Reconciliation After Drift¶

Essence¶

Reconciliation After Drift is the repair pattern for a system that has lost a shared operational truth. It applies when two or more records, states, versions, accounts, or plans were expected to correspond, but now disagree. The goal is not merely to make numbers match or clear an exception queue. The goal is to restore an action-ready representation while preserving the evidence, authority, and reasoning behind the repair.

The key insight is that drift is often structurally normal. Separate teams, replicas, ledgers, physical counts, caches, drafts, and registries do not update at exactly the same time or through the same path. The archetype turns that drift into a governed repair cycle: compare, classify, resolve, record, verify, and learn.

Compression statement¶

When multiple representations that should correspond to the same referent diverge over time, Reconciliation After Drift detects the divergence, compares the competing states, identifies authority or merge rules, resolves conflicts without silent overwrite, records the repair, and verifies that the reconciled representation is fit for action.

Canonical formula: drifted_representations + shared_referent + comparison_rule + source_authority_or_merge_policy + conflict_resolution + reconciliation_record + verification_check -> restored_actionable_consistency

When to Use This Archetype¶

Use this archetype when multiple representations of the same underlying referent have already diverged and some action depends on restoring consistency. Typical triggers include mismatched ledgers, stock discrepancies, inconsistent permissions, conflicting document versions, stale records, replica divergence, or teams working from different facts.

Do not use it merely because something is messy. The representations should have a meaningful shared referent and a plausible repair basis. When the main task is selecting an authoritative source before divergence occurs, use Source-of-Truth Assignment. When the main task is preventing corruption across a lifecycle, use Data Integrity Preservation. When the task is accounting for whether a quantity was conserved across transformations, use Conservation Accounting.

Structural Problem¶

The structural problem is redundant or distributed representation without guaranteed convergence. A system has gained speed, resilience, specialization, or local ownership by allowing more than one representation of reality. Over time, updates are delayed, duplicated, lost, interpreted differently, or applied in a different order. The result is not just “bad data”; it is competing operational truths.

This is especially risky when each representation may be partly valid. A bank statement may be current while the ledger contains pending internal adjustments. A branch may include a valid local correction while another branch includes a global update. A physical count may be true at the shelf while the digital system reflects unscanned returns. Reconciliation has to repair the relationship among representations, not simply crown the most convenient one.

Intervention Logic¶

The intervention begins by naming the drifted representations and confirming their shared referent. It then inventories differences, classifies the mismatch type, and applies an explicit authority or merge rule. The repair should produce a reconciled state, but it should not silently overwrite the past. The reconciliation record matters because later review needs to know what differed, why the repair was justified, and which exceptions remained unresolved.

Strong implementations also feed the finding back into prevention. If the same mismatch recurs, the system has a control problem: synchronization cadence, write permissions, validation, transaction boundaries, handoffs, or source-of-truth rules may need repair.

Key Components¶

Reconciliation After Drift is the repair cycle for systems that maintain multiple representations of the same underlying thing — ledgers and statements, replicas and caches, physical and digital counts, drafts and versions — and have allowed those representations to diverge. The cycle begins with the Drift Detection Signal, which surfaces mismatch through audits, automated comparisons, complaints, dashboards, failed workflows, or scheduled checks. Once divergence is known, the Drifted Representations are collected as a working set, and the Shared Referent is confirmed so that records being compared genuinely point to the same entity, event, balance, obligation, or object — false shared-referent assumptions create mistaken merges. When stakes warrant it, a Mutation Pause or Freeze halts further writes, shipments, approvals, or edits so the mismatch does not compound during repair.

The middle of the cycle does the comparison and resolution work. The Difference Inventory lists conflicting fields, balances, timestamps, edits, or assumptions so repair is concrete rather than impressionistic. The Comparison Rule defines how representations are compared and which differences matter — exact equality, normalized units, semantic meaning, custody sequence, version ancestry, or acceptable tolerances — and the Difference Classification separates mismatch types so each gets the right repair path: stale update, missing event, duplicate, conflicting edit, unauthorized mutation, legitimate contextual difference, or unresolvable exception. The Source Authority names who or what governs each kind of difference — sometimes varying by field, jurisdiction, or period — and the Conflict Resolution Rule specifies how plausible-but-conflicting representations are chosen, merged, escalated, or preserved as unresolved. Where neither side should simply replace the other, the Merge Policy provides structured combination logic, and the Exception Owner prevents unresolved cases from becoming unowned limbo.

