In plain English
Decision Proof Infrastructure is a read-only, retrospective, off-path layer that connects retained source evidence, governing versions, human judgment, recorded outcomes, chronology, proof conditions, and limitations into a reviewable Decision Proof Record. It preserves source and human authority; it does not make, rerun, validate, or change the underlying decision.
A simple example
A model is questioned after decisions have already been made. Decision Proof Infrastructure helps find the affected decisions and connect the retained evidence needed to understand each one without rerunning them.
Definition and operating problem
Critical-decision evidence fragments because operating systems optimize for execution, workflow, or status rather than later reconstruction. Source values, policy or rule versions, model context, human rationale, approvals, outcomes, and timestamps can remain valid yet disconnected.
Decision Proof Infrastructure addresses that later-review problem. It connects retained context while preserving what each source actually owns and what the evidence cannot establish.
Anatomy of a Decision Proof Record
A useful record distinguishes origin, meaning, transformation, authority, time, and limitation. Flattening these categories creates apparent completeness while hiding where interpretation or derivation occurred.
Ten record elements
Canonical proof-condition taxonomy
A proof condition describes a dimension, not a whole-record score. The five dimension statuses are Ready, Weak, Missing, Ambiguous, and Conflicting.
Missing/unverifiable is a separate evidence classification. It identifies unavailable or unconfirmable evidence and must not be presented as a sixth dimension status. A question such as outcome correctness may instead be outside assessment scope.
Worked comparison: payment and AML share an architecture, not a workflow
The public payment reconstruction retains a payment event, authentication and authorization responses, risk and configuration context, a human exception, and a recorded source outcome. Approved typed payment-edge semantics are absent, so the public presentation uses ordered retained context and chronology.
The separate AML example retains transaction and account context, an AML monitoring signal, alert, investigation evidence, analyst rationale, approval, and recorded outcome. Its canonical synthetic record includes approved typed AML relationships. Those relationships are not imported into payment evidence.
Synthetic example
One architecture, two authority models
Both records preserve source identity, governing versions, human authority, chronology, proof gaps, and limitations, while their source workflows and relationship authority remain distinct.
- Payment: ordered context; delegation evidence is Weak and Missing/unverifiable.
- AML: approved typed relationships; policy-time linkage is Ambiguous.
- Neither record establishes decision correctness or production deployment.
Replay is not source-decision re-execution
Decision replay reconstructs retained context in the sequence and classifications available to a later reviewer. It separates what existed at decision time from what was captured or learned afterward.
Replay does not execute the original rule, model, authorization, monitoring, investigation, or approval logic. A reconstructed record can be internally consistent while the source outcome remains outside correctness assessment.
What a later reviewer asks
A later reviewer asks which retained records existed at decision time, which governing versions and human authorities applied, what outcome the source system recorded, which context arrived later, and which gaps prevent a complete reconstruction.
The answer must preserve the payment record's ordered context and the AML record's separately approved relationship authority rather than flattening both scenarios into one universal graph claim.
What RecordArc reconstructs and does not do
RecordArc reconstructs retained source identity, classifications, governing versions, chronology, human authority, proof conditions, and disclosed limitations. It uses approved relationships where they exist and ordered context where typed-edge authority is absent.
It does not make, recommend, rerun, validate, or change the source decision, and it does not convert a synthetic demonstration into deployment or operating-effectiveness evidence.
What the category is not
Decision Proof Infrastructure is not a system of record, payment engine, fraud engine, AML monitoring product, case manager, filing tool, or autonomous decision maker. It does not convert conceptual applicability into current availability.
Banking and payment decision proof is RecordArc's first implementation wedge. It validates the architecture without defining the product boundary; cross-sector applicability remains controlled by evidence, semantic, temporal, authority, and limitation gates.