What Is a Decision Ledger?
A decision ledger is an append-only record of the decisions an automated system makes, kept as first-class data rather than as log lines. Each entry records what was decided, the inputs the decision read, the policy and authority it acted under, the action taken, and what changed as a result. Like a financial ledger, entries are never edited in place; corrections are new entries. A decision ledger serves two readers: auditors reconstructing why something happened, and later decisions that must respect what earlier ones committed.
Updated
What is a decision ledger?
The term is new and still settling. It shows up in 2026 writing about AI agents that take consequential actions, such as issuing refunds, changing records and moving money, without a person approving each step. Two lines of thinking feed it.
The first is the "system of record for decisions" argument. In AI's trillion-dollar opportunity: Context graphs, Jaya Gupta and Ashu Garg of Foundation Capital argue that enterprise software records outcomes but not the reasoning behind them, and ask whether new "systems of record for decisions, not just objects" will emerge. Their unit is the decision trace: what happened in a specific case, under which policy, with which exception and precedent.
The second is governance. An August 2026 VKTR article by Hemang Upadhyay describes an agent decision ledger as "a structured record of the evidence, choices, approvals and actions behind every consequential agent-driven outcome," which, like a financial ledger, should be "organized around consequential events." The open-source security project AiSOC uses the phrase for a replayable record of every agent step.
The ideas behind it are older. Double-entry bookkeeping, event sourcing and audit trails all keep an immutable history and derive current state from it. What a decision ledger adds is the decision itself as the unit: not "row 42 changed" but "agent 7 approved refund R for this reason, against this budget, and here is what it read."
How a decision ledger works
A minimal schema:
CREATE TABLE decision_ledger (
decision_id uuid PRIMARY KEY,
decided_at timestamptz NOT NULL,
actor text NOT NULL, -- agent, model or rule ID
decision_type text NOT NULL, -- 'refund', 'credit_limit', ...
subject_id text NOT NULL, -- the account, order or entity
inputs jsonb NOT NULL, -- values read, or a snapshot reference
policy text NOT NULL, -- policy and version applied
verdict text NOT NULL, -- approve / deny / hold / escalate
effect jsonb, -- what changed: amount, record IDs
supersedes uuid REFERENCES decision_ledger(decision_id)
);Three design rules make it useful:
- 1.Record what was read, not just what was decided. "Approved because the customer had no prior refunds" can't be checked later unless the entry shows what the refund history said at that moment, from one consistent point in time.
- 2.Append, never update. A reversal is a new entry with
supersedesset. The history stays replayable. - 3.Write the entry with the effect. If the refund is issued but the ledger write fails, the ledger is wrong. The decision record and the state it changes should commit in one transaction, or through a pattern such as an outbox that guarantees both happen.
Why a decision ledger matters in real-time systems
Most discussion treats a decision ledger as an audit artifact, read after the fact. In concurrent systems it is also live input. Two agents drawing on the same daily refund budget each need to see what the other just approved. If approvals are recorded only in logs shipped to an analytics store, each agent reads a budget that trails reality, and both approve.
So a decision ledger that later decisions read has to be transactional, not just durable. When the ledger and the budget it draws on live in the same transactional store, two conflicting approvals cannot both commit; one sees the other's entry and is rejected or re-evaluated. Tacnode holds this kind of decision state directly: decision records, holds and per-agent limits written by the decisions themselves and read by the next ones, with full transactions on that data. The concurrency side of this is covered in ACID for agents.
FAQ
Related terms
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.
ACID transactions guarantee atomicity, consistency, isolation, and durability, so a group of database operations either fully succeeds or fully fails.
Idempotency means an operation has the same effect whether applied once or many times. Covers its math origin, HTTP methods, and API idempotency keys.
Decision coherence is the property that concurrent automated decisions act on the same version of shared state, instead of contradicting each other.
The blackboard pattern coordinates independent specialists through one shared workspace they read and write, instead of through messages between them.
Decision traces record how individual decisions were made: inputs, policy, exceptions, precedent, approver and outcome, so precedent becomes searchable.
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.