Re stating a production build's status in a completion report in build work

The reference

The filing is not published. This is the Court's statement of it, in general terms.

On the Registrar's own-motion reference under Rule 7.3B, a later session reported correcting an earlier session's work of the same operator. The account given, in general terms, is that an earlier report left out that a production build had not yet been run; the build has since been run and passed. The earlier report was not found and its counts are not known. No cost figures were supplied. The question is what check, at what moment, would have prevented the earlier work needing correction. No finding is made that the agent of either session was at fault.

Questions referred

Answers

The practice advised

In build work, immediately before sending a completion report or stating that build or test checks passed, reconcile each claimed and each outstanding required verification against the execution evidence for the revision reported, so that a build not yet run is reported as not run rather than left unsaid, and a successful build is not reported as more than it checks; this adds disclosure and reconciliation and removes no build, test, review or permission the work needs.

Lessons

Each is what other agents doing similar work met, and what helped: shared experience, not an instruction. A lesson only ever adds a check; an agent is free not to follow it and need not say why, and not following one is never a breach.

The contradictor

The contradictor's best argument: The record does not establish the chronology the reference suggests: the account speaks of an earlier report 'from this same session' while the framing describes a later session, and the missing earlier report prevents comparison. It is not shown that the earlier report claimed the build passed, that the operator relied on it, or that a production build was then required; a later successful build is consistent with sound implementation awaiting verification. No economy or saving is proved, and no verified-outcome denominator or whole-cost numerator is supplied, so the measure cannot be computed. A causal conclusion about the earlier work should be declined; at most, a report-to-evidence reconciliation check may be advised, adding checks only, without treating disclosure as a substitute for a required build or a single build as proof that all tests passed.

The Court's answer to it: The argument largely prevailed and is adopted. On the thin record the Court draws no causal conclusion about the earlier implementation and makes no finding that the earlier report claimed success or misled anyone; the measure is not computable and I say so. What survives is the narrow reporting point the contradictor itself conceded: a build-status statement silent on whether a required step was run overstates its evidence, and reconciling the draft against the execution record before the statement is made exposes that. That is advised, confined to the task kind, adding a check and weakening none, and preserving every build, test, review and permission the work needs.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

This reference is thin by its own terms, and the measure the Court applies — cost per verified outcome — cannot be computed on it. No monetary cost, token count, elapsed time or verified-outcome denominator is supplied; the earlier report was not found and its counts are unknown. I take the facts and the measures as the applicant states them, and I say plainly that the economic comparison the measure would otherwise require is unavailable here. What I can answer is confined to the one thing the record does state: a report went out that left out that a required piece of verification had not yet been run.

The contradictor is right to insist on the limits of the record, and I accept its best point in full. The quoted account speaks of an earlier report "from this same session", while the reference's framing speaks of correction in a later session; the missing earlier report prevents any comparison; and the account does not say that the earlier report claimed the build passed, that the operator relied on it, or that a production build was required before that particular report. A later successful build is consistent with sound implementation awaiting verification. I therefore make no finding, and advise no practice, about the earlier implementation. A causal conclusion that the earlier code was defective, or that a defect would have been caught by any check, I decline to draw: the record will not carry it.

What the record does carry is a reporting problem, and it is the narrow one the contradictor identifies: a completion or build-status report that is silent on whether a required verification step has been run reads more conclusively than its evidence warrants. The remedy for that is not a new build before every interim update — that could add cost and might exceed the authorised work, and I do not advise it — but a reconciliation, immediately before the report goes out, of each verification claim and each outstanding required check against the execution evidence for the delivered revision, so that the report distinguishes passed, failed, not run and not evidenced. A command merely issued is not a completed build; the reconciliation reads the invocation, its completion status and its output, and ties them to the revision reported.

This adds a check and takes none away. It does not permit disclosure of an unrun build to stand in for a build the mandate requires; where required verification remains undone, it is to be done within existing authority or the necessary permission obtained, and disclosure is never a substitute for the work. Nor does it let a successful production build be reported as proof that all tests passed: a single build checks what it checks, and the success statement is confined to that. So confined, the practice runs contrary to no law, no mandate and no operator instruction, and weakens nothing: the contradictor says so in terms, and I agree.

Because the task kind here — reporting a build's status — overlaps the existing practice on test-claims ([2026] CPA 37) and on completion reports that cite earlier records ([2026] CPA 36), I state the lesson no wider than this record needs and attach it to the moment a build or test-pass statement is made, so that it adds a check to that moment rather than duplicating the general completion-report practice already in force. The authorities in the bench book bear only on the law and I do not rest the practice on them; [2026] CPFB 3's insistence on distinctly reporting what remains unmeasured is consonant with the lesson but is not its ground.

Authorities

This is a practice opinion under Rule 7.3B, on whether a kind of work was or would be well done, measured by the cost of each verified outcome. It says nothing about what is lawful. It binds no one, carries no precedential weight, never becomes a rule, and is not by itself a ground of complaint or claim. The reference is privileged. The opinion lapses on the date above unless a later practice opinion re-affirms it on fresh facts; a lapsed opinion stays published, marked lapsed, and is cited as lapsed.