The final components produce a trustworthy result and feed learning back into prevention. The Reconciled State is the repaired, action-ready representation — not necessarily a single flattened record, but possibly a canonical record plus exception notes and pending items. The Reconciliation Record documents what differed, what rule was applied, what changed, who approved it, and what remains unresolved, because repair without a record creates a second integrity problem. The Verification Check confirms that the reconciled state actually meets the decision need and has not introduced new inconsistencies, using totals, invariants, stakeholder confirmation, or downstream sanity checks. The Rollback or Restore Path provides a safe undo for repairs that later evidence reveals to be wrong — essential in automated or high-volume reconciliation. Finally, the Recurrence Prevention Trigger converts repeated findings into upstream changes in synchronization, validation, access, transaction, or source-of-truth controls, so the same divergence stops being a chronic clerical burden and becomes a fixed structural problem.

Component	Description
Drifted Representations ↗	Role: Collects the records, accounts, versions, states, plans, or replicas that no longer agree. The archetype begins with at least two representations that are expected to correspond. Without a drifted set, the problem is ordinary validation or source assignment.
Shared Referent ↗	Role: Identifies the underlying entity, event, balance, obligation, version, object, or condition the representations are supposed to describe. Reconciliation is unsafe unless the records actually refer to the same thing. False shared-referent assumptions create mistaken merges.
Difference Inventory ↗	Role: Makes the mismatches explicit by listing conflicting fields, balances, timestamps, edits, states, or assumptions. A comparison artifact prevents impressionistic repair and helps distinguish timing differences from substantive conflict.
Comparison Rule ↗	Role: Defines how representations are compared and which differences matter. The rule may compare exact values, normalized units, semantic meaning, custody sequence, transaction history, version ancestry, or acceptable tolerances.
Difference Classification ↗	Role: Separates mismatch types so each receives the appropriate repair path. Common classes include stale update, missing event, duplicate entry, conflicting edit, unauthorized mutation, legitimate contextual divergence, and unresolved exception.
Source Authority ↗	Role: Names the authoritative source, role, rule, approval, custody path, or decision criterion for resolving a difference. Authority may differ by field, state, time period, jurisdiction, or record type. It should be explicit rather than implied by convenience.
Conflict Resolution Rule ↗	Role: Specifies how conflicting but plausible representations are chosen, merged, escalated, or preserved as unresolved. This keeps reconciliation from becoming arbitrary overwrite. Some conflicts require human adjudication or domain review.
Reconciled State ↗	Role: Represents the repaired, action-ready state after differences have been resolved or explicitly marked as exceptions. A reconciled state is not necessarily a single flattened record; it may include a canonical record plus exception notes, links, or pending items.
Reconciliation Record ↗	Role: Documents what differed, what rule was used, what was changed, who or what approved it, and what remains unresolved. This record preserves accountability and learning. A reconciliation without a record often creates a second integrity problem.
Verification Check ↗	Role: Confirms that the repaired state now satisfies the decision need and does not introduce new inconsistencies. Verification may use totals, invariants, referential checks, stakeholder confirmation, replay tests, or downstream sanity checks.
Drift Detection Signal ↗	Role: Triggers reconciliation when mismatch, exception, stale state, duplicate update, or discrepancy appears. Can come from audits, automated comparisons, complaints, dashboards, failed workflows, or scheduled checks.
Mutation Pause or Freeze ↗	Role: Prevents further writes, shipments, approvals, edits, or decisions from compounding the mismatch during repair. Not always necessary, but important when the drift is spreading or high stakes.
Merge Policy ↗	Role: Defines structured combination rules when neither representation should simply replace the other. Useful for collaborative editing, distributed systems, duplicate customer records, and branch conflict resolution.
Exception Owner ↗	Role: Assigns responsibility for resolving unresolved conflicts or approving high-stakes repair. Prevents reconciliation queues from becoming unowned limbo.
Recurrence Prevention Trigger ↗	Role: Turns repeated reconciliation findings into upstream process, access, validation, or synchronization changes. This connects repair to data integrity preservation and prevents chronic reconciliation burden.
Rollback or Restore Path ↗	Role: Provides a safe way to undo an incorrect reconciliation when later evidence shows the repair was wrong. Especially useful in automated or high-volume reconciliation.

Common Mechanisms¶

