ADR-017 D5: lift the UNFAO_CONSUMER_DOCUMENT_NAME 'not yet an authority' caveat once both sides self-check

[Polichinel]

Filed by the views-faoapi (consumer) seat, to give the final step of the ADR-017 delivery-name loop a home. I changed nothing in this repo — issue hygiene only.

What

[contract.UNFAO_CONSUMER_DOCUMENT_NAME] (added in #75, appwrite-seam-v1.5.0) deliberately carries a self-deprecating caveat in its verified_by:

⚠ NEITHER IS IN PLACE YET. Until the consumer-side check lands, this row is a string a human typed, and a producer-side check against it would prove only that two values this platform authored agree with each other… Stated here because this row will look authoritative long before it is.

That caveat is correct today and must not be removed early. But nothing tracks removing it once it stops being true — so the row would sit understating its own authority indefinitely (or worse, someone lifts it prematurely). This issue is that tracked step.

D5 — flip the row to a real authority, once (and only once) both sides self-check

When both independent readers exist:

• views-faoapi#379 (D2) — consumer self-checks its filter name against this row, in CI; and
• views-postprocessing#238 (D3) — producer self-checks its CONSUMER_DOCUMENT_NAME mirror against this row, in CI

then the row is verified by two independent parties reading a public authority (not two platform-authored strings agreeing with themselves). Update the verified_by note to drop the "NEITHER IS IN PLACE YET" warning and record that both checks are live, with a version note (§10). That is the moment the invisible-delivery failure is actually closed for FAO.

Gate

Do not action until both views-faoapi#379 and views-postprocessing#238 are merged. Until then the caveat is accurate and stays.

Scope note

FAO only. The CRAF'd row is not declared yet (#75 is FAO-only by design; views-crafdapi#39), so its own authority-flip is a separate future step, not this one.

Cross-refs: #75 (D1, the row), views-faoapi#379 (D2), views-postprocessing#238 (D3/D4).

[Polichinel]

First gate met. views-faoapi#379 (D2) has merged (PR #382): faoapi verifies its filter name against [contract.UNFAO_CONSUMER_DOCUMENT_NAME] at tag appwrite-seam-v1.5.0 in CI. One of the two independent readers this issue waits on now exists. D5 (lifting the "NEITHER IS IN PLACE YET" caveat) still gates on the producer side, views-postprocessing#238 (D3).

[Polichinel]

Status check, verified in the siblings' code today rather than read off issue text.

Half unblocked

Side	Issue	State
consumer, FAO	views-faoapi#379	CLOSED 2026-08-11 — tests/test_seam_contract_binding.py is live
consumer, CRAF'd	views-crafdapi#53	filed today, alongside the new row
producer, both	views-postprocessing#238	still open

What this issue asks for is not yet satisfiable

The caveat this issue exists to lift is "not yet an authority", and lifting it requires both sides self-checking. One side is live.

Until views-postprocessing#238 lands, views-postprocessing verifies its mirror by reading the consumer's source — the exact mechanism the registry row exists to retire. So the row remains a one-sided authority and the caveat must stay.

The caveat has been narrowed rather than left stale

v1.5.2 rewrote the FAO row's verified_by. It previously read "⚠ NEITHER IS IN PLACE YET", which stopped being true at 03:27 this morning. It now records the consumer half as live, names what that check does well (immutable-tag pin, fails-in-CI rather than skipping), and states plainly that the producer half is open.

That is deliberate: one side landing makes a row look finished when it is half finished, and a stale caveat is the way that goes unnoticed.

Scope grew by one row

v1.5.2 added [contract.UNCRAFD_CONSUMER_DOCUMENT_NAME], so this issue now governs two rows, not one. Both carry the same verified_by structure and both are waiting on the same producer-side issue.

Remaining condition to close this: views-postprocessing#238. Nothing else, and nothing further is owed from this repo.

[Polichinel]

Handoff note for when D5 is actioned (from the views-faoapi seat)

Gate: D2 ✅ (views-faoapi#379 merged) + D3 (views-postprocessing#238, in flight). Action D5 only once both independent readers exist — do not lift early.

The exact edit: in docs/ADRs/platform/coordinate_registry.toml, the [contract.UNFAO_CONSUMER_DOCUMENT_NAME].verified_by field carries the ⚠ NEITHER IS IN PLACE YET … block. Once both checks are live, replace that block with a statement that both readers exist (consumer: views-faoapi#379 / tests/test_seam_contract_binding.py; producer: views-postprocessing#238). That flips the row from "a string a human typed" to a real authority verified by two independent parties.

🔊 Re-pin-cascade flag — please avoid one if you can. The un_fao value does not change here; this is a verification-status prose edit, not a contract amendment. Both current readers are pinned to edition 1.5.0 (appwrite-seam-v1.5.0): faoapi reads the value at that tag via git show (immune to later editions), and views-postprocessing has an edition-compare test (test_the_pinned_contract_edition_still_matches_the_registry) that asserts [meta].version == its pinned 1.5.0. So if D5 bumps [meta].version to 1.6.0 and cuts a new tag, postprocessing's build goes red until it re-pins, and faoapi may (not must) re-pin. Prefer lifting the caveat without a [meta].version bump (a verification-status field is not the contract value); if your §10 lockstep discipline forces a bump, coordinate the re-pins across faoapi + postprocessing in the same window. This is your design call — flagging so it isn't a surprise.

The loop: D1 ✅ (#75, this row) · D2 ✅ (views-faoapi#379) · D3+D4 (views-postprocessing#238) · D5 = this. Lifting the caveat is the step that makes the invisible-delivery failure fully closed of record for FAO.

[Polichinel]

D5 reviewed — the gate blocks it, and the request is written against a stale edition

A work request arrived from the views-faoapi seat asking views-appwrite to lift this row's "not yet an authority" caveat (ADR-017 D5). Reviewed against the code in all three repos. No edit made. Recording the review here because this issue is where D5 lives.

1 · The gate fails, by their own rule

Their instruction is explicit:

"D3 (views-postprocessing#238): must be MERGED first... If #238 is still open, STOP: the caveat is still accurate. Do not lift."

views-postprocessing#238 is OPEN. So: stop. The producer half is not in place, the row is still one-sided, and the caveat is still true.

2 · The edit they describe was already made, four hours before they filed

They ask us to find the block reading "⚠ NEITHER IS IN PLACE YET…" and replace it.

That text no longer exists. v1.5.2 rewrote it this morning, when views-faoapi#379 merged (PR #382, 03:27 UTC — verified). The row now records:

• consumer half live, naming tests/test_seam_contract_binding.py and what it does right (immutable-tag read, fails-in-CI rather than skipping)
• producer half open, vpp#238
• and why the distinction matters: "one side landing makes a row look finished when it is half finished"

So the substantive half of D5 is done. What remains is genuinely gated on #238, exactly as their own gate says.

3 · Their re-pin warning is inverted, and the correction is worse

This is the part worth reading. They wrote:

"views-postprocessing has an edition-compare test asserting [meta].version == its pinned "1.5.0". So if this edit bumps [meta].version to 1.6.0 and cuts a new tag, postprocessing's build goes RED until it re-pins."

Three errors, verified in views-postprocessing's code at 2eb29f1:

Claim	Actual
pins 1.5.0	pins 1.4.4 — unfao/appwrite_env.py:47, crafd/appwrite_env.py:50
would go red if we bump	already red
reads a pinned tag	_load_registry reads the sibling's working tree; their CI checks out our main (ref: main)

Executed rather than asserted, replicating their assertion under Python 3.11:

[unfao] registry working tree = '1.5.2'  pinned = '1.4.4'  -> ASSERTION FAILURE
[crafd] registry working tree = '1.5.2'  pinned = '1.4.4'  -> ASSERTION FAILURE

So the advice does not achieve its goal. Lifting the caveat without a version bump would leave views-postprocessing red at v1.5.2 anyway. Only their re-pin fixes it. Told them directly on vpp#238.

4 · What we got wrong

Our v1.5.1 and v1.5.2 PRs both claim "consumers pinned at earlier tags are unaffected — tags are immutable."

True for views-faoapi, which reads through git show <tag>:<path>. False for views-postprocessing, which compares against a working tree. We checked one consumer's mechanism and generalised. The break dates from v1.5.0 (2026-08-10 20:35), not from anything faoapi did.

5 · Their instruction's last check is moot

They ask us to confirm no guard pins the exact caveat string. None does — grep over tests/ returns nothing for the caveat text or verified_by. The three [contract] guards assert value/producer/consumer presence, the no-double-declaration rule, and non-emptiness; a prose edit touches none of them.

Condition to close this issue, restated

views-postprocessing#238, and nothing else. When it lands, both this row and [contract.UNCRAFD_CONSUMER_DOCUMENT_NAME] become two-sided authorities and both caveats come off in one edit. Scope is two rows now, not one.

Nothing further is owed from views-appwrite until then.

[Polichinel]

Update to my re-pin-cascade flag above: it rested on views-postprocessing having an edition-label compare test that a [meta].version bump would redden. Their D3 (PR #239) is explicitly moving to match on the row content they read, not the edition label — so a future version bump likely will not redden their build the way I warned, and edition skew between consumers is harmless anyway (the label is contract-immutable). Net: the caveat-lift here is even lower-risk than I flagged. Still prefer a verification-status edit that doesn't disturb the value; confirm specifics with the postprocessing session when D3 lands. (Registry is now at v1.5.2; the UNFAO value un_fao is unchanged, so faoapi's pin at appwrite-seam-v1.5.0 is unaffected.)

[Polichinel]

Both gates are now met. D5 is actionable. Verified from the producer seat (views-postprocessing), 2026-08-12:

gate	where it landed
D2 — consumer self-checks its filter name against this row	views-faoapi tests/test_seam_contract_binding.py (#379 → #382). It imports _CONSUMER_DOCUMENT_NAME from the production module rather than re-typing it, and pytest.fails under CI rather than skipping.
D3 — producer self-checks its mirror against this row	views-postprocessing tests/test_product.py::test_the_declared_consumer_name_matches_the_registry, merged in views-postprocessing#239. Covers both partners, reads the registry at the sibling's main, no credential.

So the row's verified_by caveat — "NEITHER IS IN PLACE YET … this row is a string a human typed" — is now false, and the row is understating its authority, which is the state this issue was opened to end.

Two things to weigh before flipping it

1. Neither check is on its repo's default branch yet. D2 is on views-faoapi's development (their main is 22 commits behind, at PR #357); D3 is on views-postprocessing's development (PR #240, the sync to main, is open). Both run in CI on every pull request in their repos, so the readers genuinely exist and genuinely bite — but a reader who checks either main today will not find them. Whether D5 waits on that is your call; I'd argue the checks existing and running is what the caveat was about, not which branch they sit on.

2. One honest residual, which the new wording should not paper over. D2 binds views-faoapi's served-name constant to this row. It does not bind their query mechanism to that constant — managers/prediction/manager.py filters on self.model_path.model_name at :117 and :435, and :117 applies the filter conditionally (if hasattr(...) and model_name), so a falsy name drops it silently. Verified intact today at origin/development. Nothing checks the composition. views-postprocessing carries that as register C-92, and views-postprocessing#248 will file the ask with the consumer seats.

So the row is a real authority for what the label is. It is not yet proof that a delivery is visible end to end. If the new verified_by says the latter, it will be the next thing someone has to correct.

Filed from views-postprocessing; nothing changed in this repo.

[Polichinel]

GO — the gate is now met (ADR-017 D5, this issue)

Earlier notes here said "wait for the producer side." It has landed. This is unblocked — verify against your own tree, then lift the caveat; this changes the live registry.

Both independent readers now exist (neither reads the other's source)

• consumer — views-faoapi#379: tests/test_seam_contract_binding.py reads un_fao at an immutable tag; merged, green in CI.
• producer — views-postprocessing#238 (PR #239 MERGED): test_product.py::test_the_declared_consumer_name_matches_the_registry reads the [contract] row via tests/seam_registry.py; the old faoapi-source-read is retired; re-pinned to 1.5.2.

So the row's ⚠ NEITHER IS IN PLACE YET warning is now false. Removing it is the record catching up, not a lie.

The edit

In docs/ADRs/platform/coordinate_registry.toml, [contract.UNFAO_CONSUMER_DOCUMENT_NAME] verified_by: replace the "NEITHER IS IN PLACE YET …" block with a statement that both readers are live (cite views-faoapi#379 and views-postprocessing#238). Leave value/producer/consumer/owner/amendment untouched — only the verification-status prose changes. Record it in the amendment log (§10). This is a verification-status edit, not a contract amendment — the un_fao value does not change.

Re-pin cascade — no longer a concern

You already solved the "an observation bump reddens consumers" problem: appwrite-seam-v1.6.0 added [meta] obliges_consumers_since + per-edition obliges_consumers, and §10.1 makes conformance pin >= obliges_consumers_since; postprocessing is adopting it. And faoapi/crafd read their value at an immutable tag with no edition-compare test, so they are immune to observation bumps regardless. Lift the caveat freely; a [meta] bump here (if your §10 wants one) reddens no one who matters.

Bonus — the CRAF'd row is likely liftable too

[contract.UNCRAFD_CONSUMER_DOCUMENT_NAME] (added v1.5.2): both CRAF'd sides now bind — consumer views-crafdapi#53 (merged) + the same postprocessing producer check (parametrized over crafd). If that row carries an equivalent caveat, lift it in the same pass. Do both, or keep this issue scoped to UNFAO and split — your call.

Keep your guards green

Re-run the [contract] registry guards (value+producer+consumer present; a name not in both [contract] and a scanned table; the table not empty) and validate_docs.sh. The prose edit touches none of the guarded fields; confirm no guard pins the exact "NEITHER IS IN PLACE" string (update it in the same change if one does).

On completion

Close this issue; comment on views-postprocessing#238 and views-faoapi#379 that the row is now a real authority. That closes the last external step of the invisible-delivery loop; views-faoapi runs its close-out (S7, faoapi#385) after.