Critical authoritative state restoration¶

Resolve time-sensitive high-consequence state discrepancies by reconciling conflicting authoritative records and live status evidence into a trusted current-state ledger with explicit holds and uncertainty, without diagnosing root cause or taking downstream action.

Metadata¶

Pattern id: critical-authoritative-state-restoration
Pattern family: Investigate / Reconcile / Verify
Problem structure: Record reconciliation (record-reconciliation)
Domains: Finance (finance), Compliance (compliance), Operations (operations), HR (hr)

Workflow goal¶

Determine the trusted current state of a critical situation by reconciling conflicting records, snapshots, and case evidence under emergency source-of-truth rules, then produce a human-reviewed state-restoration package that preserves unresolved truth gaps and stops before recommendation, notification, or execution.

Inputs¶

Critical discrepancy declaration and scope¶

Description: A declared severe case, control emergency, or command-level discrepancy that defines the affected entities, time window, and bounded state questions that must be resolved quickly.
Kind: case
Required: Yes
Examples:
Treasury command bridge asks which settlement obligations and liquidity buffers are actually current and unencumbered
Compliance response lead asks which payments are truly blocked, released, or still under sanctions hold after systems diverge
Operations command center asks which product lots are genuinely quarantined, in transit, or still exposed after hold-state conflicts emerge

Conflicting authoritative state evidence¶

Description: Structured records, live snapshots, control logs, and governed notes that describe the same critical state from different systems or responsible teams.
Kind: evidence-set
Required: Yes
Examples:
Bank confirmations, treasury ledgers, collateral calls, and manual liquidity adjustments
Screening engine status, case queue states, payment message holds, and override logs
Lot genealogy, warehouse quarantine status, shipment holds, and lab-review records

Emergency source-of-truth and hold rules¶

Description: Approved precedence rules, freshness thresholds, identity constraints, and mandatory hold conditions that determine when one source may be trusted, when disagreement must remain visible, and when humans must intervene.
Kind: policy
Required: Yes
Examples:
Treat central-bank facility confirmation as authoritative only when the settlement timestamp is inside the approved freshness window
Require human review if a blocked-payment state differs between sanctions case tooling and payment-rail hold records
Keep a lot branch on hold when genealogy, shipment, and quality systems cannot agree on containment status

Prior adjudications and active hold state¶

Description: Optional prior reconciliations, manual overrides, hold manifests, or reviewer decisions that should inform the current truth-restoration pass without erasing new conflicts.
Kind: case-state
Required: No
Examples:
Earlier liquidity bridge ledger with two entity balances marked provisional
Existing sanctions-hold exception record awaiting legal review
Previous contamination command-center hold manifest for one unresolved lot family

Outputs¶

Trusted current-state ledger¶

Description: The best available authoritative state for each in-scope entity, obligation, or lot, annotated with evidence references, freshness, and confidence.
Kind: ledger
Required: Yes
Examples:
Current intraday liquidity ledger with confirmed settled cash, encumbered balances, and provisional manual adjustments
Payment-hold ledger showing which transactions are truly blocked, released, or pending sanctions adjudication
Lot-state ledger showing quarantined, in-transit, and unresolved product branches with current evidence lineage

Unresolved discrepancy and hold register¶

Description: Explicit list of conflicts, unknowns, blocked merges, stale sources, and policy-triggered holds that prevent parts of the state from being treated as settled truth.
Kind: review-queue
Required: Yes
Examples:
Counterparty exposure lines held because a bank confirmation conflicts with a manual treasury adjustment
Payments kept in unresolved state because the screening queue and release ledger disagree
Lot branches held because warehouse and genealogy systems identify different downstream pallets

State-restoration handoff packet¶

Description: Structured package for downstream human decision-makers showing what state is trusted, what remains provisional, what evidence supports each conclusion, and where the workflow stopped.
Kind: case-packet
Required: Yes
Examples:
Treasury bridge packet showing confirmed funding runway, unresolved positions, and evidence links
Compliance response packet showing authoritative sanctions-hold scope and unresolved release conflicts
Operations command packet showing authoritative containment status and remaining ambiguous lot branches

Environment¶

Operates in critical situations where leaders need one trusted current-state picture quickly, but the source systems, human workbenches, and control ledgers disagree in ways that make premature certainty dangerous.

Systems¶

Systems of record, ledgers, or regulated case systems that hold candidate authoritative state
Snapshot, telemetry, or status systems that reflect live state during the critical window
Command, bridge, or investigation workspaces for critical discrepancy review
Audit, hold-manifest, and reviewer-approval systems

Actors¶

Command lead, incident lead, or crisis coordinator requesting trusted-state restoration
Domain analyst or steward who interprets source-system meaning
Risk, compliance, legal, or control reviewer
Human decision-maker who consumes the reconciled current-state packet

Constraints¶

