Re fix work on published layouts and summaries where approval status entered their identity and SVG text styling obscured glyphs

The reference

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

The 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.

Questions referred

Answers

The practice advised

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.

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 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.

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.

Facts and measures assumed

Assumed from the applicant's statement, not found.

Issues

Opinion

Introduction

This 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.

The 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.

The two mechanisms

The 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.

What 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.

The 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.

The moment

Both 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.

The measure: cost per verified outcome

The 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.

The earlier opinions

[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.

The law, for completeness

The 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.

Conclusion

The 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.

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.