Record the disagreement rather than replacing it
Name the intended operation and keep both statements visible: the status the handoff expects and the status the source currently reports. Record where the observed value came from and when it was observed. Do not overwrite the earlier record just to make one screen look consistent.
IETF RFC 9110 section 9.2.2 says a client should not automatically retry a non-idempotent request unless it knows the request semantics are idempotent or can detect that the original request was not applied. That protocol rule does not decide which business record is current.
Run the bounded receipt
Use a safe fixture or an approved non-production record and run:
node --test sites/howtox.com/evidence/P161/status-reconciliation-receipt.test.mjs
The local validator requires an operation identity, expected and observed status, source, observation time, reconciliation owner, explicit decision, and escalation route. It rejects a fixture that describes agreement instead of a discrepancy. It does not query a provider, establish data freshness, or authorize staff action.
Hold work when nobody owns the comparison
Pause the handoff if the team cannot name the source, timing, person who compares the records, and decision that follows. A manual reconciliation queue is often a smaller and safer next step than adding an automatic retry or status overwrite.
For a paired-system boundary, see Test Booking-to-Calendar Synchronization Before Staff Rely on It. For accepted work that later changes, see Test a Reopened Work Request Before Staff Rely on It. For an unknown first request result, see Test a Retry-Safe Request Handoff Before Staff Rely on It.
Does this receipt prove the source-system status is correct?
No. It proves only that the local fixture names a disagreement, evidence source and time, decision owner, and escalation route. An approved system-specific exercise must test the actual records, permissions, concurrency, and consequences.