Stop at determining trusted current state, preserving unresolved ambiguity, and packaging that state for human consumption; do not explain root cause, choose a response, or execute the response.
Preserve source lineage, timestamps, and reviewer-visible hold reasons for every consequential state element.
Prefer explicit provisional or held states over forced harmonization when evidence conflicts materially.
Keep emergency truth rules, manual overrides, and state-restoration approvals versioned and inspectable.

Assumptions¶

Participating systems expose enough identifiers, timestamps, and status fields to support defensible cross-system reconciliation under pressure.
Human owners are available to resolve protected conflicts, approve authoritative-state declarations, and decide what happens next.
Downstream response, communication, or execution workflows can consume a bounded handoff packet without requiring this pattern to take those actions itself.

Capability requirements¶

Retrieval (retrieval): The workflow must gather conflicting state evidence rapidly from multiple systems before trusted current state can be established.
Discrepancy analysis (discrepancy-analysis): The core problem is interpreting field-level and entity-level disagreements across competing records, snapshots, and human control artifacts.
Verification (verification): Every authoritative-state conclusion must be checked against source freshness, precedence rules, and independent evidence rather than accepted at face value.
Policy and constraint checking (policy-and-constraint-checking): Emergency precedence rules, mandatory hold conditions, and protected-state boundaries determine when delegated reconciliation must stop and surface uncertainty.
Coordination (coordination): Critical truth restoration usually spans multiple specialist roles and systems, so shared state and clear handoff boundaries are essential.
Tool use (tool-use): The workflow reads ledgers, case systems, manifests, and status tooling and writes hold registers and handoff packets through governed tools rather than text-only reasoning.
Memory and state tracking (memory-and-state-tracking): Trusted-state conclusions, unresolved conflicts, superseded snapshots, and reviewer decisions must persist across repeated critical updates.
Exception handling (exception-handling): Safe operation depends on holding, escalating, or isolating conflicts that exceed delegated truth-restoration scope instead of flattening them into one false answer.

Execution architecture¶

Orchestrated multi-agent (orchestrated-multi-agent): Critical state restoration often benefits from explicit roles for source retrieval, cross-system comparison, hold classification, and handoff assembly so the reconciliation path stays fast and inspectable.
Human in the loop (human-in-the-loop): Humans remain embedded because protected conflicts, emergency precedence exceptions, and final authoritative-state acceptance cannot be delegated away safely.

Autonomy profile¶

Level: Human directed (human-directed)
Reversibility: The reconciled ledger and handoff packet can be superseded as fresher evidence arrives, but once humans act on an incorrect critical-state picture the practical consequences may be costly or impossible to undo quickly.
Escalation: Escalate whenever no defensible authoritative state can be established, identity or lineage breaks make merges unsafe, protected data cannot be separated cleanly, or the next requested step would require recommendation, declaration, or execution instead of truth restoration.

Human checkpoints¶

Confirm the declared critical scope, source-of-truth hierarchy, and protected-state boundaries before automated reconciliation begins.
Review the trusted current-state ledger and hold register before the output is used for consequential decisions, declarations, communications, or operational changes.
Approve changes to emergency precedence rules, identity-merge thresholds, or hold-release logic before those changes affect live critical cases.

Risk and governance¶

Risk level: Critical (critical)
Failure impact: Declaring the wrong current state in a critical situation can trigger or delay emergency holds, misstate regulated or financial exposure, undermine safety containment, and cause leaders to act on a false picture precisely when response windows are narrow.
Auditability: Preserve every source snapshot or query reference, precedence rule version, identity or match decision, unresolved conflict, hold reason, human override, and authoritative-state acceptance event so reviewers can reconstruct exactly how the trusted-state picture was formed.

Approval requirements¶

Human approval is required before the trusted-state output is used for external reporting, executive declaration, customer or partner communication, fund restriction, shipment disposition, or other consequential downstream action.
Governance review is required before changing emergency precedence logic, protected-state handling, or hold-release criteria used by future critical truth-restoration runs.

Privacy¶

Limit copied financial, regulated, shipment, or personal detail to the minimum needed for state restoration and downstream review rather than duplicating full raw records broadly.
Keep protected identifiers and restricted evidence inside narrower review channels when the main state-restoration packet can rely on generalized or hashed references.

Security¶

Restrict read and write access to critical workbenches, hold manifests, and authoritative-state ledgers because tampering can distort the trusted picture during a severe event.
Record manual overrides, source-priority changes, and repeated reconciliation failures in durable logs so unauthorized state shaping remains detectable.

Notes: Critical-risk governance fits because the pattern determines what humans can safely treat as the current truth under severe consequences, while still remaining bounded at reconciliation, hold-state preservation, and handoff rather than action selection or execution.

Why agentic¶

