Decision Runtime Trace
Evidence Artifact
This concept is part of the Decision Infrastructure category.
Decision Infrastructure asks
“Should it still happen now?”
The immutable record of how a decision became an executed outcome.
Not a log. Not a workflow history. Not an audit trail reconstructed after the fact. A Decision Runtime Trace is the architectural artifact written in-line with the act — anchored to the exact policy, authority, and inputs in effect at the moment of consequence.
Why logs, workflow histories, and audit trails are insufficient
Most enterprise systems can describe what happened. None of the common artifacts capture what governed the act:
Application logs
Describe state changes. Don’t capture the governance context the change was permitted under.
Workflow histories
Track lifecycle progression. Exit before the commit boundary — they don’t see the act itself.
Audit trails
Reconstructed after the fact from logs. Inherit every gap in the underlying log substrate.
Approval records
Prove the decision was approved. Do not prove the decision was still admissible at the moment of action.
A Decision Runtime Trace addresses all four limitations by being generated at the commit boundary — not assembled afterward.
What is a Decision Runtime Trace?
A Decision Runtime Trace is the immutable, time-ordered architectural record of how a single decision moved from intent to consequence.
It captures the admissibility evaluation, the verdict, the act, and the evidence as one bound record — anchored to the exact policy version, authority state, and input snapshots in effect at the moment of action.
The trace is not a derivative of execution. The trace is the architectural form in which governed execution exists.
Canonical definition
The structured, immutable, time-ordered architectural artifact recording a single decision from intent to consequence — captured in-line at the commit boundary, anchored to the policy version, authority register state, and input snapshots that governed the act.
The six trace stages
Each governed decision passes through six stages. The trace captures all six in a single bound record.
- 1
Decision
The approved intent arrives, ready to act.
Captured in the trace
Decision reference, action requested, originating approver, approval timestamp.
- 2
Admissibility
Authority, policy, state, evidence, timing, and exposure evaluated against current context.
Captured in the trace
Per-check verdict, evaluated values, policy version in effect, authority register snapshot.
- 3
Verdict
One of four deterministic outcomes — ALLOW, HOLD, DENY, ESCALATE.
Captured in the trace
Verdict label, controlling reason, escalation target (if applicable).
- 4
Execution
If the verdict is ALLOW, the act commits — irreversibly, accountably.
Captured in the trace
Bound timestamp, system-of-record reference, idempotency key.
- 5
Evidence
Evidence is captured atomically with the act — not reconstructed afterward.
Captured in the trace
Evidence hash, input snapshot reference, attestation chain.
- 6
Outcome
The real-world consequence that follows the act, linked back to the trace.
Captured in the trace
Outcome identifier, downstream system acknowledgements, settlement state.
Relationship to the Commit Boundary
The commit boundary is the structural point at which intent crosses into consequence. A Decision Runtime Trace spans the commit boundary — it begins before (when admissibility is evaluated), crosses through (when the act commits), and continues after (when the outcome resolves).
Before the boundary
Decision arrives, admissibility is evaluated, verdict is produced.
Through the boundary
The act commits. Evidence is captured atomically with binding.
After the boundary
Outcome resolves. Trace closes with downstream acknowledgements.
Relationship to Runtime Admissibility
Runtime admissibility is the property the system evaluates at the commit boundary. The evaluation itself produces structured artifacts — one verdict per admissibility check, plus the values evaluated against. These artifacts are not summarized into the trace; they are the trace’s admissibility section.
Without a Decision Runtime Trace, admissibility evaluations are ephemeral — they affect the verdict but leave no architectural residue. With it, every check becomes part of the permanent record that proves the act was governed.
Relationship to the Governance Ontology
The governance ontology defines the semantic vocabulary the trace is written in. It specifies which properties must be captured at each stage, which references must anchor each artifact, and which relationships must be preserved for the trace to be reconstructible.
The ontology is the contract; the trace is the artifact written against it. A trace that satisfies the ontology can be replayed deterministically by anyone with the same anchored inputs.
Replay Governance
Replay Governance is the ability to reconstruct deterministically what an enterprise system should have decided at a prior moment, using only the inputs available at that moment. The Decision Runtime Trace is what makes Replay Governance possible.
Because the trace anchors each stage to its policy version, authority register state, and input snapshots, a regulator, auditor, or internal reviewer can re-run the verdict against the same context — and verify that the act was governed under the rules that actually applied at the moment.
Without Replay Governance
Past decisions can be described but not reconstructed. Disputes resolve into argument, not verification.
With Replay Governance
Past decisions can be deterministically re-evaluated against the exact context they were governed under.
See a trace in action
For a concrete walk-through with an illustrative mortgage-funding scenario, including an ALLOW trace, a HOLD trace, and a sample evidence payload, see the reference implementation:
Runtime Trace ExampleRelated primitives
The Decision Runtime Trace exists alongside four other primitives of Decision Infrastructure. Each governs one facet of how execution remains admissible; the trace is what records all of them in one bound artifact.
Commit Boundary
Where the trace records the act.
Runtime Admissibility
What the trace evaluates against at the boundary.
Governance Ontology
The vocabulary the trace is written in.
System of Intelligence
The operating model that writes the trace.
FAQ
How is this different from a log, an audit trail, or a workflow history?
Logs describe state changes in a system. Audit trails are reconstructions assembled from those logs after the fact. Workflow histories track decision lifecycle but exit before the commit boundary. A Decision Runtime Trace is generated in-line with the act — anchored to the policy version, authority state, and inputs in effect at the moment of binding. It is the architectural form of the governed decision itself, not a derivative of it.
Is this the same as 'evidence at execution'?
Evidence at execution is the evidence payload captured atomically with the act. The Decision Runtime Trace is the broader artifact that contains the evidence alongside the admissibility evaluation, the verdict, the bound timestamp, and the outcome reference. Evidence is one stage of the trace; the trace is the whole record.
Who is the trace for?
Three audiences. Regulators and auditors use the trace to verify the act was governed. Internal reviewers use it to investigate exceptions and disputes. Consequence Intelligence uses it as the substrate for learning from outcomes that were actually admissible — not from outcomes that should never have occurred.
Does the trace expose internal implementation details?
No. The trace records the governed surface: which decision, which verdict, which policy version, which evidence reference. Internal model behavior, engine names, and component-level orchestration are not part of the trace. The trace is the architectural record of governance, not a system-internals dump.
Why is this called a primitive rather than a feature?
A feature is something a product offers. A primitive is something the architecture requires. Decision Infrastructure cannot produce governed execution without a structured record that anchors the act to its full governance context — admissibility, authority, policy, evidence. The trace is the architectural form that record must take. It is not optional.
Reference Surfaces
Reference Surfaces
Understanding a category requires more than comparisons. These reference surfaces explain the core concepts, architecture, vocabulary, and placement of Decision Infrastructure within the enterprise stack.
Definition
What Is Decision Infrastructure?
The canonical introduction to the category. Defines Decision Infrastructure, execution governance, runtime admissibility, and governed execution.
- Category definition
- Execution governance
- Runtime admissibility
- Governed execution
Placement
Where Decision Infrastructure Fits
Where Decision Infrastructure sits between Decision Systems and Consequence Intelligence in the enterprise stack.
- L4 Decisioning
- L5 Decision Systems
- L6 Decision Infrastructure
- L7 Consequence Intelligence
Architecture
Decision Infrastructure Architecture
The architecture that enables execution governance — how Decision Infrastructure operates across enterprise systems.
- Commit boundaries
- Runtime validation
- Execution control
- Evidence generation
Vocabulary
Decision Infrastructure Glossary
The canonical vocabulary of the category — the lexicon analysts can quote precisely.
- Runtime admissibility
- Commit boundary
- Execution governance
- Governed execution
- Evidence at action
Related Concepts
The primitives the trace records
Each primitive contributes one stage to the trace. Together they make governed execution reconstructible.
Commit Boundary
Where the trace records the act — the structural point intent becomes consequence.
Runtime Admissibility
What the trace evaluates against — the property that an approved decision remains permitted right now.
Execution Governance
The discipline the trace operationalizes — governance at the act.
Governed Execution
The outcome state the trace closes when the verdict is ALLOW.
Evidence at Execution
The trace stage captured atomically with binding.
Governance Ontology
The vocabulary the trace is written in — defines what must be captured.
System of Intelligence
The operating model that writes the trace at runtime.
Related Comparisons
Related Comparisons
Use these comparisons to understand how Decision Infrastructure differs from adjacent categories, systems, and governance models.
Decision Infrastructure vs Decision Intelligence
The category vs its output cousin — what produces decisions vs what governs them at execution.
Decision Infrastructure vs Decision Governance
Governance defines policy. Infrastructure operationalizes it at execution.
Decision Infrastructure vs Decision Control Plane
A control plane routes and coordinates actions; Decision Infrastructure governs whether each action should still happen at all.
Decision Infrastructure vs Decision Execution Engine
An execution engine runs the action; Decision Infrastructure governs whether execution may proceed.
Decision Infrastructure vs Runtime Governance
Runtime governance is a capability; Decision Infrastructure is the category that contains it.
Decision Infrastructure vs Decision Systems
Workflow-and-approvals systems exit before execution; Decision Infrastructure governs the act itself.
Decision Infrastructure vs AI Governance
AI Governance defines what should be allowed. Decision Infrastructure governs whether those permissions remain valid at execution.
AI Governance vs Decision Systems
Why model and process governance frameworks don't close the gap between approval and consequence.
Decision Infrastructure vs Digital Twin
Simulating reality vs governing what is allowed to happen in reality.
Sovereign Reasoning vs Decision Systems
Reasoning under jurisdictional and policy constraints vs the workflow systems that operationalize decisions.
Decision Infrastructure vs Agentic AI
Agents act autonomously; Decision Infrastructure governs whether each autonomous action is admissible at execution.
Decision Infrastructure vs MLOps
MLOps keeps the model healthy; Decision Infrastructure governs whether the decision it informs is admissible at execution.
Decision Infrastructure vs GRC
GRC documents and reviews controls; Decision Infrastructure enforces them on each action at execution.
Decision Infrastructure vs iPaaS
iPaaS connects systems and moves data; Decision Infrastructure governs whether the action between them should execute.
Decision Infrastructure vs Observability
Observability explains execution; Decision Infrastructure governs whether it should occur at all.
Decision Infrastructure vs Knowledge Graphs
Knowledge graphs map what is connected; Decision Infrastructure governs whether an action across those connections is admissible.
Decision Infrastructure vs Sovereign Reasoning
Sovereign Reasoning bounds how AI reasons; Decision Infrastructure governs whether the resulting action is admissible at execution.
Decision Infrastructure and Palantir
Palantir integrates data and drives action; Decision Infrastructure governs whether each action is admissible at execution — across any platform.
Decision Infrastructure and ServiceNow
ServiceNow runs and automates the workflow; Decision Infrastructure governs whether each action it fires is admissible at execution.
Decision Infrastructure and Pega
Pega manages decision workflows; Decision Infrastructure governs whether execution remains legitimate at the act.
Decision Infrastructure and Appian
Appian automates process execution; Decision Infrastructure governs consequence authorization at the commit boundary.
Decision Infrastructure and FICO
FICO optimizes decision quality; Decision Infrastructure governs whether a scored decision is still admissible at execution.
Decision Infrastructure vs Middleware
Middleware passes messages between systems; Decision Infrastructure governs whether the action a message triggers should execute.
Decision Infrastructure vs BPM
BPM orchestrates the process and moves work to the action; Decision Infrastructure governs whether that action should commit.
Decision Infrastructure vs Workflow Automation
Workflow automation runs the sequence; Decision Infrastructure governs whether each action in it should commit.
Decision Infrastructure and Salesforce
Salesforce runs the customer workflow; Decision Infrastructure governs whether each action it fires remains legitimate at the act.
Decision Infrastructure and Celonis
Celonis reveals how processes run and drives action; Decision Infrastructure governs whether that action is admissible at execution.
Decision Infrastructure and Icertis
Icertis manages contracts and obligations; Decision Infrastructure governs whether an action taken under them is admissible at execution.
Decision Infrastructure and Encompass
Encompass runs the loan workflow; Decision Infrastructure governs whether each consequential loan action is admissible at execution.
Decision Infrastructure and Empower
Empower runs loan origination; Decision Infrastructure governs whether each consequential loan action is admissible at execution.
Decision Infrastructure and Harvey
Harvey generates legal reasoning and drafts; Decision Infrastructure governs whether the actions taken from that reasoning are admissible at execution.
Decision Infrastructure and iManage
iManage manages legal knowledge; Decision Infrastructure governs the consequential actions taken using that information at execution.
Decision Infrastructure and Intapp
Intapp coordinates legal intake, conflicts, and approvals; Decision Infrastructure governs whether execution remains admissible at the act.
Decision Infrastructure and Relativity
Relativity surfaces and reviews evidence; Decision Infrastructure governs the consequential actions taken because of it at execution.
Decision Infrastructure and Reveal
Reveal surfaces evidence with AI-assisted review; Decision Infrastructure governs the consequential execution based on it.
Decision Infrastructure and Aderant
Aderant runs the business of law; Decision Infrastructure governs whether the consequential actions those operations drive are admissible at execution.
Decision Infrastructure and NetDocuments
NetDocuments manages legal documents and knowledge; Decision Infrastructure governs the consequential actions taken using that information.
Decision Infrastructure and Contract Lifecycle Management
Contract lifecycle platforms manage the contract; Decision Infrastructure governs whether actions taken under it remain admissible at execution.
Decision Infrastructure and Litera
Litera drafts, compares, and perfects legal documents; Decision Infrastructure governs whether the actions taken from those documents are admissible at execution.
Related Reading
Long-form explorations
Platform & Vision