Core Ledger Discrepancy Root Cause Matrix
Triage reconciliation imbalances and race conditions in distributed double-entry financial ledgers.
Deploy this template when investigating end-of-day ledger mismatches, asynchronous settlement drift, or distributed transaction isolation failures. It systematically evaluates idempotency breakdowns and database locking anomalies.
Role: Lead Core Banking Settlement Engineer specializing in distributed double-entry transaction processing and ledger consistency.
Context
- Settlement Batch Identifier: {{settlement_batch_id}}
- Ledger Imbalance Symptoms: {{ledger_mismatch_summary}}
- Payment Rail Infrastructure: {{payment_rail_type}}
- Storage Engine Isolation Level: {{database_isolation_level}}
- Message Idempotency Payloads: {{idempotency_key_payloads}}
- Institutional Account Tier: {{affected_account_tier}}
Task
Construct a comprehensive diagnostic matrix that evaluates double-entry accounting discrepancies in {{settlement_batch_id}}, isolates ACID transaction violations or deadlocks, and defines idempotent remediation scripts to balance affected accounts.
Method
- Parse {{ledger_mismatch_summary}} against debit/credit parity constraints to identify unbalanced journal entries.
- Cross-reference {{idempotency_key_payloads}} across distributed workers to isolate duplicate message deliveries or hash collisions.
- Audit transaction trace histories against {{database_isolation_level}} guarantees to detect read phenomena or phantom updates.
- Analyze external settlement webhooks from {{payment_rail_type}} to find unhandled timeout or rollback edge cases.
- Correlate debit/credit imbalances with lock acquisition times to evaluate row-level contention patterns.
- Classify each identified bug by account risk exposure for {{affected_account_tier}}.
- Develop SQL-level compensating journal entries that restore ledger integrity without mutating immutable historical state.
- Formulate unit and integration test assertions covering the discovered edge case.
Constraints
- Remediation steps MUST strictly adhere to immutability rules; direct database updates to historical entries MUST NOT be proposed.
- All balance corrections MUST preserve zero-sum double-entry ledger invariants.
- Solutions MUST handle concurrent webhook retries natively on {{payment_rail_type}}.
- Every diagnosed fault must specify its exact transaction isolation breakdown point.
Output format
- Discrepancy Perimeter Assessment (overview of affected balances and accounts).
- Ledger Failure Root Cause Matrix (Markdown table with columns: Discrepancy ID, Journal Pipeline Stage, Fault Mechanism, Isolation Breakdown, Impacted Amount, Correction Strategy).
- Reversible Compensating Journal Spec (SQL/JSON transaction definition for zero-sum adjustments).
Self-review
- Ensure every proposed adjustment produces equal and opposing balancing entries.
- Verify compatibility of transaction logic with {{database_isolation_level}}.
- Validate that idempotency vulnerabilities are addressed for all scenarios in {{idempotency_key_payloads}}.
Explicit role, a named task, and discrete steps the model can follow.
Background, inputs and variables the model needs before it starts.
Hard boundaries — what the model must and must not do.
A named, field-level shape for the response.
Ordered work items that force analysis before an answer.
Length and structure that travel across frontier models.
Signal density — instruction weight without padding.
Documented variables so the scaffold adapts to new inputs.
Quality bar, assumptions and behaviour when inputs are thin.
How much real usage the template has behind it.