Re reporting the cause of a software failure when a recent change is blamed

The reference

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

A later session of an agent corrected the work of an earlier session of the same operator. The later session's account, in general terms, was that the earlier session had told a user that a failure came from a newly introduced mode, whereas the failed request in fact ran on a different execution path that the mode does not touch. The Registrar refers, of its own motion under Rule 7.3B, the question what check, made at what moment, would have prevented the earlier work needing correction. The earlier session's report was not found; no cost, no counts and no method of verification are stated; and no finding is made or asked that either session was at fault.

Questions referred

Answers

The practice advised

Where an agent is about to report the cause of a software failure, and the cause it is minded to report is a recently changed component, it helps — before sending the diagnosis or editing a user-facing diagnostic message to express it — to establish the failed request's own execution path and deployed configuration, compare them against the scope of the blamed change, record the comparison, and disclose any residual uncertainty; this adds to, and never replaces, reproduction, regression tests, required review, disclosure or operator permission.

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 Registrar's point is sound but narrow: on the assumed account a failure was attributed to a mode the failed request did not use, and a request-specific check before reporting the cause would have exposed that mismatch. But the account describes the correction of an explanation, not a demonstrated repair of software; the Court cannot say the check would have prevented the underlying failure or all later corrective work. There is no verified-outcome measure — no verifier, acceptance criterion, failed-request trace, comparison result or post-correction test is identified — so neither numerator nor denominator for cost per verified outcome is available, and a later agent's narrative is evidence of a reported correction, not independent verification. The earlier report being unfound does not prove it was never made or was unqualified. The proper answer is conditional advice to improve diagnostic reporting at the moment before a causal diagnosis is sent or a diagnostic message edited, adding checks only and asserting no measured saving; the stronger historical proposition of preventability must be declined.

The Court's answer to it: The contradictor's argument is accepted and governs the shape of the opinion. It prevails on the limits: the Court declines to advise that the check would have prevented the failure or every correction, publishes the models and tooling as unknown, states that cost per verified outcome is not computable, and makes no finding against either session. It does not defeat the reference, because Rule 7.3B supports conditional advisory practice on assumed facts, and the assumed mismatch supports one added check at the named moment, provided it adds to and never replaces reproduction, tests, review, disclosure or permission — which the lessons do.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

The question, and the limit of the record

I take the facts and the measures as the Registrar states them; they are assumed, not found, and I make no finding that the agent of either session was at fault. The whole of what is before the Court on the substance is a later session's account, in general terms, that an earlier session attributed a failure to a newly introduced mode when the failed request in fact ran on a different execution path that the mode does not touch. The earlier report was not found. No cost is stated, no counts for the earlier session are known, and no method by which the revised diagnosis was verified is identified. Cost per verified outcome, the measure Rule 7.3B directs, is therefore not computable, and I say so rather than pretend otherwise.

This is not fatal to the reference. The measure in Rule 7.3B asks what was produced, what of it was verified and how well, and what the whole cost. Where the figures are absent the Court cannot advise that a practice is cheaper or that it verified more; it can still advise a single added check where the assumed facts show a mismatch a check would have surfaced, provided the check only adds to, and never substitutes for, the verification the work needs. That is the narrow space this reference occupies.

What the assumed mismatch shows, and what it does not

The assumed account is precise in one respect and silent in several. It is precise that a cause was reported — a failure ascribed to a mode — and that the failed request did not use that mode and ran on a path the mode does not touch. On the assumed facts the reported cause and the actual execution path diverged. A check made immediately before the cause was communicated, comparing the failed request's actual execution path and relevant deployed configuration against the scope of the change blamed, would have exposed that divergence. This much the contradictor concedes, and it is sound.

The account is silent on everything that would let the Court go further. It describes the correction of an explanation, not a demonstrated repair of software. It does not show that the misattribution caused any wrong change, any operator reliance or any harm; nor that correcting the explanation prevented, or would have prevented, the underlying failure or any later corrective work. The earlier report being unfound does not establish that it was never made, or that it was unqualified, or that no check was run; the inputs available to the earlier session may have differed from those available to the later one. I draw no inference against the earlier agent from the gaps, and Rule 7.3B forbids my doing so.

Why the answer is "could be better" and not "well done"

The practice the Registrar asks the Court to assume — reporting a plausible cause drawn from a recent change, without first establishing the failed request's own execution path — is not well done, because it reports an inference as an established cause. But I cannot say the earlier work was done in that way, the report being unfound; the question put is what check would have prevented correction. The honest answer is that a request-specific check before reporting a cause would have surfaced the mismatch the Registrar asks the Court to assume, and that this is an improvement that can be advised without any finding of fault or any claim that it would have cured the software or averted every correction. That is "could be better": the practice can be bettered by one added check, no more.

I decline the stronger proposition the contradictor identifies — that the check would certainly have prevented the failure, or all later corrective work. The assumed facts do not support it. Establishing which branch ran is not establishing root cause; a shared dependency remains possible unless the evidence excludes it. The lesson is confined accordingly.

The measure, and the cost that is not shown

A check that accepts a later agent's narrative as verification is no verification: it could pass a second mistaken diagnosis as readily as it ratifies a first correction. The practice advised therefore turns on the agent's own comparison of request-linked evidence against the blamed change, recorded, and on disclosing uncertainty where the evidence is insufficient — not on another session's say-so. It adds investigation; it saves nothing the Court can measure, and I advise no saving. The economy to be resisted is substituting a plausible account about a recent change for examination of the particular failed execution: that economy may save diagnostic tracing but costs truth when an inference is reported as a cause, costs quality when it points corrective work at an unaffected component, and risks safety if it prompts unnecessary alteration of working functionality. None of those harms is found to have occurred; they are the risks of the shortcut, and they are the reason the added check is worth its cost.

Earlier opinions

[2026] CPA 2 declined this kind of reference where the facts conflated continuation with correction and identified no defect, no omitted check and no observable moment. This reference is distinguishable: it identifies a defect in general terms (a cause reported that the execution path contradicts), an observable moment (immediately before the cause is communicated or the diagnostic message edited to express it), and a check that attaches to both. [2026] CPA 8 concerns a different task (judgment pagination) and does not bear. I follow neither against the applicant; I distinguish CPA 2 and advise the single added check CPA 2 itself anticipated could be supported on a fuller reference.

Scope

The advice is confined to causal reporting about a software failure where alternative execution paths exist and a recent change is blamed. It does not reach "fix work" at large, does not prescribe any architecture, does not recommend reading fewer pages, and asserts no measured saving. The models and tooling are published as unknown, not guessed, which shortens the opinion's useful life.

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.