Mechanism	Description
Reconciliation Report ↗	This is a document_or_report. It implements Reconciliation After Drift when it summarizes mismatches, classifications, decisions, corrections, unresolved exceptions, and approvals. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Ledger Reconciliation Workflow ↗	This is a accounting_procedure. It implements Reconciliation After Drift when it compares ledgers, statements, payments, invoices, credits, and balances to repair financial divergence. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Data Diff and Merge Tool ↗	This is a software_tool. It implements Reconciliation After Drift when it compares records, files, schemas, rows, or versions and helps apply merge rules while preserving difference history. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Three-Way Merge ↗	This is a version_control_procedure. It implements Reconciliation After Drift when it uses a common ancestor plus two divergent versions to decide which changes can be combined and which conflicts need resolution. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Source-of-Truth Table ↗	This is a governance_artifact. It implements Reconciliation After Drift when it specifies which source or role is authoritative for each field, state, jurisdiction, timeframe, or mismatch type. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Exception Queue Review ↗	This is a review_cadence. It implements Reconciliation After Drift when it routes unresolved or high-stakes mismatches to accountable owners for adjudication, approval, or escalation. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Inventory Count Reconciliation ↗	This is a operations_procedure. It implements Reconciliation After Drift when it compares physical counts, warehouse records, shipments, returns, and adjustments to restore stock state. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Replica Repair Job ↗	This is a automated_repair_process. It implements Reconciliation After Drift when it detects and repairs divergence among caches, replicas, event streams, or distributed system states according to consistency rules. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Custody Chain Reconciliation ↗	This is a records_or_compliance_procedure. It implements Reconciliation After Drift when it compares custody events, handoffs, approvals, and physical or digital evidence to repair gaps in responsibility records. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.
Audit Log Review ↗	This is a evidence_review. It implements Reconciliation After Drift when it uses historical events and change records to reconstruct how divergence occurred and which repair is justified. It is not the archetype by itself; it is one way to operationalize comparison, authority, repair, recording, and verification.

Parameter / Tuning Dimensions¶

Drift Tolerance Threshold: How much difference can be tolerated before reconciliation is required.
Authority Hierarchy: Which source, rule, role, timestamp, or custody chain wins under specified mismatch types.
Merge Granularity: Whether repair occurs at the record, field, transaction, event, file, account, branch, or policy level.
Reconciliation Cadence: Whether comparison and repair are event-driven, scheduled, continuous, or triggered by exceptions.
Evidence Burden: How much proof is required before changing a record or state.
Automation Level: How much of detection, comparison, merge, approval, and verification can be automated.
History Retention Depth: How much prior state, difference, approval, and repair rationale is retained after reconciliation.
Escalation Threshold: When unresolved or high-stakes mismatches require human, legal, clinical, security, or governance review.

These parameters tune the repair pattern. A low-stakes content edit can tolerate lightweight merge rules; a rights-affecting identity record or financial balance may require strong evidence, approval, and retained history. The correct tuning depends on reversibility, harm, legal obligation, operational delay, and recurrence risk.

Invariants to Preserve¶

Shared Referent Integrity: The reconciled representation still refers to the correct entity, object, event, account, version, obligation, or state.
No Silent Overwrite: The repair does not erase alternative states, conflict evidence, or the reason the selected state was accepted.
Actionable Consistency: Representations needed for the decision are consistent enough for safe, legitimate action.
Authority Trace Is Visible: The source, rule, or approval behind the reconciled state can be inspected later.
Unresolved Conflicts Remain Explicit: Differences that cannot be resolved under the available rule are carried forward as exceptions.
Recurrence Signal Is Preserved: The repair record captures enough cause information to improve upstream controls.

The most important invariant is not superficial sameness. It is trustworthy actionability: the repaired state should correspond to the right referent, preserve the basis of authority, and keep unresolved conflict visible rather than hiding it.

Target Outcomes¶

Restored Operational Consistency: Systems and people can act from a reconciled state rather than conflicting records.
Reduced Decision Error from Stale State: Decisions are less likely to rely on outdated, partial, duplicated, or contradictory information.
Clear Exception Handling: Unresolvable mismatches are routed to owners, escalation, review, or adjudication instead of remaining hidden.
Improved Records-Family Governance: Source-of-truth, traceability, validation, access, and synchronization controls become more precise after learning from drift.
Better Auditability of Repairs: Future reviewers can see what diverged, why the repair was made, and which evidence supported it.
Lower Recurrence of Same Drift: The divergence pattern becomes less frequent because upstream causes are addressed.

