Fix the disagreement before reading the proposed rule
Record one subject, the expected status, the observed conflicting status, the evidence rule, and the maximum acceptable age of the observation. Name what happens when the records still disagree: hold, review, reconcile, or escalate. Do not let the proposed code silently select a winner.
IETF RFC 9110 section 15 defines response status codes. It does not decide an application's source of truth, freshness policy, or business outcome after two records disagree.
Run a local change receipt
Use an intentionally bounded fixture and run:
node --test sites/odexing.com/evidence/P162/status-reconciliation-change-receipt.test.mjs
The validator requires a VCS revision, repository, conflict subject, different expected and observed statuses, authority-evidence rule, stale threshold, explicit non-silent outcome, reviewer, rollback procedure, and post-rollback check. It does not run Git, contact a service, test concurrency, or prove a human approved the change.
Keep recovery part of the gate
If the maintainer cannot identify who rolls back the policy and how to check the prior behavior afterward, stop the merge discussion. A local fixture can expose a missing decision, but a target repository and approved non-production environment still need their own tests.
For an automation-boundary receipt, see Gate an Agent-Generated CI Workflow Before Merge. For accepted work that reopens, see Gate an Agent-Generated Reopen-Workflow Change Before Merge. For request identity, see Gate an Agent-Generated Retry-Handling Change Before Merge.
Does this fixture prove which production status is authoritative?
No. It proves only that the local receipt names disagreement handling and recovery. Repository owners must verify actual records, permissions, timestamps, integrations, and deployment behavior.