Step 4 of the FAO correction procedure is incomplete — and Note 07 B.2 still tells FAO withdrawal is unavailable

[Polichinel]

docs/operations/correction_procedure.md (register C-22) is executable at steps 1–3 and 5. Step 4 — telling FAO — is executable but incomplete, and the document says so in its own banner. This issue tracks what is missing, because as of 2026-08-21 nothing did.

Two things prompted it. First, views-datafactory measured #387 and it is real: nine delivered cells carry a wrong second-level administrative label (views-datafactory register C-353, fix tracked at views-datafactory#471). That is the first live instance of the case §4 leaves open. Second, in going to write it up for FAO I found that the note §4 defers to still tells FAO something false.

1. Pre-Release Note 07 Topic B.2 misstates the cost of withdrawal — and the note is unsent

correction_procedure.md §3 already flags this; it has not been acted on. Confirmed still present today in brain/2_projects/fao02/_dev_materials/prerelease_notes/fao_02_pre_release_note_07/sections/topic_b.tex:41:

Option B — Withdrawal … Not available today. Requires a change to the delivery contract between PRIO-VIEWS' components, and corresponding work in the API layer.

That is false. views-faoapi ships an operator quarantine — src/views_faoapi/managers/prediction/quarantine.py, APPWRITE_UNFAO_QUARANTINED_FILE_IDS, wired into managers/prediction/manager.py:154 — read at selection time, no redeploy, reversible, nothing deleted. Withdrawal is available today and costs one environment variable.

Why this matters more than a stale sentence: B.2's Recommendation asks FAO to accept withdrawal while telling them it requires unbuilt work. If FAO chooses supersession partly on that cost framing, the decision is procured on a false premise. The note has not been sent, so this is fixable at no cost — but only before it goes.

• Correct topic_b.tex Option B to state that withdrawal is available now via operator quarantine, and adjust the Recommendation's cost argument
• Re-check summary.tex Decision~B.2, which repeats the framing
• Recompile and re-read B.2 end to end before the note is sent

2. §4's two open questions are open because FAO has not been asked yet

The banner is accurate as written and was already corrected once (2026-08-03) after it claimed nobody had decided who makes contact, while §4 twenty lines below named the person. What is genuinely undecided:

1. Are the named recipients right, and is there an expected notification period? A single named individual on leave is a single point of failure in exactly the situation where delay is costly.
2. Does FAO expect a correction notice for every error, or only one material to published outputs?

Both are Pre-Release Note 07 Decision B.1. Neither can be closed from this repository — they close when FAO answers. What this repository owes is that §4 is updated the day the answer arrives, rather than the answer living in an inbox.

• Note 07 sent (blocked on item 1 above)
• On FAO's answer: update §4, retire the "Still awaiting" subsection, update the interim-defaults table in topic_b.tex, update C-22
• tests/test_doc_accuracy.py asserts §4's responsibility sentence exists — extend it to the recipients/period fields once they are real, so the next drift is caught the way the banner drift was not

3. The materiality question now has a worked example, and it has been disclosed

Question 2 above is not hypothetical any more. The views-datafactory defect is precisely "a wrong admin label on a handful of cells" — the example §4 uses to argue the two cases are different events.

It has been disclosed to FAO as Pre-Release Note 07, Topic G (added 2026-08-21): information only, no decision point, no row in the decisions summary. It states the nine cells, that no country assignment and no forecast value changes, and that PRIO-VIEWS intends to correct at the next scheduled boundary rebuild rather than out of cycle, unless FAO indicates their processing joins on the second-level administrative unit.

What this repository must do when that correction lands: views-datafactory#471 regenerates the seven GAUL parquets and moves the ingestion digest. tests/test_gaul_lookup_fidelity.py will fail on the pinned lookup_version — that is the intended alarm, not a regression. The response is to rebuild the lookup (scripts/build_gaul_lookup.py --datafactory <path> --region land_gaul) and re-pin, not to relax the test.

• When views-datafactory#471 lands: rebuild the lookup, re-pin lookup_version, confirm the fidelity suite goes green on the new digest with no skipped in the summary line
• Record the event in C-22's history as the first exercise of the procedure, and note which gate did not catch it

Why here and not in views-datafactory

The defect is theirs and is tracked there. The procedure is ours, and the part that is incomplete is the part that faces the partner. correction_procedure.md §2 already points at views-datafactory#387 for the producer-side question and correctly says "do not correct a delivery to compensate for a producer defect" — this issue is the other half of that sentence.

Register C-22, C-43 · views-datafactory #387, #471, register C-353 · Pre-Release Note 07 Topics B and G