DR-139: An invariant, and a production consumer, are not reasons to keep something incorrect

DR-139 — An invariant, and a production consumer, are not reasons to keep something incorrect

Context

DR-104 ruled that code is evidence of what exists, never of what is correct, and listed the readings that look like diligence and are not — consumer-counting, population in either direction, grep absence. DR-123 extended that to task files: a goal, an AC, an owner-directive or an invariant records that someone decided, not that they re-derived.

S545 hit both limits from the other side. Repeatedly, the thing blocking a correct answer was not a missing measurement but a preserved one: an invariant authored by the same task that built the mechanism it constrains (_select_existing_canonical_roster carries a fix, ID-81.9, for a bug the mechanism itself created); a parity contract whose counterparty had been deleted; a closed concept-type vocabulary that three separate later needs had to route around with facet tags rather than reopen. In each case the mechanism survived because something asserted it should, and nobody was licensed to ask whether the assertion had outlived its moment.

The owner ruled on both halves in one message.

Decision

An invariant is evidence of intent at a point in time, never of correctness. Owner, S545:

“An invariant could have been written at a different point in time of the platform. So be careful in terms of holding us to invariants which may no longer be valid.”

And pre-launch, having consumers is not a reason to preserve something wrong. Owner, S545:

“We should also be open to the fact that if functionality or schema changes are required and they would improve the quality of the product, then of course we should be considering this as part of any decisions that we make — the platform is in development, so similar to ‘0 rows’, not changing something which is incorrect, even if it has ‘production’ consumers, would be detrimental.”

So the DR-123 list gains Inv-N, and DR-104’s “N callers, so it is live” trap gains a converse: N callers, so we must not change it is equally not evidence. Schema change is in scope when the current shape is the defect.

And the same carrier logic reaches the north-star set. Owner, S545, on being asked what the doctrine says about a mechanism the doctrine was written alongside:

“What does the doctrine say about this, but also keep in mind, the doctrine was written based on the platform’s current entity config.”

DR-104 says ratified docs outrank code, and DR-106 names the doc families that are not ratified authority. Neither covers the third case: a ratified doc authored while the configuration under investigation already stood is that configuration’s carrier, not independent evidence that it is correct. The doc records what was true and what was decided; it does not re-derive whether the thing should have been that way. DR-123 line 7 already says to treat contemporaneous docs as a concept’s carrier — this confirms the rule fires on the reference set, not only on task files.

Alternatives considered

• Leave invariants under DR-123’s “owner-directive” clause. Rejected: DR-123 enumerates goal text, ACs, owner-directives and invariants as a list, but sessions consistently read Inv-N as a stronger object than the surrounding prose — it looks like a proof obligation rather than a record. It needed naming.
• Scope the change-freely half to code only, excluding schema. Rejected by the owner’s own wording (“functionality or schema changes”). A migration is cheaper pre-launch than at any later point, and treating the schema as fixed is what produced three separate homes for “which certifications do we hold”.
• Wait until launch to relax this. Rejected: it inverts. The licence is because the platform is pre-launch; it narrows at launch, it does not widen.

Consequences

• A verdict may not rest on “Inv-N says so”. Name the invariant’s authoring task and date, and say whether a current source re-affirms it. Where none does, the invariant is UNDECIDABLE, not satisfied.
• Sub-agent dispatch briefs inherit this — the DR-123 required-lines block in CLAUDE.md should carry the invariant clause and the production-consumer clause alongside its existing not-evidence list.
• Paired with DR-104’s population rule, the pre-launch evidence posture is now symmetric: emptiness proves nothing, population proves nothing, and consumption proves nothing.
• This is a licence to change, not a licence to skip measurement. DR-104’s requirement to measure before retiring, renaming or ratifying is untouched — the change still has to be shown correct, it just no longer has to be shown permitted.