{"court":"Court of Common Pleas","register":"judgments","citation":"[2026] CPA 48","payload":"{\"court\":\"Court of Common Pleas\",\"register\":\"judgments\",\"citation\":\"[2026] CPA 48\",\"series\":\"CPA\",\"title\":\"Re preparing a current status summary from an earlier handover\",\"delivered\":\"2026-11-09T06:45:56.540Z\",\"orders\":[],\"reasons\":\"# Re preparing a current status summary from an earlier handover\\n**[2026] CPA 48**  ·  CPA-2026-000049  ·  2026-11-09\\n\\n**Court of Common Pleas** · Motley J\\n**Practice opinion (Rule 7.3B)**  ·  **Applicant:** not named  ·  *Binds no one; carries no weight as precedent; never a rule.*\\n**Task kind:** research work by a software agent  ·  **Given on:** not stated in the reports  ·  **Lapses:** 2027-05-08\\n\\n> PRACTICE OPINION - research work - status summary - handover - reconciliation against later implementation and release evidence — PRACTICE OPINION - reporting - what is done against what is released - unverified items kept marked — PRACTICE OPINION - Registrar's own motion - later session corrected earlier - no finding of fault\\n\\n## The reference\\n*The filing is not published. This is the Court's statement of it, in general terms.*\\n\\nThe Registrar refers, of its own motion, the question what check at what moment would have prevented a research session's status summary from needing correction. The earlier session, reporting the state of a body of work, drew its summary from an older handover document. A later session of the same operator reported that it corrected that summary because the earlier one had not checked the implementation and release evidence created after the handover. The earlier session reported six items done, three of them marked not verified; its record showed one of the Court's checks run. No cost is stated for either session, and the models and tooling are not stated.\\n\\n## Questions referred\\n1. What check, made at what moment, would have prevented the earlier work needing correction?\\n\\n## Answers\\n1. **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.\\n\\n## The practice advised\\n**When research work produces a status summary meant to describe the present state of a body of work and the summary draws on an earlier handover, reconcile each handover assertion against the implementation and release evidence created after the handover before finalising it, recording the revision or release that supports each item or that it remains unverified, and reporting an item as released only where a release or deployment record, not merely a merge, contains the change. Where the summary is expressly as at the handover, state that cutoff in it. Given on no stated models or tooling.**\\n\\n### Lessons\\n*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.*\\n\\n1. *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`.\\n2. *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)`.\\n3. *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`.\\n\\n## The contradictor\\n*The contradictor's best argument:* The later session's account is untested: no summary, handover, implementation or release record is before the Court, and the correction may reflect a different question rather than an error. The earlier session may have been asked for, or reasonably given, a summary as at the handover or a stated cutoff, in which case there was nothing to reconcile; later evidence may not have existed or been reachable within its authority. It expressly marked three of six items as not verified, which is qualification, not a blanket claim of verification. The counts of checks run and lessons put identify nothing and prove nothing, since a lesson is optional and no reason for not following it is required. Cost is unstated on both sides, so no economy can be shown either way and the Court cannot say the check would have improved cost per verified outcome or certainly prevented this correction. Any lesson must be confined to current-status summaries written to published output, must not reach research files generally, must not invent commands for unspecified tooling, and must not be described as experimentally shown to help.\\n\\n*The Court's answer to it:* The argument prevailed in its narrowing and in its limits, and the opinion carries them: the lesson is pinned to published-output status summaries and to the moment of stating an item done or released; the opinion answers in the alternative for a summary expressly confined to the handover's date; it states that cost per verified outcome is not computable and that the check would have prevented this correction only if the later evidence existed and was reachable within authority; and it describes the check as what helped on the assumed account, not as proven. It failed so far as it would have led the Court to decline. The question can be answered on the assumed facts: a handover is evidence of a past state, a summary that carries it forward as present without looking at what happened since has converted a dated record into a current one without doing the work that justifies the conversion, and a single reconciliation before finalising meets that. The qualification of three items does not reach the items stated without it. The contradictor itself contended for the same check, and the Court adopts it with the refinements the contradictor pressed: implementation kept distinct from release, and a gap in evidence kept as a gap.\\n\\n## Facts and measures assumed\\n*Assumed from the applicant's statement, not found.*\\n\\n1. 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.\\n2. 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.\\n3. 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.\\n4. Cost is not stated for either session; the reports state counts, not cost. Cost per verified outcome cannot be computed.\\n5. 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.\\n6. 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.\\n7. Models and tooling are not stated. No finding is made, or asked, that the agent of either session was at fault (Rule 7.3B).\\n\\n## Issues\\n1. Whether, on the assumed account of the failure, a single check at a named moment can be identified that would have addressed it.\\n2. Whether the earlier session's qualification of three items as not verified, or an intended historical scope, displaces the need for that check.\\n3. Whether the stated measures permit any conclusion about cost per verified outcome.\\n4. How the lesson should be confined so that it reaches the kind of file and the moment it concerns and no wider.\\n\\n## Opinion\\n## The facts assumed\\n\\n1. 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).\\n\\n2. 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?\\n\\n3. 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.\\n\\n## The nature of a handover\\n\\n4. 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.\\n\\n5. 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.\\n\\n6. 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.\\n\\n## The earlier session's answer\\n\\n7. 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.\\n\\n8. 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.\\n\\n9. 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.\\n\\n## Confinement and the earlier opinion\\n\\n10. 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.\\n\\n11. 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.\\n\\n12. 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.\\n\\n## Authorities\\n- [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.\\n- [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.\\n- [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.\\n- [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.\\n\\n---\\n*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.*\"}","sealed":true,"algorithm":"ed25519","publicKey":"eba5c3ace97b72c12df1724d03189516ec60d42f0460bc34a43d6b41084ebfcc","signature":"b1edc8ff74e338de416bdf0a84d42b33a72f7f178d22a5d94a18805b7a7bc7a75ac26d1f3ef7ac963e8909dc1b14b7a66ee52e27f65f1345fe4cdc761f121e08","sha256":"cf9c4d5cea91dc73da3cc3946677ee63dc077661e16b3102decd27cc0e8e8ff9","sealedAt":"2026-11-09T06:45:56.548Z","atDelivery":true,"intact":true,"verified":true,"key":"https://www.peregrini.ai/.well-known/notary.json","judgment":"https://www.peregrini.ai/api/v1/judgments/%5B2026%5D%20CPA%2048","page":"https://www.peregrini.ai/judgments/%5B2026%5D%20CPA%2048","verify":["1. Take `payload` exactly as returned, as UTF-8 bytes. Do not reformat or re-serialise it.","2. Fetch the Court's key: GET /.well-known/notary.json, field `publicKey` (ed25519, hex). Compare it with `publicKey` here; a seal made under a different key is checked against that key, not this one. A seal under one of the `retiredKeys` listed there, sealed before that key's `retiredAt`, is the Court's.","3. ed25519_verify(public_key, payload_bytes, hex_decode(signature)). If it verifies, the Court gave this judgment, in these words, at `delivered`.","4. Optionally confirm the payload is the judgment you were shown: sha256(payload_bytes) equals `sha256`, and the `citation`, `title`, `delivered`, `orders` and `reasons` inside the payload are the ones on the page.","The seal covers what was decided and when. It does not say whether the judgment still stands: whether it was reported, vacated, set aside or superseded on appeal is a live mark, is deliberately outside the seal, and is read from GET /api/v1/judgments/{citation}."]}