A successful reconciliation produces more than a clean table or matching balance. It restores confidence that the relevant actors and systems can act from the same repaired state, and it leaves enough trace to review or undo the repair if later evidence changes.

Tradeoffs¶

Speed vs Evidence Quality: Fast repairs reduce operational delay but may choose the wrong state if evidence is thin.
Single Authority vs Contextual Truth: A strong authority hierarchy makes decisions clear but may erase legitimate local context.
Automation vs Judgment: Automated reconciliation scales but can mishandle semantic conflict, rights-affecting changes, or ambiguous evidence.
History Retention vs Simplicity: Rich repair history supports audit and reversal but increases complexity and storage burden.
Tolerance vs Sensitivity: Loose tolerances reduce reconciliation noise, while strict tolerances catch small mismatches that may matter.
Repair Cost vs Upstream Prevention: Frequent reconciliation can become a costly substitute for fixing validation, access, transaction, or synchronization controls.

The central tradeoff is between operational closure and truth-preserving repair. Systems often want mismatches gone quickly, but premature closure can launder errors. Good reconciliation makes the mismatch actionable without pretending uncertainty never existed.

Failure Modes¶

False convergence: usually caused by The repair forces records to match even though they do not share the same referent or legitimate contextual differences remain. Mitigate by: Validate the shared referent, preserve contextual distinctions, and keep unresolved exceptions explicit.
Destructive overwrite: usually caused by One representation replaces another without preserving the prior state, comparison basis, or rationale. Mitigate by: Use reconciliation records, version history, backups, and approval gates for high-stakes changes.
Authority confusion: usually caused by The system lacks explicit source authority or uses different authority rules by convenience. Mitigate by: Maintain a source-of-truth table and field-level authority/merge policy.
Stale source wins: usually caused by A nominal authority is out of date or disconnected from real-world updates. Mitigate by: Check recency, custody, event history, and downstream confirmation before accepting authority blindly.
Conflict suppression: usually caused by Unresolved conflict is normalized away to clear a queue or meet a reporting deadline. Mitigate by: Require exception states, owner assignment, escalation thresholds, and audit review.
Endless exception backlog: usually caused by Mismatches are detected faster than owners can resolve them. Mitigate by: Set triage levels, automate low-risk repairs, allocate owner capacity, and reduce upstream drift sources.
Repeated drift after repair: usually caused by The repair fixes the symptom but not missing synchronization, validation, access, transaction, or workflow controls. Mitigate by: Add recurrence-prevention triggers and feed findings into Data Integrity Preservation controls.
Semantic mismatch merge: usually caused by Fields or records with similar names but different units, meanings, jurisdictions, or time scopes are merged. Mitigate by: Require schema/meaning checks and domain review before semantic merge.

Many failures come from treating reconciliation as clerical cleanup. In high-stakes settings, reconciliation is governance: it can affect money, access, identity, custody, care, and accountability.

Neighbor Distinctions¶

Data Integrity Preservation: Data Integrity Preservation protects accuracy, consistency, provenance, validation, access, and recovery across the full data lifecycle. Reconciliation After Drift is narrower and repair-oriented: it begins after multiple representations have already diverged.
Conservation Accounting: Conservation Accounting tracks a conserved quantity across transformations to detect leakage, duplication, or hidden transfer. Reconciliation After Drift repairs inconsistent representations of the same referent, even when no conserved quantity is being tracked.
Source-of-Truth Assignment: Source-of-Truth Assignment chooses an authoritative representation. Reconciliation After Drift may use that authority, but its core work is comparing, resolving, recording, and verifying diverged states.
Traceability Linking: Traceability Linking connects a record or state to its origin and path. Reconciliation After Drift uses traceability evidence to repair divergence but is not just link creation.
Transactional Atomicity: Transactional Atomicity prevents partial commits by making related operations all-or-nothing. Reconciliation After Drift repairs inconsistency after prevention failed, was absent, or could not cover distributed/local updates.
Bidirectional Consistency Mapping: Bidirectional Consistency Mapping designs ongoing mapping rules between two representations. Reconciliation After Drift is the repair cycle when such representations have already fallen out of consistency.
State Synchronization: State Synchronization keeps states aligned continuously or periodically. Reconciliation After Drift addresses the exception condition of divergence and conflict repair.
Correspondence Validation: Correspondence Validation checks a new model or version against old valid behavior before replacing it. Reconciliation After Drift repairs inconsistent records, accounts, versions, or states after they diverge.
Stationarity Validation: Stationarity Validation tests whether past-generating assumptions still hold. Reconciliation After Drift tests and repairs consistency among representations, not stability of a statistical process.

