Decision Token

also known as Per-Action Authored Justification, Decision Token (Authored Justification)

Mint a self-contained record at the moment a consequential action executes, bundling the rule that fired, the exact data read, the conclusion reached, and the authorizing identity.

Context

An agent takes consequential actions in a regulated setting such as a bank approving a transfer, an insurer settling a claim, or a clinical tool flagging a case. A supervisor can later demand, for any single action, a defensible account of why it happened, and that account must hold up even after the model has been updated, the prompt has changed, and the surrounding logs have rotated.

Problem

An action-only record proves that the agent did something but not that the action was justified, and reconstructing the justification later depends on logs that were never designed to carry it, a model version that may no longer exist, and inference about what the model was probably weighing. When a supervisor asks why one specific transfer was approved, an after-the-fact narrative assembled from scattered traces is both expensive to produce and easy to dispute, because nothing ties the rule, the data, and the conclusion together at the instant the action committed.

Forces

A defensible account is cheap to capture at execution time, when the rule, the input data, and the conclusion are all in hand, and expensive to reconstruct afterward from logs that rotate and models that change.
A regulator wants one self-contained artifact per action, not a query across several systems that each hold a fragment of the story.
Capturing the full justification inline on every action adds storage and latency, so the granularity of what counts as consequential must be chosen deliberately.
The token must bind to the specific model version and data snapshot that produced it, or its account drifts out of date the moment the system is upgraded.

Example

A bank's agent approves a EUR 40,000 transfer. In the same step that commits the transfer, it mints a signed Decision Token: rule fired is 'large-transfer review under threshold EUR 50,000', data read is the customer's 90-day balance and prior payee history, conclusion is 'within established pattern, approved', authorizing identity is the agent's service account under policy v7, model digest and timestamp attached. Months later a supervisor asks why that one transfer was approved, and the bank hands over the token rather than reconstructing the reasoning from scattered logs.

Diagram

flowchart TD A[Agent proposes consequential action] --> M[Token Minter assembles rule + data + conclusion + identity + model version] M --> S{Complete signed token?} S -- no --> R[Action rejected, does not commit] S -- yes --> W[Write token to append-only store keyed by action id] W --> C[Action commits] C --> Q[Supervisor later reads one token per action]

Solution

Therefore:

Wrap every consequential action so that committing the action and minting its Decision Token are a single step. The token captures, in human-readable form, the policy or rule that fired, the precise inputs the agent read, the conclusion it reached, the identity that authorized the action, and the model version and timestamp that produced it. The token is signed and written to append-only storage keyed by action identifier, so it stands on its own without depending on surrounding logs. Because the justification is authored at the moment of execution rather than reconstructed later, the artifact handed to a supervisor is the token itself, and an action that cannot mint a complete token does not commit.

What it gives you

Any single action has a self-contained, signed account of why it happened, produced at execution time rather than reconstructed from rotated logs.
A supervisor receives one artifact per action instead of a cross-system query, lowering the cost and the disputability of an explanation.
Binding the model version and data snapshot into the token keeps the account valid after the model or prompt changes.

What it costs you

Minting a full token on every consequential action adds storage and per-action latency that grows with action volume.
A token is only as honest as the conclusion text the agent writes into it; a confident but wrong rationale is recorded as faithfully as a correct one.
Choosing what counts as consequential is a judgement call, and drawing the line too narrowly leaves un-tokenized actions a supervisor can still ask about.

What this pattern forbids. A consequential action cannot commit unless a complete, signed Decision Token naming the rule fired, the data read, the conclusion, and the authorizing identity is written to the token store in the same step; post-hoc reconstruction does not satisfy this requirement.

And the patterns that stand alongside it, or against it —

complementsDecision Log★★— Persist the agent's reasoning trace alongside its actions so post-hoc review can explain why.
complementsProvenance Ledger★★— Log every agent decision and state change with enough metadata to explain or reverse it later.
alternative-toDeontic Token Delegation·— Reify obligations, permissions, and prohibitions as transferable deontic tokens that agents pass along the delegation chain with provenance, so duty and accountability transfer with the work, not only the credentials to perform it.
complementsPolicy-Gated Agent Action (KRITIS)★— Each agent action passes through a policy gate (NIS2, EU AI Act, BSI rules) and is tagged with Run ID + Model Digest + Policy Hash for WORM-audit reconstruction.