Repository navigation
Document post-delivery correction procedure for wrong assignments (C-22) #15
Description
Activity
Status vs current
development(2026-06-27): still open/valid; scope refreshed.
Still nodocs/standards/data_correction_procedure.md. Two scope updates since this was written:- Step 1 ("clear stale disk cache") is moot — the disk-cache machinery was deleted with the mapper (C-39). Drop it from the procedure.
- Identifying affected deliveries is now easier — S5 provenance (S5 — Structured delivery provenance invariant (C-15, supersedes #12) #56) stamps each upload with structured fields (lookup_version, region, cell counts) and the S3 identity metadata (name/loa) is on the file, so "which deliveries are affected" can key off provenance rather than guesswork.
Remains a process doc needing FAO-relationship + Appwrite-infra input (not a code change). Tier 3.
Rewrite tracked as #189 (epic #181, S8).
This issue's procedure describes a system that no longer exists: step 1's disk cache and step 2's shapefiles both went with the runtime mapper (C-39, PR #42). The delivery is now the ADR-013 frame-native wire.
Meanwhile C-22's trigger has fired — run-0 delivered on 2026-07-27 (
rusty_bucket_forecasting_20260727_095355, 64,742 cells, 28.4M rows) and is being served live by views-faoapi. There is data in a partner's store and no written way to correct it.#189 rewrites it against the delivery that exists, and carries the two questions only the operator can answer (who contacts the UN FAO, and whether they expect retraction or supersession). This issue closes when that document lands.
- added a commit that references this issue
on Aug 2, 2026 Superseded by
docs/operations/correction_procedure.md, landed in #206 (S8 / epic #181).This issue's procedure described the pre-#149 delivery — "clear stale disk cache", "re-run with corrected shapefiles" — and both were deleted with the runtime mapper in PR #42. The replacement is written against the ADR-013 frame-native wire that actually ships.
The two questions this issue never resolved are now stated explicitly in §4 of that document rather than left implicit: who contacts the UN FAO, and whether they expect retraction or supersession. Both are the operator's.
Context
When a Cluster B error is discovered after data has been uploaded to the FAO Appwrite bucket, there is no documented procedure for correction. The data delivery chain has stages beyond the code:
Steps 3-5 have no documented procedure, no automation, and no mechanism to identify which prior deliveries are affected.
Requirements
Write a correction procedure document (
docs/standards/data_correction_procedure.mdor similar) that specifies:Risk Register
C-22 (Tier 3). Part of Cluster B (operational impact dimension).
Note
This is a process documentation task, not a code change. It requires input from whoever manages the FAO relationship and the Appwrite infrastructure.