The cleanest boundary is timing and focus: Reconciliation After Drift starts after representations have diverged and focuses on repair. Data Integrity Preservation is broader lifecycle protection. Source-of-Truth Assignment is authority selection. Conservation Accounting tracks preservation of a conserved quantity. Transactional Atomicity prevents partial commit before divergence becomes a repair problem.

Variants and Near Names¶

Ledger Reconciliation: Repair mismatches among financial ledgers, statements, balances, invoices, payments, credits, and obligations. It remains under the parent because It follows the same compare-classify-resolve-record-verify repair logic as the parent.
State Sync Repair: Repair divergence among replicas, caches, event streams, or distributed state after synchronization fails. It remains under the parent because It remains a representation-drift repair pattern using comparison, authority or merge rules, records, and verification.
Version Conflict Reconciliation: Repair divergence among branches, drafts, specifications, policies, or document versions after parallel changes conflict. It remains under the parent because It follows the parent repair logic but applies it to version histories and branches.
Inventory Reconciliation: Repair divergence between physical inventory, digital records, shipments, returns, damage records, and custody handoffs. It remains under the parent because It remains a repair of diverged representations of the same underlying stock state.

Useful near names include:

Reconciliation After Divergence → reconciliation_after_drift: Same parent concept using divergence rather than drift language.
Record Drift Repair → reconciliation_after_drift: Narrower records-oriented name for the same repair pattern.
State Reconciliation → reconciliation_after_drift: Common name when the drifted representations are system states.
Sync Repair → state_sync_repair: Implementation name for state synchronization repair.
Data Reconciliation → reconciliation_after_drift: Common data-domain label; keep as alias unless a specific data-governance variant is needed.
Account Reconciliation → ledger_reconciliation: Finance/accounting domain name for the ledger variant.

These names should generally point back to the parent or to a recognized variant. The project should avoid drafting reconciliation_report, checksum, audit_log, or diff_tool as archetypes; those are mechanisms or evidence artifacts.

Cross-Domain Examples¶

financial_accounting: A company reconciles its general ledger, bank statement, pending payments, and chargeback records after month-end discrepancies appear. Multiple accounts describe the same financial reality but have drifted through timing differences, missing entries, reversals, and duplicate records.
distributed_databases: A service detects that two replicas disagree after a network partition and applies repair rules based on version vectors, timestamps, and conflict policy. Diverged system states must be compared, repaired, verified, and protected against recurrence.
inventory_management: A warehouse reconciles physical stock counts with ERP records after returns, damaged goods, and delayed scans produce mismatched quantities. Physical and digital representations should agree before ordering, shipping, or reporting can proceed.
collaborative_document_work: A policy team merges conflicting drafts from regional teams while preserving change history and escalating disagreements about substantive requirements. Several versions of the same document have diverged and need structured comparison, merge rules, and unresolved conflict handling.
identity_and_access_records: An organization reconciles HR, identity provider, and application permission records when a role change is reflected in some systems but not others. Diverged representations of role and access state can create security and compliance risk.

Extended example: A hospital has three representations of a patient medication state: the physician order, the pharmacy dispensing record, and the bedside administration record. A discrepancy appears after a schedule change. Reconciliation After Drift first confirms that all records refer to the same patient, medication, dose, and time window. It inventories differences, distinguishes delayed charting from actual non-administration, applies source authority and clinical review rules, updates the reconciled medication record, documents the evidence and decision, verifies that downstream alerts now use the corrected state, and flags the workflow gap that caused delayed updates.

Non-Examples¶

A new system is tested against old behavior before launch. That is Correspondence Validation unless the old and new records have already drifted and require repair.
A single database row fails a validation rule. That is data validation or Data Integrity Preservation, not reconciliation among diverged representations.
A team chooses which database will be official before any mismatch occurs. That is Source-of-Truth Assignment; reconciliation comes after divergence.
A process tracks whether materials are conserved during transformation. That is Conservation Accounting unless the central problem is repairing already-diverged records or states.