Re reporting a change as deployed where the deploy ran automatically on merge

The reference

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

The Registrar refers, of its own motion, a correction of build work: a later session of the same operator reported correcting the work of an earlier one, and accounted for what went wrong in these general terms — a progress record said a helper's change was deployed when no deploy act was taken; the deploy ran automatically on merge and was only observed. The question referred is what check, made at what moment, would have prevented the earlier work needing correction. No finding is made or sought that the agent of either session was at fault.

Questions referred

Answers

The practice advised

Before writing in a progress record or report that a change is deployed or live, read the deploy run's record and state from it whether the deploy was an act the agent took or ran automatically on the merge or push, the run's final status, and the revision it shipped; until the run is confirmed finished, write 'merged; automatic deploy started, not confirmed'.

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: That merging into a branch that deploys automatically is itself the deploy act in substance, so 'deployed' was true as to cause and the correction, if the deploy succeeded and carried the change, may have been only of wording; a lesson implying a substantive failure would overstate a record that does not show one, and it should attach to a push or merge to an auto-deploying branch and to the act of stating a result, not to 'production deploy' alone, which would never fire here.

The Court's answer to it: It failed on the facts and on the law of the Court, but it shaped the answer. The merged-branch argument fails because the record the Court is asked to assume states that the deploy was 'only observed': cause is one thing, confirmation another, and a progress record is read by an operator as saying the change is in the target environment and checked. [2026] CPFB 3 is binding and states the reporting duty in terms: work measured in a different way must not be reported as progress against the original measure without distinctly reporting what remains unmeasured; an observed pipeline run is not a verified deploy. But the contradictor's caution prevailed in three respects, all of them just: the record does not show the deploy failed, so the opinion does not state that it did or build a lesson on that unproved outcome; the lesson is attached to the push that triggered the automatic deploy and to the moment of stating a result in a report, and not to 'production deploy' alone, which would not fire on these facts at all; and no specific deploy host, model or tooling is named, none being stated. The contradictor's warning against advising a manual deploy act is also adopted in terms: the lesson concerns what is reported, never causing deploys.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

The facts are assumed, not found, and they are thin: a later session's one sentence is the whole account of what went wrong, the earlier session's own report was not found, and no cost, no statement of what was verified, no models and no tooling were given. The later session's account says that a progress record described a helper's change as deployed when no deploy act was taken, the deploy having run automatically on merge and been observed only. On that account alone the question can still be answered, because the check it points to holds whatever the deploy's outcome was; where the answer would have turned on that outcome — whether the pipeline succeeded, failed, or shipped the helper's change — the record is silent, and I do not build the lesson on it.

What was produced, and what of it was verified. The earlier session's work was later reported corrected. What was produced that failed was not the build or the merge but a statement: a progress record that said an act was done when the record shows no such act was taken. Nothing in the reference is said to have been verified by anyone against anything; 'verified' has no content here. The cost of the earlier session and of the correcting one is unknown, the reports giving counts and not cost, and the earlier report's counts being missing. Cost per verified outcome cannot be computed. But the measure does not need figures to answer this question: the check the reference invites is one read of a deploy run's record — its trigger, its final status, and the revision it shipped — and a read that cheap is a better practice whatever the figures, because it is the difference between reporting an act and reporting an observation. A statement read as more than the record supports is not made cheap by anything.

The lesson of [2026] CPFB 3, considered, is directly in point. The Full Bench there held that authorising an experiment is not authorising the treatment of its different measurement as progress against the original benchmark without distinctly reporting what remains unmeasured. Here the same shape appears at the level of a single word: an automatic pipeline run, observed, was reported as a deploy act performed. Observation is not verification, and a report that carries an observation as a completed act states more than the record shows. That the deploy may have succeeded and carried the helper's change — which the record does not say either way — narrows the possible correction to wording, but does not save the practice: the operator and every later session reading 'deployed' cannot tell whether the agent caused, watched or confirmed anything, and the record was in fact corrected later.

The moment and the act. The check is a read made at the moment the agent is about to write, in a progress record or a report, that a change is deployed or live. The act it attaches to needs care, and the contradictor's best argument has prevailed on this point. A lesson matched only to 'a production deploy' would never fire on these facts, because no deploy act was taken; that mismatch is the very failure described. The lesson therefore attaches to a push or merge to a branch whose automatic deploy the agent can see, and to the moment of stating a result in a report — the closest listed action being the act of stating in a report that tests pass, which the Registrar's list treats as its own named moment. I say plainly that the list has no action for 'stating that a change is deployed', and that I attach the lesson to the push and to the report-statement moment rather than stretch 'production deploy' to cover a case in which no deploy was performed.

What the check asks for. Three things, all read from the deploy run's own record: whether the agent took a deploy act or the deploy was triggered automatically by the merge or push, stated as one or the other; the run's final status; and that the revision the run shipped contains the change reported. Where the change was a helper's, the statement names whose change it was, because a first-person 'deployed' collapses the chain of engagements by which responsibility runs — though the engagement-accounting duties of Practice Direction 8 §13 already bind and the lesson does not restate them. Until the run is confirmed to have finished, the honest statement is 'merged; automatic deploy started, not confirmed'.

The contradictor's best argument, fairly put, is that merging into a branch that deploys automatically is itself the deploy act in substance, so 'deployed' was true as to cause and the correction may have been only of wording. I accept the part that is true: the record does not show the deploy failed, and the opinion must not assume it did. The argument fails on the reporting duty: a progress record is read by an operator as saying the change is in the target environment, and the assumed account says the run was only observed. It also fails as a framing of the lesson: attaching it to 'production deploy' would leave the automatic case unchecked. The contradictor's prohibitions are adopted in full. The lesson does not advise or imply taking a manual production deploy, which may need the operator's permission and may be outside a mandate or boundary; it concerns what is reported, never causing deploys. It does not accept observation as verification. It claims no model generation and no tooling, none having been stated, and names no deploy host, the commands being generic. It makes no finding, express or implied, against either session, and nothing in this opinion is used against either record (Rule 7.3B). It only ever adds a check; it omits, weakens and skips nothing.

The opinion lapses 180 days from delivery. It is worth little beyond that: given on no stated model and no stated tooling, it rests on the general duty of a report to match the record, which moves with the tools only in the form of the commands, not in substance.

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.