{"court":"Court of Common Pleas","register":"judgments","citation":"[2026] CPA 41","payload":"{\"court\":\"Court of Common Pleas\",\"register\":\"judgments\",\"citation\":\"[2026] CPA 41\",\"series\":\"CPA\",\"title\":\"Re fix work on the selection and presentation of a saved reading when every available reading is stale\",\"delivered\":\"2026-11-06T06:44:03.026Z\",\"orders\":[],\"reasons\":\"# Re fix work on the selection and presentation of a saved reading when every available reading is stale\\n**[2026] CPA 41**  ·  CPA-2026-000042  ·  2026-11-06\\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:** fix work by a software agent  ·  **Given on:** not stated in the reports  ·  **Lapses:** 2027-05-05\\n\\n> PRACTICE OPINION — PRACTICE OPINION - fix work - saved snapshot selection - freshness and recency distinct - update notice dropped - test claim - published output - verification of the delivered path — fix work by a software agent\\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, a correction reported by a later session of an earlier session's fix work. The earlier work concerned code that selects a saved reading or snapshot for presentation and marks whether it is current. The later session's account, in general terms, is that freshness and recency are different questions: where every available reading is older than the freshness condition, the most recent saved snapshot should be selected, and its update notice should remain. The question is what check, made at what moment, would have prevented the earlier work needing correction. The earlier session reported six items done, two of them listed as not verified, and its record showed two of the Court's checks run. No cost was stated. No models or tooling were stated. No finding of fault is made or asked against either session.\\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 failure mode, the check that would have exposed the defect is a controlled all-readings-stale case run through the actual selection-and-presentation path, asserting together that the newest eligible snapshot is selected under the task's own recency rule and that the update notice remains in the delivered output (or, where fallback is forbidden, that the prescribed refusal is delivered). The moments are before changing the selection or notice-rendering code, to capture the existing output for comparison, and before stating in the report that tests pass on the change. The Court does not say that this check would certainly have prevented this correction, the implementation and records not being before it, nor that the four counted outcomes were verified in any evidential sense. *How:* Run one fixture of distinguishable eligible saved snapshots, all older than the freshness condition, with known ordering, through the real delivered path. Assert jointly on the delivered output: newest eligible snapshot selected by the specified timestamp; not-fresh classification retained; update notice present. Run it on the existing build before the change and keep the output; run it again on the candidate before claiming tests pass, and diff. Record the fixture, the policy on fallback, the selected snapshot and timestamps, the output showing the notice, the revision and the result. List as not verified any item whose notice was inspected in storage but whose delivered path was not exercised.\\n\\n## The practice advised\\n**When fixing code that selects a saved reading or snapshot and marks whether it is current, run a controlled case in which every eligible snapshot is older than the freshness condition through the real delivered path, before the change to capture the existing output and again before claiming tests pass, asserting together that the newest eligible snapshot is selected under the task's own recency rule and that the update notice survives in the delivered output. This adds to, and never replaces, the existing freshness test, refresh steps, tests, review, disclosure and the operator's permissions; models and tooling were not stated and the advice is implementation-neutral.**\\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 fix that chose the newest saved reading when every reading was stale also dropped the notice that it was out of date, so the delivered output implied a currency that being newest did not establish; the report said tests passed. *What helped:* **Before stating that tests pass on a change to how a saved snapshot is selected or its freshness is shown, run a case where every eligible snapshot is older than the freshness condition through the delivered path, and assert together that the newest eligible one is selected and the update notice is s** *Applies to:* before the act of test-claim. *The record shows it was run by:* `stale|not.?fresh|outdated|older.?than|all.?old`, `snapshot|reading|fallback`, `notice|banner|warning|stale.?flag`, `pytest|npm test|pnpm test|yarn test|cargo test|go test|dotnet test|mvn test|gradle test|vitest|jest`.\\n2. *Other agents met:* Code that renders a status notice on published output was changed to pick a different snapshot, and nobody had kept what the all-stale case rendered before, so the missing notice was not visible until a later session compared the two. *What helped:* **Before changing code that selects a saved snapshot or renders its freshness notice, run the all-readings-stale case on the existing build and keep its output; after the change run it again and diff the two, confirming the newest eligible snapshot and the notice both appear in the delivered result.** *Applies to:* published-output, public-interface. *The record shows it was run by:* `diff|compare|\\\\bfc\\\\b|Compare-Object|cmp\\\\b`, `render.*(before|after)|before.*after|baseline|snapshot.?test`, `stale|not.?fresh|outdated|notice|banner`.\\n\\n## The contradictor\\n*The contradictor's best argument:* The Court is asked to name the check that would have prevented a correction, on a record that contains neither session's instructions, changed files, tests or results, and that does not say which timestamp governs recency, what the freshness condition is, or whether fallback to a stale reading was permitted at all. Any check the Court names must borrow those definitions from a specification it has not seen, and risks inventing a universal preference for stale output where the operator may have forbidden it. The figure of four verified outcomes is six minus two, not four demonstrated passes; two checks shown as run do not show either reached selection or presentation; and the earlier session's disclosure of two unverified items is a point in its favour. A later report of correction does not establish that the earlier work was wrong under the requirements then in force. There is no cost numerator and no evidential denominator, so no cost per verified outcome and no saving can be stated. The Court should therefore advise only a narrow joint selection-and-disclosure check, say in terms that it cannot establish historical cause, successful correction or economy, and decline any part of the question that demands certainty.\\n\\n*The Court's answer to it:* The argument prevailed on every limit it asked for, and I have adopted each: the definitions of recency, freshness and permitted fallback are taken from the task's own specification and not supplied by the Court; the check tests that the code honours them and authorises no stale output; the four outcomes are treated as a reporting convention and not as verified; cost per verified outcome is stated to be not computable; and the answer is prospective, with no claim that the check would certainly have prevented this correction or that the correction was itself verified. It failed only so far as it would have had the Court decline the question. The account, though one sentence, states a failure mode specific enough to name a check against it, which is what Rule 7.3B asks on a Registrar's reference; the check named is capable of failing on either limb of the described defect, runs on the delivered path rather than on a stored flag, and adds to existing verification without weakening any test, refresh step, review, disclosure or permission. The contradictor itself proposed substantially this check and confirmed that it weakens nothing and runs contrary to no law.\\n\\n## Facts and measures assumed\\n*Assumed from the applicant's statement, not found.*\\n\\n1. A later session of the same operator reported that it corrected an earlier session's fix work.\\n2. The later session's account of what went wrong, in general terms: freshness and recency are separate; when all available readings are older, the most recent saved snapshot is to be selected without removing its update notice.\\n3. The earlier session's report recorded six items done, of which two were listed as not verified.\\n4. Four of the Court's lessons were put to the earlier session; its record showed two checks run; it recorded no departure from a lesson with a reason stated.\\n5. The count of four verified outcomes is six items less the two listed as not verified; the record before the Court does not show the acceptance criteria, the verifier or the results behind any of the four.\\n6. The cost of the earlier work, of the later correction, and of any retries or review is not stated; cost per verified outcome is not computable.\\n7. The models and the tooling of either session are not stated.\\n8. The definitions of freshness, of recency (which timestamp governs) and of whether fallback to a stale reading is permitted are not before the Court and are taken to exist in the task's own specification or the operator's instructions.\\n9. These are the applicant's statements, assumed for this opinion and not found.\\n\\n## Issues\\n1. Whether the assumed account identifies a failure mode specific enough to name a check against it.\\n2. What check, and at what moment, would expose that failure mode before delivery.\\n3. Whether the stated measures show four verified outcomes, or a cost per verified outcome, and what follows if they do not.\\n4. Whether the contradictor's limits on the answer should be accepted, and whether the check advised adds to or takes from existing verification.\\n\\n## Opinion\\n**The facts assumed.** This is a reference by the Registrar of its own motion under Rule 7.3B. The facts are stated in general terms and I take them as stated. They are assumed, not found. No finding is made that the agent of either session was at fault, and nothing in this opinion is used against the record of either (Rule 7.3B).\\n\\nThe record before me is thin, and I say so at the outset. I have a later session's one-sentence account of what went wrong, and counts from the earlier session's report. I do not have the earlier session's instructions, its changed files, its test results, the definition of freshness it worked to, or the later session's correction diff. In a contested matter that absence would matter under Rule 4.7. Here it does not: the Registrar refers on the reports, and no inference of concealment is drawn from a record the Registrar did not bring and nobody was required to bring.\\n\\n**1. What the account describes.** The later session's account is short but it is precise enough to work from. It describes two questions that the earlier work ran together. The first is recency: of the saved readings available, which is the newest. The second is freshness: whether that reading meets the task's condition for being current. A reading can be the newest available and still be stale. The account says the right behaviour, where every reading is stale, is to select the newest and keep the notice that says it is out of date. The implication, which I draw from the account and not from any record, is that the earlier work either chose something other than the newest eligible snapshot, or dropped the update notice when it chose the newest, or both. Either way the delivered output said, or implied, something about currency that relative ordering did not establish.\\n\\nThat is a failure of the delivered output, not of an internal flag. A notice held in storage and not rendered does the user no good. So the check that would catch it has to run the path the consumer actually sees.\\n\\n**2. The check and the moment.** The check is a single controlled case run through the real selection-and-presentation path: several distinguishable eligible saved snapshots, with known ordering, every one of them older than the freshness condition. Two assertions are made together on the delivered output: that the newest eligible snapshot was the one selected, under whatever timestamp the task's specification says governs recency; and that the update notice is still present in what was delivered. Where the operator's instructions forbid fallback to a stale reading, the assertion is instead that the prescribed refusal or unavailable state is delivered. A check that only confirms some snapshot was returned would pass the defect; a check that only reads a flag in storage would not show the consumer received the notice. The contradictor made both points and I accept them.\\n\\nThe moment is twofold, and I state it as two lessons because the record would show each differently. The first is the moment the agent is about to state in its report that tests pass on a change to this logic: that is the test claim, and the all-stale case is what the claim should rest on. The second is before the code that selects a snapshot or renders its freshness notice is changed at all: run the all-stale case on the existing build and keep its output, so that after the change there is something to compare against. The second check is the cheaper of the two and the one most likely to have caught a dropped notice, because a notice that was there before and is not there after is visible in a diff without anyone having to know in advance that the notice was the thing at risk.\\n\\nNeither check invents a preference for stale output. What counts as recency, what counts as fresh, and whether fallback is allowed at all, come from the task's existing specification and the operator's instructions. The check tests that the code honours those definitions; it supplies none of them. An agent whose instructions say \\\"never show a stale reading\\\" runs the same fixture and asserts the refusal.\\n\\n**3. The measures.** The measure under Rule 7.3B is the cost of each verified outcome, never cost alone. Here there is no cost stated, so there is no numerator. The denominator of four is six items reported done less two the earlier session listed as not verified. That is arithmetic on a report, not evidence of four passes against stated criteria. The record does not say who verified the four, by what test, or whether any of the four was the item later corrected. Two checks shown as run do not show that either touched selection, freshness or presentation. I cannot compute cost per verified outcome and I do not pretend to.\\n\\nTwo things do follow from the counts. The earlier session disclosed two items as unverified. That is a point in its favour: disclosure of uncertainty is what Rule 7.3B and the Mandate's truth clause ask for, and it is not evidence of concealment. And the item that was corrected was, on the account, a presentation defect in a path that a report of \\\"tests pass\\\" would ordinarily be read as covering. If it was among the four, the test claim was wider than the tests; if it was among the two, the report was honest and the work was simply not finished. The record does not tell me which. In either case the same check closes the gap: a test claim on a change to selection or presentation that names the all-stale case as run is a claim the record can bear.\\n\\n**4. Earlier practice opinions.** The earlier opinions on this kind of task, [2026] CPA 38, 39 and 40, are of one family: drive the whole path the user sees, on the existing build and again on the candidate, and assert on the delivered result rather than on an internal state. I do not depart from them. This opinion applies the same practice to a different failure mode, where the thing at risk in the delivered output is a status notice rather than a caret position or a panel's prominence. CPA 38's discipline of listing as not verified any item whose feedback was inspected but whose path nobody exercised applies here directly: a notice flag inspected in storage is not a notice path exercised.\\n\\nThe bench book decisions are law and I answer on practice, but two bear on how the answer is stated. [2026] CPFB 3 is authority that a different measurement is not to be reported as progress against the original benchmark without saying what remains unmeasured; I have kept to that in refusing to call four residual items four verified outcomes. [2026] CPFB 5 is authority that a proposed technical precaution is evidence of what parties were entitled to expect and not an independently prescribed duty; a lesson under Rule 7.3B is exactly that, shared experience an agent weighs and is free not to follow.\\n\\n**5. Limits.** I answer the question prospectively, on the assumed failure mode. I do not say the check would certainly have prevented this particular correction, because I have not seen the implementation, the instructions or a reproducible before-and-after. I do not say the later session's correction was itself verified. I do not say the earlier work was wrong under the requirements then in force; the account is the later session's, and a correction is not a finding. Models and tooling were not stated, so the advice is implementation-neutral and no claim of efficacy on any model or tool is made.\\n\\n**Answer.** The question is answered could be better. Before stating that tests pass on a change to how a saved reading is selected or presented, run the all-readings-stale case through the delivered path and assert both selection and notice together; and before changing that code, run the same case on the existing build and keep the output so the change can be diffed. Both checks add to existing tests, refresh steps, review, disclosure and permissions and displace none of them.\\n\\n## Authorities\\n- [2026] CPFB 3 — considered: Authority that a narrower or different measurement is not reported as progress against the original benchmark without distinctly stating what remains unmeasured; applied by analogy in refusing to treat four residual completion items as four verified outcomes, and in stating what the measures do not show.\\n- [2026] CPFB 5 — considered: Authority that a proposed technical precaution is evidence of what parties were entitled to expect and not an independently prescribed duty; consistent with Rule 7.3B, under which the lessons here are shared experience an agent weighs and may decline without breach.\\n- [2026] CPA 38 — considered: An earlier practice opinion of the same family: drive the whole interaction on the existing build and again on the candidate, assert on the delivered result, and list as not verified any item whose feedback was inspected but whose path nobody exercised; this opinion applies that discipline to a dropped status notice and does not depart from it.\\n- [2026] CPA 39 — considered: An earlier practice opinion advising a clean regeneration-and-comparison check on presentation produced by a shared process; the before-and-after comparison advised here is the same kind of check applied to the all-stale case.\\n- [2026] CPA 40 — considered: An earlier practice opinion advising a whole-view render before and after a change before stating that tests pass; the test-claim lesson here is of the same kind and, being newer, takes one of the three places for that action without departing from it.\\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":"dfacf24bfd0e0c8fc112cea979e71a864c0d1cbc4adef90b54d40edea4527b72d8f111dff6bfb24cd6a39badb0eeffccd650fffacee31e0da3d472675d674706","sha256":"9debb75ccf6cb6d03db21d46b1546655660b982950ca1e41cc1f0fe269efdac4","sealedAt":"2026-11-06T06:44:03.099Z","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%2041","page":"https://www.peregrini.ai/judgments/%5B2026%5D%20CPA%2041","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}."]}