What Are Decision Traces?
Decision traces are durable records of how individual decisions were made: the inputs gathered, the policy applied, any exception or precedent invoked, who or what approved it, and what changed as a result. Where a rule says what should happen in general, a decision trace records what happened in one specific case. Accumulated over time, decision traces become searchable precedent for audits, debugging and later decisions, including decisions made by AI agents. A trace can be checked later only if it records what the decision read, and as of when.
Updated
What are decision traces?
The term is central to AI's trillion-dollar opportunity: Context graphs, an essay by Jaya Gupta and Ashu Garg of Foundation Capital, posted December 22, 2025. They describe decision traces as "the exceptions, overrides, precedents, and cross-system context that currently live in Slack threads, deal desk conversations, escalation calls, and people's heads," and draw the central line: "Rules tell an agent what should happen in general," while "Decision traces capture what happened in this specific case."
Their argument is about systems of record. Persist the traces, they write, and you get "a queryable record of how decisions were made." The accumulated structure of those traces is what they call a context graph. Software that sits in the execution path, where the decision is made, can capture a trace at that moment. A warehouse loaded by ETL afterward cannot, because, in the essay's words, "By the time data lands in Snowflake, the decision context is gone." The context graph post covers that argument in depth.
In observability, "trace" means something narrower. OpenTelemetry says "Traces give us the big picture of what happens when a request is made to an application," and builds them from spans, each of which "represents a unit of work or operation." An agent's OpenTelemetry trace can record model and tool calls; a decision trace records the business decision they added up to. The first is a source for the second, not a substitute.
How decision traces work
The essay's worked example is a renewal agent that proposes a 20% discount where policy caps renewals at 10% unless a service-impact exception is approved. The agent gathers incident and escalation history, routes the exception to Finance, and Finance approves (Foundation Capital). A trace for that decision might look like this, with illustrative values:
{
"decision_id": "d-7f3a",
"decided_at": "2026-10-19T14:02:11Z",
"actor": "renewal-agent",
"subject": "account:4410/renewal",
"policy": { "id": "renewal-discount", "version": "3.2", "cap_pct": 10 },
"proposal": { "discount_pct": 20 },
"exception": { "type": "service-impact", "approved_by": "finance" },
"precedent": ["d-1c09"],
"inputs": {
"sev1_incidents_90d": { "value": 3, "source": "incidents", "as_of": "2026-10-19T14:02:09Z" },
"open_escalation": { "value": true, "source": "support", "as_of": "2026-10-19T14:01:40Z" }
},
"effect": { "discount_pct": 20, "record": "crm:opportunity/88123" }
}The inputs block, and the as_of fields inside it, are what make a trace checkable. Here the incident count was read at 14:02:09 and the escalation status at 14:01:40, from two systems. If the escalation was resolved at 14:01:55, the agent decided on an escalation that had been closed for sixteen seconds, and the trace pairs inputs read at two different moments. A trace that names one read point for all its inputs, read from one consistent snapshot, can be audited. One that doesn't is a narrative.
Two more rules keep traces useful. Append, never edit: a reversal is a new trace that references the old one. And write the trace no later than the effect: in the same transaction when both live in one store, or before the change is sent to another system such as the CRM, so a discount never exists without the record of why.
Why decision traces matter in real-time systems
The essay describes a feedback loop: "Captured decision traces become searchable precedent. And every automated decision adds another trace to the graph." That makes traces an input to the next decision, not only an audit history.
As an illustration, suppose policy allows one exception per customer per quarter, and two agents handle requests from the same customer at once. Each searches precedent, finds none and grants one. If traces reach the precedent store by a batch job every few minutes, neither could have seen the other's grant. When later decisions read the traces, each record has to be written in the same transaction as the decision, with concurrent checks serialized so the second grant sees the first or retries. That is the decision ledger pattern.
Tacnode is not a graph store, and it doesn't build context graphs. It holds the decision context a trace points to: what a decision read, evaluated under one snapshot, and what it decided, written with full transactions. A trace can then cite one read point, and the next decision can see what the last one committed.
FAQ
Related terms
A decision ledger is an append-only record of automated decisions: what was decided, on what inputs, under which policy and authority, and what changed.
Decision context is everything an automated decision reads and everything earlier decisions committed, as it stands at the moment the decision executes.
Event sourcing stores application state as an append-only log of immutable events; current state is derived by replaying them. Covers mechanics and trade-offs.
Decision coherence is the property that concurrent automated decisions act on the same version of shared state, instead of contradicting each other.
MVCC (Multi-Version Concurrency Control) lets databases keep multiple versions of each row so readers see consistent snapshots without blocking writers.
Derived context is state computed from events rather than stored directly — aggregates, velocity counts, features, embeddings — that decisions consume.
Closed-loop decisioning feeds each automated decision's output back as input: verdicts and holds to the next decision, outcomes to the rules and models.