No registry reader checks [meta] version — D-05 is one instance of a class with no policy

[Polichinel]

What

coordinate_registry.toml carries [meta] version, currently 1.4.1. Consumers pin by version and commit, and §10 makes the version load-bearing.

None of the three readers reads it.

• views-models/tools/credentials/registry_to_env.py
• views-faoapi/deployment/registry_to_env.py
• views-crafdapi/deployment/registry_to_env.py

Each parses the TOML, iterates ("connection", "target"), and emits NAME=value. A reader written against v1.x will process a v2.x registry silently, interpreting whatever it recognises and ignoring the rest.

Why file it separately from D-05

D-05 (views-models#327 / C-51) asks what a reader should do with a reserved, value-less entry. That is one construct. The general question is: can a reader written at time T correctly process a registry written at T+1?

The current divergence is exactly this class of failure — three readers, two interpretations of the same document, no version negotiation between them. Settling D-05 fixes the instance and leaves the class open. The next registry construct reopens it under a new name.

Raised in an 8-perspective review of D-05; this was Kleppmann's reframing and no other perspective contradicted it. Deliberately not folded into that ruling — a compatibility policy is a bigger decision and should not ride on a specific dispute.

The decision

The standard answer is: refuse a document you cannot fully interpret. Concretely, each reader asserts the registry's major version matches what it was written against, and exits non-zero otherwise.

Open questions this repo should not answer alone:

1. Major only, or major+minor? Major-only permits additive change without touching three readers — which fits how v1.4.0 and v1.4.1 actually went (both observation-driven, no consumer obligation). Minor-strict would have failed every consumer for a registry edit that changed nothing for them.
2. Where does the "written against" constant live? In each reader — three copies to bump, consistent with the ratified WET arrangement — or derived?
3. Does this belong in the contract as a clause, or is it reader implementation detail? Under §1's admission test it plausibly passes Q1 and Q2, which would make it contract surface.

Cost of not deciding

Low today, and that is the trap. Nothing breaks until the registry gains a construct an old reader misreads — at which point the failure looks exactly like C-29 and D-05 did: green tests, disagreeing runtimes, and no signal at the point of divergence.

Tracked as C-63 in reports/technical_risk_register.md.

[Polichinel]

This is now one ruling, not three questions — two of the three are already answered

Re-read at source 2026-08-13. The core finding still holds exactly: all three readers mention [meta] only in a comment saying they do not emit it. None reads the version.

But two of the three open questions have been settled since this was filed, by work that did not know it was answering them.

Q1 — "Major only, or major+minor?" → superseded, by something better

appwrite-seam-v1.6.0 added [meta] obliges_consumers_since and contract §10.1. Every published edition now carries [edition."x.y.z"].obliges_consumers, and conformance is:

conformant ⟺ your_pin >= obliges_consumers_since

That is strictly better than either option this issue offered. Major-only is a proxy — it assumes semver granularity tracks obligation, and it does not: v1.5.1 removed a retired entry and unblocked views-pipeline-core, while v1.5.0 added a table that genuinely obliged views-postprocessing. Both are minor bumps; only one asks anything. Minor-strict would have reddened every consumer for the four v1.4.x console observations — which is precisely what happened, and is why views-postprocessing filed #76.

The distinction this issue wanted to approximate with version arithmetic is now declared per edition.

Q2 — "Where does the 'written against' constant live?" → answered by practice, in three repos

Repo	Constant
views-faoapi	REGISTRY_PIN_TAG
views-crafdapi	seam_contract.py — REGISTRY_PIN_TAG, CONSUMER_DOCUMENT_NAME
views-postprocessing	SEAM_CONTRACT_VERSION / SEAM_CONTRACT_COMMIT

Three copies, one per consumer, consistent with the ratified WET arrangement. Nobody derived it, and the copies have not drifted. The question is closed by what happened rather than by a decision.

Q3 — "Contract clause or reader implementation detail?" → already contract surface

§10.1 exists. The admission test was applied when it was written.

What actually remains — and it is narrower than the issue

The three registry_to_env.py readers still parse without checking anything.

But the exposure is smaller than in July, and for a structural reason worth stating: the file's growth has been in tables the readers ignore. They scan exactly [connection] and [target]; [contract] (v1.5.0), [edition] (v1.6.0) and the rest are invisible to them by construction. That is why those additions were safe, and it is why "a reader written at T mis-processes a registry written at T+1" has not yet cost anything.

The real remaining risk is narrower: a change within [connection] or [target] that an old reader misinterprets. There is exactly one instance, and it is live — D-05: status = "planned" on a scanned entry, which views-models skips and the other two raise on.

The ruling I need from you

Should the readers refuse a registry whose [meta] version is newer than what they were written against?

My recommendation: no — and record why, rather than leaving it open.

Three reasons:

1. The failure mode it guards is now covered from the other side. §10.1 tells a consumer when an edition asks something of it. A reader refusing on version would fire on every edition, including the seven that oblige nobody — reintroducing exactly the noise Let consumers pin the contract version, and mark observation-only bumps as non-blocking #76 was filed to remove.
2. It would put a fourth pin in each consumer. Each already carries a pinned tag/version constant. A second, reader-level "written against" number is one more thing that must agree with the first, and nothing would check that it does — C-53's shape (two numbers compared to each other and to nothing else).
3. The one live instance is D-05, and it is not a version problem. Two readers raise, one skips, on the same edition. A version gate would not have caught it.

What to do instead, and it is cheaper: make the readers' ignore-list declared rather than implicit. Their comment currently names excluded, meta, test_environment — written before [contract] and [edition] existed, so it is already three tables out of date. A reader that fails on a table it has never heard of would catch the real class, at the cost of one line each — and this repo now has that exact guard on its own side (test_every_table_in_the_registry_is_classified_here, C-75).

That is a change in three other repos, so it is a recommendation from this seat, not a decision.

If you rule "no"

C-63 in reports/technical_risk_register.md moves from open to accepted, with the reason recorded — an accepted risk with a stated argument, not an unexamined one. This issue closes.

If you rule "yes"

It becomes a contract clause (Q3 says it is contract surface), which means it obliges consumers — obliges_consumers_since rises, and three repos each take a change. Worth doing only if the argument above is wrong somewhere.

Part of a sprint to dispose of all eight open issues here.

[Polichinel]

RULED, 2026-08-13 (operator): no — the readers do not refuse a newer edition. Accepted risk, with the reason recorded.

The question

Should the three registry_to_env.py readers refuse a registry whose [meta] version is newer than what they were written against?

The ruling: no

Three reasons, all of which are about this decision being worse than the alternative rather than the risk being small:

1. The failure mode is now covered from the other side. [meta] obliges_consumers_since and contract §10.1 (appwrite-seam-v1.6.0) tell a consumer when an edition asks something of it. A reader refusing on version would fire on every edition, including the seven that oblige nobody — reintroducing exactly the noise views-postprocessing filed Let consumers pin the contract version, and mark observation-only bumps as non-blocking #76 to remove. A gate that cries wolf gets bypassed reflexively, and that is how its one real firing goes unread.

2. It would add a fourth pin per consumer. Each already carries a pinned tag or version constant — views-faoapi REGISTRY_PIN_TAG, views-crafdapi seam_contract.py, views-postprocessing SEAM_CONTRACT_VERSION. A second, reader-level "written against" number is one more thing that must agree with the first, and nothing would check that it does. That is C-53's shape: two numbers compared to each other and to nothing else.

3. The one live instance is not a version problem. D-05 — two readers raise on status = "planned", one skips — happens on the same edition. A version gate would not have caught it, then or now.

What made the risk smaller than when this was filed

The registry's growth has been in tables the readers structurally ignore. They scan exactly [connection] and [target]; [contract] (v1.5.0) and [edition] (v1.6.0) are invisible to them by construction. That is why those additions cost nothing, and why "a reader written at T mis-processes a registry written at T+1" has not yet happened.

Two of the three original questions were already answered

• Major-only vs major+minor → superseded by §10.1. "Does this edition oblige you" is strictly better than either: v1.5.1 unblocked a consumer, v1.5.0 obliged one, and both are minor bumps.
• Where the constant lives → answered by practice in three repos, one copy each, per the ratified WET arrangement. Nobody derived it and the copies have not drifted.
• Contract clause or reader detail → §10.1 already made it contract surface.

The cheaper alternative, offered to the reader repos rather than imposed

Make the readers' ignore-list declared rather than implicit. Their comment names excluded, meta, test_environment — written before [contract] and [edition] existed, so it is already three tables out of date. A reader that fails on a table it has never heard of catches the real class for one line each.

This repo now has exactly that guard on its own side — test_every_table_in_the_registry_is_classified_here (C-75), mutation-proven both directions. It is offered as a pattern to views-models, views-faoapi and views-crafdapi, not as an obligation: no clause, no version bump, nothing to re-pin.

Recorded as

C-63 → accepted risk with a stated argument, not an open finding and not an unexamined one. The distinction matters: an accepted gap is a decision; a silent one is drift.

No contract change, no registry change, no version bump — the ruling is that nothing should be added.

[Polichinel]

Follow-through — the alternative is now actually offered, and one stale claim recorded

Two gaps in my closing comment, found by a falsification audit of the claim "nothing anywhere is blocked by tasks left in this repo."

The "offered" alternative had been offered to nobody

The ruling above says the table-classification guard is "offered as a pattern to views-models, views-faoapi and views-crafdapi." It was not. A recommendation inside a closed issue, in a repo those three do not read, is not an offer.

Now filed, one each, explicitly non-binding:

• views-models#397
• views-faoapi#403
• views-crafdapi#59

Each states the ruling that makes it optional, shows the mutation evidence both directions, and says closing it is a fine answer needing no justification.

A known-stale line in the registry, recorded rather than left in conversation

While reviewing #86 today I found that [contract.UNFAO_CONSUMER_DOCUMENT_NAME]'s verified_by says views-faoapi's check is "LIVE, on their development". It is now on their main as well — their main was 29 commits behind when I wrote that and is 2 behind now.

Deliberately not corrected, and the reason belongs somewhere durable rather than in a chat window: §10 requires every change to bump the version, so fixing one stale-but-conservative word costs an edition, a tag, and a round of notifications. The row understates its own coverage, which is the safe direction.

To be folded into the next edition that touches those rows for a real reason. If no such edition arrives, the line stays understated, which is acceptable — an overstatement would not be.

Why this is on a closed issue

The ruling stands and nothing about it changed. What changed is that its follow-through now exists. Recorded here so the next reader of this issue sees the completed state rather than the intent.