Skip to content

Reconciliation After Drift

Restore consistency when records, states, versions, accounts, or representations of the same underlying reality have drifted apart.

The Diagnostic Story

Symptom: Two or more records, states, or representations that are supposed to describe the same thing have diverged. Each version may contain partial truth, local corrections, or stale information, and acting on any one of them risks being wrong in ways that are hard to detect before the error causes harm. Nobody is sure which version is authoritative, or the answer differs depending on who you ask.

Pivot: Treat the mismatch as a repair problem over related representations. Identify the shared referent, collect all drifted states, compare them against an explicit authority or merge rule, resolve conflicts, write a reconciliation record that preserves evidence of how the drift arose, and verify the repaired state before acting on it.

Resolution: The working surface returns to a single consistent truth rather than a set of competing partial truths. The reconciliation record makes the repair auditable and provides the input needed to prevent the same drift from recurring. Actions downstream can again trust that the representation they are reading reflects reality.

Reach for this when you hear…

[distributed systems] “Two nodes accepted writes during the partition and now disagree on account balance — reconciliation means deciding which version wins, not just merging the numbers.”

[financial close] “The subsidiary ledger and the consolidated GL were twenty thousand dollars apart and both teams thought theirs was right — reconciliation is the only way to find out.”

[clinical records] “The patient's medication list in the ER system and the one in the pharmacy system hadn't synced in six months — before we prescribed anything we had to reconcile them.”

Mechanisms / Implementations

  • Reconciliation Report: This is a document_or_report.
  • Ledger Reconciliation Workflow: This is a accounting_procedure.
  • Data Diff and Merge Tool: Compares two divergent copies against their common ancestor, auto-merges the changes that don't overlap, and surfaces the ones that do as explicit, reviewable conflicts.
  • Three-Way Merge: This is a version_control_procedure.
  • Source-of-Truth Table: This is a governance_artifact.
  • Exception Queue Review: Routes the conflicts no automatic rule could resolve into a monitored queue where a named owner adjudicates each one to closure.
  • Inventory Count Reconciliation: This is a operations_procedure.
  • Replica Repair Job: Runs on a schedule to find replicas that have fallen behind or diverged and reconciles them back toward the others, bounding how stale any copy is allowed to get.
  • Custody Chain Reconciliation: This is a records_or_compliance_procedure.
  • Audit Log Review: This is a evidence_review.

Abstractions this archetype builds on — directly (a source ingredient) or as a related pattern. Links follow the typed catalog namespace.

Built directly on (3)

Also references 8 related abstractions

Variants

Narrower or domain-specific specializations that share this archetype's core structure. Recognized variants are established; candidate variants are provisional.

Ledger Reconciliation · domain variant

Repair mismatches among financial ledgers, statements, balances, invoices, payments, credits, and obligations.

State Sync Repair · implementation variant

Repair divergence among replicas, caches, event streams, or distributed state after synchronization fails.

Version Conflict Reconciliation · implementation variant

Repair divergence among branches, drafts, specifications, policies, or document versions after parallel changes conflict.

Inventory Reconciliation · domain variant

Repair divergence between physical inventory, digital records, shipments, returns, damage records, and custody handoffs.