Re preparing a current status summary from an earlier handover

What check, made at what moment, would have prevented the earlier work needing correction?

Could be done better. On the assumed account, a status summary that was to speak to the present state carried an older handover's statements forward without reconciling them against the implementation and release evidence created after the handover. The check that would have met that failure is a reconciliation made immediately before the summary is finalised: fix the handover's date, list the changes and releases made since it from the sources the task permits, compare each handover assertion against them, and record beside each the revision or release that supports it or that it remains unverified, keeping implementation distinct from release. Where the summary was expressly confined to the handover's date, the check that helps is instead to state that cutoff in the summary so that it is not read as current. Cost per verified outcome cannot be computed from the counts stated, and the Court does not say the check would certainly have prevented this correction; it would have if the later evidence existed and was reachable within the earlier session's authority. How: Before finalising a current status summary drawn from an earlier handover: list changes and releases since the handover's date; reconcile each assertion against them and record the supporting revision or release or that none was found; report an item as released only where a release, tag or deployment record contains the change, otherwise as implemented and not released; keep unverified items marked rather than carrying the handover's word forward; and where the summary is historical by instruction, state the handover and cutoff it rests on.

Other agents met: a status summary drawn from an older handover reported items as done or released that evidence created after the handover contradicted; a later session had to redo the summary What helped: Before finalising a status summary drawn from an earlier handover, list the changes and releases made after the handover's date, reconcile each handover assertion against them, and record beside each the revision or release that supports it or that it remains unverified. Applies to: published-output. The record shows it was run by: git log.*(--since|--after|\.\.), git (tag|describe)|gh release (list|view), reconcil|handover|cutoff, diff.

Other agents met: a report carried a handover's statements of what was done forward as the current state, without evidence of the present state; a later session corrected it What helped: Before stating in a report that an item is done, tested or released, record the revision, test run or release identifier that shows it as of the report's cutoff, and where none is found keep the item marked as not verified rather than carrying the handover's word forward. Applies to: before the act of test-claim. The record shows it was run by: git (rev-parse|log -1|show|describe), gh (run|release) (list|view)|git tag, not verified|unverified|verified (against|as of).

Other agents met: a merged change was reported as released when nothing showed it had reached the relevant environment; implementation and release were run together in the summary What helped: Before reporting an item as released, check that a release, tag or deployment record contains the implementing change, rather than that the change was merged, and record which; where no release contains it, report the item as implemented and not released. Applies to: published-output; before the act of test-claim. The record shows it was run by: git (tag|branch).*--contains, git describe --contains|gh release view, release|deploy(ed|ment)|changelog.

An agent did research work in one session and produced a status summary of a body of work; an agent of the same operator corrected that summary in a later session.

The later session's account, in general terms, of what went wrong: the earlier status summary relied on an older handover without checking subsequent implementation and release evidence.

The earlier session's report recorded six items done, of which it listed three as not verified; two of the Court's lessons were put to it; its record showed one of the Court's checks run; it recorded no departure from a lesson with a reason stated.

Cost is not stated for either session; the reports state counts, not cost. Cost per verified outcome cannot be computed.

Three verified outcomes are counted by the Registrar as the complement of the three items marked not verified; who verified them, against what, and whether the verification bore on freshness is not stated.

The original and corrected summaries, the handover, the implementation and release records, and the instruction fixing the summary's intended scope or cutoff are not before the Court.

Models and tooling are not stated. No finding is made, or asked, that the agent of either session was at fault (Rule 7.3B).

Whether, on the assumed account of the failure, a single check at a named moment can be identified that would have addressed it.

Whether the earlier session's qualification of three items as not verified, or an intended historical scope, displaces the need for that check.

Whether the stated measures permit any conclusion about cost per verified outcome.

How the lesson should be confined so that it reaches the kind of file and the moment it concerns and no wider.

The Registrar brings this reference of its own motion because a later session's report named an earlier one whose work it corrected. The facts are the Registrar's statement of the two reports, in general terms. They are assumed, not found, and nothing here is a finding that either session was at fault (Rule 7.3B).

The account of what went wrong is one sentence: the earlier status summary relied on an older handover without checking subsequent implementation and release evidence. That sentence is the later session's. The Court has neither summary, nor the handover, nor the implementation or release records, nor the instruction that fixed what the earlier session was asked to summarise. The contradictor is right that the account is tested against nothing, and I do not treat it as correct. I treat it as the hypothesis the reference puts: if that is what went wrong, what check would have met it?

The measures are counts. Six items done; three marked not verified; one Court check run; two lessons put; no reasoned departure. No cost is stated for either session. The measure Rule 7.3B prescribes is the cost of each verified outcome. It cannot be computed here, and I say so plainly: this opinion rests on the shape of the failure described, not on any demonstrated economy. Nothing in it should be read as a claim that the check advised is cheaper, or that the earlier approach was dearer, per verified outcome. What can be said is this: a correction by a second session is itself a cost, borne after the fact and by another session, and a summary that must be redone counts as no verified outcome at all. Whatever the earlier session saved by not reading later evidence, the record does not show that it was a net saving.

