ProofRecord™ v0.1 Schema
A ProofRecord™ is the tamper-evident artifact produced when the ExecutionProof™ Boundary Console evaluates a request against a defined boundary. It captures the full decision — what was requested, what evidence was considered, which policy version applied, and why the outcome was reached — so the decision can be reconstructed, audited, and defended later.
Version 0.1 defines a standardized set of 20 fields. Every record is exportable as a human-readable executive view (PDF) and as machine-readable JSON.
The 20 fields
| # | Field | Description |
|---|---|---|
| 1 | ProofRecord ID | Unique, immutable identifier assigned when the record is created. Never reused, never edited. |
| 2 | Timestamp | UTC timestamp of the moment the decision was rendered. |
| 3 | Request ID | Identifier of the originating request, used to correlate the record with the requesting system. |
| 4 | Workflow / boundary name | The named execution boundary the request was evaluated against (e.g. Vendor Payment Release). |
| 5 | Actor identity | Who or what initiated the request — human user, service account, or autonomous agent. |
| 6 | Delegated authority source | Where the actor’s authority comes from: role assignment, approval chain, or delegation record. |
| 7 | Requested action | The specific high-consequence action requested, including its parameters (amount, destination, etc.). |
| 8 | Evidence references | Pointers to each evidence artifact considered, with its source system and a payload fingerprint. |
| 9 | Evidence freshness | Per-evidence status: current, stale, missing, or conflicting. A first-class field, not an afterthought. |
| 10 | Policy version | The exact version of the boundary policy in force when the decision was made. Bound to every record. |
| 11 | Constraint results | The pass / hold / fail outcome of each individual authority, policy, evidence, and state constraint. |
| 12 | System state | Snapshot of the operational state conditions checked at decision time (e.g. safe mode, account status). |
| 13 | Risk level | The risk classification of the request: low, medium, high, or critical. |
| 14 | Human review requirement | Whether human review was required, and if so, under what rule and minimum authority. |
| 15 | Decision | The rendered outcome: ALLOW, HOLD, or DENY. |
| 16 | Reason | Human-readable explanation of why the decision was reached, tied to specific constraint results. |
| 17 | Reviewer | Identity of the human reviewer, if a review or override occurred. |
| 18 | Final outcome | The resolved end-state of the request after any review or override. |
| 19 | Hash / integrity reference | Fingerprints of the record payload and its evidence, enabling tamper-evidence and later verification. |
| 20 | Reconstruction notes | Guidance for reconstructing exactly why the decision happened, for audit and accountability. |
Decision semantics
Every required condition passed. Authority is present, policy limits are satisfied, all evidence is current, system state is correct, and any required human review has been completed. The action may proceed.
The boundary cannot verify the request yet — this is not a soft allow, and no execution happens. A HOLD means something must be resolved first: evidence is stale, missing, or conflicting; a required approval is not yet present; system state is not confirmed current; or a required human review has not been performed. Once the gap is resolved, the request is re-evaluated and a new record is produced.
A required condition failed, or the request is explicitly prohibited, or a hard boundary was breached. Examples: the actor lacks delegated authority, the action is on the prohibited list, the amount exceeds the policy ceiling, or the destination is not on the allowlist. A DENY is a definitive stop and cannot be overridden by a reviewer.
Evidence freshness
Every piece of evidence carries a freshness status drawn from its source system — for example a CRM, EHR, ERP, source control, approval system, bank portal, IAM directory, or ticketing system. Freshness is evaluated against a per-evidence window defined in the boundary.
The evidence was refreshed within its allowed freshness window and is trusted as of the decision time.
The evidence exists but is older than its allowed freshness window. It must be refreshed before the action can be allowed.
The evidence required by the boundary was not supplied at all.
Two or more sources disagree, so the evidence cannot be trusted until the conflict is resolved.
Every ProofRecord™ is bound to the exact policy version that was in force at decision time. If the boundary policy changes later, historical records still reflect the rules that actually applied when the decision was made. This is what makes a record defensible after the fact.
A ProofRecord™ is designed to make undetected alteration difficult, not impossible. Concretely, each record carries an immutable ID and timestamp, payload and evidence fingerprints, and references to the policy version in force. Records are appended to history rather than edited in place, and every record is exportable for independent retention.
We describe this as a tamper-evident record. We do not claim records are impossible to alter or immutable forever — an honest description matters more than a marketing one.