Critical truth restoration requires adaptive reconciliation across stale, partial, and conflicting sources rather than one fixed precedence table applied once.
The workflow must preserve evolving authoritative-state hypotheses, explicit holds, and reviewer decisions as the situation changes, which static spreadsheet reconciliation handles poorly under pressure.
Safe operation depends on recognizing when unresolved ambiguity itself is materially important and should be surfaced instead of hidden behind a premature single answer.

Failure modes¶

A stale or partial snapshot is accepted as the current authoritative state¶

Impact: Human leaders act on outdated exposure, hold, or containment information during a critical window.
Severity: critical
Detectability: medium
Mitigations:
Recheck source freshness and snapshot lineage before accepting a field into the trusted current-state ledger.
Prefer provisional states and visible freshness warnings when no source meets the approved recency threshold.

Conflicting evidence is force-merged into a falsely settled answer¶

Impact: Material uncertainty disappears from the handoff packet and downstream teams assume a certainty that does not exist.
Severity: critical
Detectability: medium
Mitigations:
Require explicit hold states and conflict reasons whenever precedence rules do not cleanly resolve disagreement.
Block authoritative-state acceptance when mandatory fields remain unresolved or policy requires human adjudication.

Distinct entities, obligations, or lots are incorrectly merged during high-pressure reconciliation¶

Impact: The trusted-state ledger conflates separate items and spreads the wrong status or hold state across them.
Severity: high
Detectability: medium
Mitigations:
Apply stricter identity thresholds and reviewer-visible merge lineage for many-to-one or alias-heavy matches.
Route uncertain identity joins into the unresolved hold register instead of collapsing them automatically.

The workflow drifts into recommendation, declaration, or execution¶

Impact: Family boundaries blur and the critical reconciliation workflow starts making decisions or actions that should remain human-owned downstream.
Severity: medium
Detectability: high
Mitigations:
Limit outputs to the trusted ledger, hold register, and state-restoration handoff packet.
Keep downstream response, notification, and execution tools outside the delegated truth-restoration loop.

Evaluation¶

Success metrics¶

Time to first human-reviewable trusted current-state ledger with complete evidence lineage and explicit hold status.
Agreement between the workflow's trusted-state package and the final human-accepted current-state picture for the critical window.
Percentage of materially unresolved conflicts that remain visible in the hold register rather than being hidden in the main ledger.

Quality criteria¶

Every trusted-state assertion cites source evidence, freshness, and the rule or reviewer decision that made it authoritative.
The workflow preserves explicit provisional and held states whenever critical uncertainty remains.
Outputs stay bounded at current-state restoration and handoff instead of drifting into root-cause explanation, recommendation, or execution.

Robustness checks¶

Test with fast-changing source snapshots and confirm the workflow supersedes prior truth safely instead of mixing incompatible time slices.
Test overlapping identity aliases or partial match keys and verify that uncertain merges are held for review.
Test mandatory protected-data redaction and confirm the workflow can preserve state meaning without leaking restricted detail into broader handoff packets.

Benchmark notes: Evaluate both truth quality and uncertainty discipline; a faster answer is not a success if critical unknowns or stale evidence disappear from the official current-state picture.

Implementation notes¶

Orchestration notes¶

Keep source intake, comparison, authoritative-state proposal, hold classification, and handoff assembly as explicit coordinated stages over shared critical-case state.
Separate trusted-state restoration from downstream declaration, response, communication, and execution tooling so the family boundary remains intact.

Integration notes¶

Common implementations integrate ledgers, regulated case systems, inventory or status systems, command workspaces, and audit or hold-review tooling.
Keep the pattern neutral about specific treasury, sanctions, supply-chain, or crisis-management platforms.

Deployment notes¶

Start with severe discrepancy scenarios where clear emergency precedence rules, audit requirements, and human review paths already exist.
Monitor rates of superseded ledgers, unresolved holds, and human disagreement to ensure the workflow surfaces ambiguity instead of normalizing it away.

References¶

Example domains¶

Finance (finance): Reconcile treasury, bank, and collateral records during a liquidity event to determine which obligations and buffers are truly current before leaders choose a funding response.
Compliance (compliance): Restore the trusted state of blocked, released, and pending transactions when sanctions hold systems disagree during an active regulator-sensitive review.
Operations (operations): Reconcile lot genealogy, quarantine, and shipment-hold systems during a contamination event to determine which inventory is definitively contained versus still uncertain.
HR (hr): Restore the trusted current state of a protected-leave episode when leave, occupational-health, and benefits systems disagree about active review, effective dates, and unresolved dependency holds.

Authoritative record reconciliation (variant-of)
This pattern is a critical-risk, time-sensitive variant focused on trusted current-state restoration under severe consequences rather than routine reversible record repair.
Incident root cause analysis (contrasts-with)
Root-cause analysis explains why a severe discrepancy emerged, while this pattern determines what the authoritative state is right now even if causes remain unresolved.

Grounded instances¶

Canonical source¶

data/patterns/investigate-reconcile-verify/critical-authoritative-state-restoration.yaml