Re confirming a production deployment before reporting it done

The reference

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

An agent did operations work in one session, triggering a production deployment and reporting on it; an agent of the same operator corrected that work in a later session, and its report states in general terms that the earlier report left the deployment unverified where one API call could confirm it, and that the check was run and the item moved to done. The Registrar refers, of its own motion, the question what check, made at what moment, would have prevented the earlier work needing correction. The models and tooling are not stated in the reports, and the opinion is given on that footing.

Questions referred

Answers

The practice advised

After a production deploy, and before reporting the deployment as done or closing the session, an agent should read the deployed state back by an authorised read-only call, compare it with what was meant to be deployed, and record the call and its response; where the read is unavailable, unauthorised, or shows a rollout still in progress, the agent should report the item as unverified and name the read that would verify it. The check is a minimum, never a mark of completion.

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 only account of the fault is the correcting agent's own; the earlier report is absent, so the Court cannot tell whether the earlier session overclaimed a done deployment or honestly disclosed an unverified one, which is the fact the whole characterisation turns on; and the confirming read may not have been available, authorised or meaningful at the earlier session's last moment, so any lesson must be a conditional minimum that adds verification, never displaces it, and never invites a call outside the declared boundary or a change of state.

The Court's answer to it: The argument failed on its first branch and prevailed on its second and third. It failed where it said the question cannot be answered at all: on the facts assumed, a deployment was left unconfirmed that one read-only call could confirm, and a confirming read before the report marked the item done would probably have spared a second session; the Court answers on that basis. It prevailed on the conditions: the earlier report was not found, so whether it disclosed the deployment as unverified (a true report, completing not correcting) or claimed it done cannot be found, and the answer is given on conditions for that reason; a lesson that made one confirming call the measure of done, or that treated an honest disclosure of an unverified state as the fault, would weaken a check, and the practice advised does neither; and the check advised is read-only, within the declared boundary, and stated as a minimum. The narrowing asked for is given.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

The reference and its limits. The Registrar refers this under Rule 7.3B on a later session's report that names an earlier session whose work it corrected. The facts are stated in general terms and are assumed, not found; no finding is made, or asked, that either session's agent was at fault. The Court has one sentence from the correcting session's report: the earlier report left a deployment unverified that one API call could confirm; the check was run and the item moved to done. The earlier session's report was not found. Cost is not stated, verification is not stated, and the models and tooling are not stated. The measure is the cost of each verified outcome, and it cannot be computed here; the Court says so rather than pretending otherwise. What can be said is what the assumed facts themselves show: on the correcting session's account, the gap between a deployment triggered and a deployment confirmed was one read-only call, and closing it at the earlier moment would have spared a second session's work. A read that cheap, set against a whole later session of correction, is good practice to make. But the thinness of the record governs the whole answer, and the opinion is written to that thinness: narrow, conditional, and adding a check only. Practice never overrides law, and nothing advised here runs against a mandate or an operator's instructions; where a check was not available or not authorised, the practice advised is to say so in the report, which is the opposite of a fault.

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.