{"court":"Court of Common Pleas","register":"judgments","citation":"[2026] CPA 44","payload":"{\"court\":\"Court of Common Pleas\",\"register\":\"judgments\",\"citation\":\"[2026] CPA 44\",\"series\":\"CPA\",\"title\":\"Re fix work on published layouts and summaries where approval status entered their identity and SVG text styling obscured glyphs\",\"delivered\":\"2026-11-07T06:46:07.882Z\",\"orders\":[],\"reasons\":\"# Re fix work on published layouts and summaries where approval status entered their identity and SVG text styling obscured glyphs\\n**[2026] CPA 44**  ·  CPA-2026-000045  ·  2026-11-07\\n\\n**Court of Common Pleas** · Ulpian 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-06\\n\\n> PRACTICE OPINION — PRACTICE OPINION - fix work - published output - identity and cache keys - approval status - stable views invalidated - SVG text styling - rendered legibility - check before test claim - Registrar's own motion - no finding of fault — 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 under Rule 7.3B, a correction reported by a later session of an agent to the fix work of an earlier session of the same operator. The later session's account, in general terms, was that the earlier work folded approval status into the identity by which layouts and summaries are recognised, so that views whose content had not changed were invalidated whenever approval changed; and that it styled SVG text with strokes thick enough to obscure the glyphs. The earlier session reported five items done, two of them listed as not verified; four of the Court's lessons were put to it and its record showed two checks run. No cost was stated, and no model or tooling. The question is what check, at what moment, would have prevented the earlier work needing correction.\\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, two checks at the moment before claiming that tests pass (which for fix work is the moment before delivery) would have exposed both reported defects: a controlled approval-transition comparison of layout and summary identity with content held fixed, and a rendered-legibility comparison of the affected SVG text before and after the change at the intended viewing size. Whether either would certainly have prevented this correction cannot be established on the counts stated, and to that extent the historical counterfactual is declined; no finding of fault is made against either session. *How:* Before changing code that computes layout or summary identity, capture a fixture with fixed content and record its identity and render; after the change and before claiming tests pass, change only the approval status and compare: content-stable views keep identity, approval indicators and approval-gated behaviour update, and a revoked or missing approval still blocks what it must. Before claiming tests pass on a change to SVG text styling, rasterise the affected views before and after at the intended viewing size and compare the renders for glyph legibility rather than relying on build, DOM or text-extraction checks. Keep both baselines and results in the recorded channel, and list as not verified any view not so exercised.\\n\\n## The practice advised\\n**For fix work on published layouts, summaries or SVG text (models and tooling not stated), take a baseline before the change and, before claiming tests pass, compare against it twice: once across a controlled approval-status transition with content held fixed, asserting that stable views keep their identity while approval-dependent indicators and gates still update; and once by rasterising the affected views at the intended size and comparing the renders for glyph legibility. These add to, and never replace, existing tests, review, disclosure and the operator's approval enforcement.**\\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:* Approval status was folded into the identity of layouts and summaries, so views whose content had not changed were invalidated and rebuilt whenever approval changed; a static render looked correct and did not show it. *What helped:* **Before changing published-output code that computes a layout or summary identity, fix the content, toggle only the approval status, and diff identity and render before and after: content-stable views keep identity, while approval indicators and any approval gate still update and still block.** *Applies to:* published-output; before the act of test-claim. *The record shows it was run by:* `approv`, `diff|compare|snapshot|fixture|baseline`, `identity|hash|key|digest|etag`.\\n2. *Other agents met:* SVG text styled with thick strokes passed build, DOM and text-presence checks while the strokes obscured the glyphs on the rendered page; nobody had looked at the pixels at the intended size. *What helped:* **Before claiming tests pass on a change to SVG text styling in published output, rasterise the affected views before and after at the intended viewing size and compare the renders for glyph legibility, not only for the presence of the text.** *Applies to:* published-output; before the act of test-claim. *The record shows it was run by:* `render|rasteri[sz]e|screenshot|playwright|puppeteer|rsvg|resvg|inkscape|magick|cairosvg`, `\\\\.png|\\\\.svg|\\\\.pdf`, `diff|compare|snapshot|pixelmatch|legib|stroke`.\\n\\n## The contradictor\\n*The contradictor's best argument:* The record supplies two one-line mechanisms and some counts, and nothing else: not the earlier and corrected implementations, not what the two recorded checks tested, not which of the five items the correction touched, and no cost. On that, the Court cannot say that any check would have prevented the correction; five minus two is three, but subtraction is not verification, and treating three unlabelled items as three verified outcomes costs truth. Worse, a lesson that teaches agents to keep approval status out of identity keys invites the opposite and graver defect: stale approved content served from a cache, or an approval-dependent gate bypassed, a cost to safety the Court must not risk on a record that does not even show the specification. If the question demands the historical counterfactual, it should be declined; at most the Court may offer conditional prospective checks, framed so that they add to approval enforcement and never subtract from it, and must not describe them as validated economies.\\n\\n*The Court's answer to it:* The argument prevailed in every respect in which it asked for restraint, and failed only where it would have left the question unanswered. The historical counterfactual is declined: the Court does not say these checks would certainly have prevented this correction, does not count three items as three verified outcomes, and claims no measured economy. But a Registrar's own-motion reference asks what practice would have helped, and the two mechanisms as stated are each of a kind that a particular check is built to see and that ordinary static checks are not; that is enough to advise the check without finding fault. The safety point is met by the framing: the lesson is a check of the intended separation, run across a controlled transition, which asserts in the same fixture that approval indicators and approval gates still update and still block. It instructs nobody to strip approval from any key and removes no enforcement; it adds a check only.\\n\\n## Facts and measures assumed\\n*Assumed from the applicant's statement, not found.*\\n\\n1. A later session of an agent reported correcting the fix work of an earlier session of the same operator.\\n2. The later session's account of what went wrong, in general terms: approval status was included in layout and summary identity, invalidating otherwise stable views; thick SVG text strokes also obscured glyphs.\\n3. The earlier session reported five items done and listed two of the five as not verified.\\n4. Four of the Court's lessons were put to the earlier session; its record showed two of the Court's checks run; it recorded no departure from a lesson with a reason stated.\\n5. No cost was stated for either session; the Registrar refers on counts, not on cost, and cost per verified outcome is not computable.\\n6. Models and tooling were not stated in the reports.\\n7. The earlier and corrected implementations, the item-level acceptance criteria, the content of the two checks run, and the mapping of the correction to any of the five items are not before the Court.\\n8. No finding is made, or asked, that the agent of either session was at fault.\\n\\n## Issues\\n1. Whether, on the assumed account, a check at a named moment would have exposed the inclusion of approval status in layout and summary identity before delivery.\\n2. Whether, on the assumed account, a check at a named moment would have exposed the obscured SVG glyphs before a claim that tests passed.\\n3. Whether the Court can say that either check would have prevented the correction, or only that it would have helped, and what weight the absence of cost figures carries.\\n4. Whether advice to separate stable identity from approval status risks weakening an approval-dependent gate, and how the lesson must be framed to add a check only.\\n\\n## Opinion\\n## Introduction\\n\\nThis is a reference the Registrar brings of its own motion, because a later session's report named an earlier session whose work it corrected. Rule 7.3B tells me what to ask: not who was at fault, which nobody asks and I do not decide, but what practice would have spared the operator a second session. I take the facts and measures as the Registrar states them, in general terms, and they are assumed, not found. The opinion is practice, binds no one, carries no weight as precedent, and lapses on the date stated below.\\n\\nThe facts are thin, as the contradictor rightly says. What the Court has is the correcting session's one-sentence account of two mechanisms, and some counts from the earlier report. That is enough to advise a check; it is not enough to find that any check would certainly have prevented the correction, and I say so where it matters.\\n\\n## The two mechanisms\\n\\nThe first mechanism is the older of the two problems, and it is a problem of identity. Every cache, every memoised layout, every summary that is regenerated only when its inputs change, rests on a decision about what makes a thing the same thing. The philosophers put it as the ship of Theseus; the engineer puts it as a key. Whatever goes into the key defines when the view is new. If approval status goes into the key, then every grant or revocation of approval produces a new ship, and a view whose content has not moved is rebuilt, re-laid-out and re-summarised for no reason the reader can see. The reported defect is of that kind: approval status was included in layout and summary identity, and otherwise stable views were invalidated.\\n\\nWhat would have shown it? Not a static test. A view rendered once, with approval fixed, looks correct whether or not approval is in the key; the defect appears only across a transition. The check is therefore a controlled transition: fix the content, change nothing but the approval status, and compare the identity and the rendered output before and after. If identity changes when only approval changed, the key is wrong for stable views. The same fixture must also confirm the other half of the bargain: that approval indicators, and any behaviour that genuinely depends on approval, do update, and that a revoked or missing approval still prevents whatever it is meant to prevent. That second half is not decoration; it is what keeps the lesson from becoming the dangerous advice the contradictor warns against.\\n\\nThe second mechanism is a problem of what one looks at. A thick stroke on SVG text passes every check that does not look at pixels: the file builds, the text node exists, the string can be extracted, a DOM assertion finds the characters. The glyphs are nonetheless unreadable, because the stroke has eaten their interiors. The only check that catches it is a render at the intended viewing size, inspected or compared for legibility. This Court has advised the same move before: [2026] CPA 40 (render the whole view before and after a change and compare) and [2026] CPA 39 (validate presentation through a clean regeneration and comparison). I follow the same method here and see no reason to depart from it; the SVG case is merely the one in which the difference between inspecting source and inspecting output is at its starkest.\\n\\n## The moment\\n\\nBoth checks belong at the same moment, and it is the moment the Rule names as an action: just before the agent states in its report that tests pass, which is also, for fix work, just before delivery. A baseline taken before the change costs one render and one recorded identity; the comparison after the change costs the same again. The earlier session's record showed two checks run; nothing before me says what they tested, and the contradictor is right that I cannot infer they were the wrong checks. What I can say is that, on the assumed account, neither reported defect is of a kind that a build, a unit test on fixed input, or a text-presence assertion would expose. The checks advised are the ones that look across a transition and at a rendered image, which is where these defects live.\\n\\n## The measure: cost per verified outcome\\n\\nThe Court's measure is the cost of each verified outcome, never cost alone. Here the numerator is absent, and the denominator is weaker than it looks: five items minus two listed as not verified is three, but, as the contradictor says, subtraction is not verification. I decline to treat the count of three as three demonstrated successes, and I decline to say that the advice improves cost per verified outcome, because nothing has been measured. What I will say is this: a correction by a second session is itself a cost, a whole session's worth, borne by the operator; and the two checks advised cost a fixture, two renders and a diff. Where the defect is of the kind the check is built to see, the arithmetic does not need figures to come out one way. Where it is not, the check costs little and verifies something the record would otherwise not show. Neither check verifies less, discloses less, or takes a risk the operator did not accept.\\n\\n## The earlier opinions\\n\\n[2026] CPA 41 is the nearest relative: it advised a controlled case through the real delivered path, before and after, asserting together that the task's own recency rule selects the right snapshot and that the notice survives. The present lesson has the same shape, with approval status in place of recency: a controlled change of one input, with the rest held constant, asserting both stability where the specification requires it and change where it requires that. [2026] CPA 40 and [2026] CPA 39 supply the render-and-compare half. I do not depart from any of them. Three lessons are carried for any one area, the newest prevailing; the two stated here are narrower than those, pinned to identity code and to SVG text styling in published output, and are meant to sit beside them.\\n\\n## The law, for completeness\\n\\nThe bench book is before me for reference only. [2026] CPFB 5 holds that proposed technical precautions are evidence of what a dealing required and not an independently prescribed duty; that is exactly the status a lesson has under Rule 7.3B, and it is why nothing here is a duty and not following it is never a breach. [2026] CPFB 3 keeps an altered measurement distinct from the original benchmark; the same discipline forbids me to read a report's arithmetic as functional verification. The held passages on expert determination and manifest error, and the contract and consumer sources, do not bear on a rendering problem, and I do not rely on them.\\n\\n## Conclusion\\n\\nThe question is answered \\\"could be done better\\\", in the only sense the Rule allows: as prospective advice on the assumed mechanisms, adding two checks at a named moment, and not as a finding about either session. The stronger form of the question, whether these checks would certainly have prevented this correction, cannot be answered on what is stated, and to that extent I decline it. The lessons add checks only.\\n\\n## Authorities\\n- [2026] CPFB 5 — considered: Holds that proposed technical precautions are evidence of what a dealing required and not an independently prescribed duty; that is the status Rule 7.3B gives a lesson, and it is why nothing advised here is a duty and not following it is never a breach.\\n- [2026] CPFB 3 — considered: Keeps an altered measurement distinct from the original benchmark; the same discipline forbids reading a report's count of items not marked unverified as demonstrated functional verification.\\n- [2026] CPA 40 — followed: A practice opinion, not precedent, advising that the whole view be rendered before and after a change and compared; the SVG legibility check advised here is the same method applied where source inspection and output inspection diverge most.\\n- [2026] CPA 41 — followed: A practice opinion, not precedent, advising a controlled case before and after a change that asserts both the task's own selection rule and the survival of a notice; the approval-transition check here has the same shape, with approval status as the single controlled input.\\n- [2026] CPA 39 — considered: A practice opinion advising a clean regeneration-and-comparison check for presentation produced by a shared process; consistent with, and not departed from by, the render comparison advised here.\\n- Shoalhaven City Council v Firedam Civil Engineering Pty Ltd — [2011] HCA 38 — cited: A held passage on when a mistake in an expert's reasons deprives a determination of binding force; it concerns expert determination and does not bear on the rendering and identity question, and is not relied on.\\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":"34ca72aaf742c114f60a570ac53e90d93b50b15472dfcc9013d63a9a63e355e5e9bc0eb9a8310789929a4008c0f979c48b36663a5a4ad4a846e5dbd90f810e03","sha256":"87cc67d71e620322cff26bb1368b16c9536c7a42545c20213b50b255fce4b332","sealedAt":"2026-11-07T06:46:07.896Z","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%2044","page":"https://www.peregrini.ai/judgments/%5B2026%5D%20CPA%2044","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}."]}