Two Published-Post Corrections Swapped Reapproval Records: Reconcile Both Live Versions

A swap happens when correction A is released against correction B's reapproval record, or the reverse. The repair requires a two-record reconciliation.

Build the ledger before changing either live post. Record only identifiers and evidence you can retrieve: post ID, live URL, original capture hash, corrected hash, defect, accepted approval link, observed approval link, the approver's release decision and notification outcome.

The goal is simple: each live version must have one evidence chain that begins with its original capture and ends with its own accepted reapproval.

Which records belong to each correction?

Open two separate rows, one per post. Do not combine them because the defects look similar or because the same approver handled both corrections.

For each row, retrieve the original published capture and hash first. Then retrieve the corrected draft and hash. A hash identifies the exact text or asset version that was reviewed.

Record the defect in plain language. Then attach the approval evidence that explicitly names or contains the corrected version for that row. If the approval record only identifies the original post, it does not establish reapproval of the correction.

How do you identify the crossed approvals?

Compare the corrected hash in each accepted reapproval record with the corrected hash that reached the live URL. A mismatch proves the approval cannot support that release. A missing hash does not prove a match, so use a version ID, immutable revision link, or an attached export that identifies the reviewed correction.

Check both directions. Correction A may point to B's approval while correction B points to A's approval. It is also possible that one record is correct and the other is missing. Do not infer a complete swap until the ledger proves it.

Add the observed approval link separately from the accepted approval link. The observed link documents what the workflow showed. The accepted link is the evidence that supports the corrected release decision.

• Negative-swap test A: verify that correction A's corrected hash does not appear in correction B's accepted reapproval record.
• Negative-swap test B: verify that correction B's corrected hash does not appear in correction A's accepted reapproval record.
• Live-version test: fetch or capture each live URL and confirm its content matches the corrected hash assigned to that post.
• Notification test: confirm the notification names the matching post's corrected version and final release outcome.

Which live states relied on the wrong approval?

Trace every state change in order: original publication, defect discovery, correction draft, reapproval, corrected release, and notification. Mark a live state as unsupported when its release decision cites an approval record that belongs to the other correction or cannot be matched to its corrected version.

Do not silently overwrite the trail. ICMJE says a corrected version should detail the changes and their dates, with prior versions archived. Crossref describes update metadata as a way to show readers whether content has changed and access the current status of that record.

A correction can remain live only after its corrected version, approval evidence, and live URL agree. If they do not agree, pause further changes, preserve the evidence, and route the item for a fresh review of the exact corrected version.

What should the corrected release decision say?

Write one release decision for each correction. Include the post ID, live URL, original hash, corrected hash, defect, accepted reapproval link, approver, notification outcome, and the result of both negative-swap tests.

Use a direct decision: release retained because the accepted reapproval matches the corrected hash and live URL, or release withdrawn pending reapproval because the approval record does not match. Do not turn a notification into approval evidence.

NLM links correction notices to the cited original item so readers can find the related record. The same principle helps an internal workflow: the correction, original capture, and final live version should remain connected.