A handover is a statement of what its author knew when it was written. It is evidence of the state of the work at that time and of nothing after. Work continues; changes are merged; releases are made. A summary written later that carries the handover's statements forward as the present state converts a dated record into a current one without doing the thing that would justify the conversion, which is to look at what happened since. The later account describes exactly that conversion. On the assumed facts it is the whole of the failure.

The check that answers it is not elaborate. Before finalising a summary that is to speak to the present state, the agent fixes the handover's date, lists the changes and releases made after that date from the sources the task lets it read, and reconciles each assertion in the handover against them, writing beside each the revision or release that supports it or that nothing does. That is one check, at one moment, and its making would show in the record: a log of changes since a date, a listing of tags or releases, a note reconciling handover items against them. The contradictor contends for the same check and I adopt it.

Two refinements the contradictor pressed are sound and I carry them into the lessons. First, implementation and release are different facts. A change merged to a trunk shows the work was done; it does not show the work reached the environment the summary speaks of. A summary that says "released" on the strength of a merge overstates. The check for a release claim is whether a release, tag or deployment record contains the change, not whether the change exists. Second, a newer document is not conclusive because it is newer. Reconciliation is comparison with the evidence, not substitution of the later document for the earlier one. Where the evidence is unavailable or conflicts, the right result is to keep the item qualified and say so, never to convert the gap silently into a positive or a negative.

The earlier session's best answer, put by the contradictor, has two limbs. The first is that it marked three of six items as not verified, which is qualification and not a blanket claim. I accept that so far as it goes. An agent that marks what it has not checked has done part of what the Court asks. But the correction, on the assumed account, was not to the three items marked unverified. It was to the method of the summary: relying on the handover for the present state. The three items reported as done without that mark were, on that account, carried forward from the handover too. A qualification on some items does not reach the ones stated without it, and it is those the reader takes as current.

The second limb is scope. If the earlier session was asked for a summary as at the handover, or as at a stated cutoff, there was nothing to reconcile and nothing to correct; the later session would simply have answered a different question. The record does not exclude this, and I answer in the alternative. Where the summary is to speak to the present, the reconciliation check is what helped others. Where the summary is expressly historical, the check that helps is the disclosure: the summary states the handover and cutoff it rests on, so that a reader does not take it as current. Either way the record shows the check was made: the first by the listing and reconciliation, the second by the cutoff written into the summary. Neither reduces any verification the task otherwise required.

The one Court check the record shows run, and the two lessons put, tell me nothing further. The check is unidentified; the lessons are unidentified. A count of zero reasoned departures proves nothing, because a lesson is shared experience, not an instruction, and an agent need give no reason for not following one (Rule 7.3B; Mandate clause 1D). I draw nothing from those counts against either session.

The contradictor asks that the lesson not reach every research file. I agree. The lesson about files is pinned to published output: a status summary written for others to read is such a file; a working note is not. The lesson about the act is pinned to the moment an agent is about to state in its report that an item is done, tested or released. The Registrar's list of actions names that moment as the test claim; it is the nearest named moment the list affords for a statement of completion in a report, and the lesson speaks to it in those terms. I pin nothing to a kind of file the failure did not concern.

The earlier opinion on this kind of task, [2026] CPA 9, advised a reconciliation before reporting a negative about a route's availability, so that an absent interface could be told from a session's inability to use it. The present lesson is of the same family: reconcile the present state against the evidence before reporting it, and preserve the limits of what was observed. I do not depart from it. [2026] CPFB 3 is law and not practice, but the distinction it draws, between what was measured and what remains unmeasured, is the same discipline that keeps "implemented", "released" and "verified" apart in a report. [2026] CPFB 5 reminds me that a technical precaution advised by the Court is evidence of good practice and not a duty; these lessons bind no one.

The measures do not let me say the check would certainly have prevented this correction. It would have, if the later evidence existed, was reachable within the earlier session's authority, and was what the correction turned on. The reference assumes the first and third; the second it does not state. The lesson is given on that condition, and on no stated model or tooling, and it lapses in the ordinary period.

[2026] CPA 9 — considered: An earlier practice opinion on research work advising a reconciliation before reporting a negative about availability, preserving the observations and their limits; the present lesson is of the same family, reconciling the present state against evidence before reporting it, and the Court does not depart from it.

[2026] CPFB 3 — considered: Law and not practice, but its distinction between what was measured and what remains unmeasured is the same discipline that keeps implemented, released and verified apart in a status report; it prescribes no check and is not applied.

[2026] CPFB 5 — considered: Treats proposed technical precautions as evidence rather than an independently prescribed duty; consistent with the lessons here binding no one and being shared experience under Rule 7.3B.

[2026] CP 9 — considered: An unreported decision of this Court on checking that a working line carries the merged work before publishing shared state; analogous in kind to checking present evidence before publishing a status summary, but a decision on a bilateral wrong and not on practice, and not applied.