The Decision Record: Evidence as a Side Effect of Running

The control most firms are missing is not a policy that says decisions must be logged. It is that the decision cannot be produced without producing its log. A record written by a person after the fact can be forgotten, contested or lost. A record emitted by the step that decides, as a side effect of executing, is what the process leaves behind because it could not have run otherwise.

This is the evidence strand of configured is not controlled. The regulatory demand for it is in what GDPR, NIS2, DORA and the EU AI Act ask of a system that acts, and the typed decision that emits it is in text is not a decision. This post is about the record itself, the Zero Trust that protects the agent producing it, and what both buy you when a supervisor calls.

What a decision record carries

Every consequential step emits a record with a fixed set of fields. It ties the decision to a business object and the exact workflow version, reconstructs the bounded option space, hashes and classifies the inputs relied on, lists the deterministic check outcomes, states the distribution and the threshold in force, says whether a person was involved and what they changed, and names every version that shaped the outcome.

decision record
  case:        CLM-2026-04471
  workflow:    claims-routing            release: 2026.09.3
  question:    choice  "Route this claim"
  options:     fast-track · standard · investigate · escalate   options: v7
  inputs:      source sha256 3f9a…c21   classification: client-confidential
  checks:      mandatory-fields PASS · policy-active PASS · limit-within PASS
  p:           0.71 · 0.19 · 0.07 · 0.03
  confidence:  0.61        threshold: 0.55 (v4)      result: fast-track
  review:      not required by threshold
  model:       routing-head v3.2   prompt: v11
  at:          2026-09-26T14:02:11Z   by: svc-claims-agent   envelope: env-claims-04

The value of the inputs hash is that an affected population can be found by source. The value of the version fields is that an incident report can say what was running. The value of review is that supervision is shown, not asserted.

Zero Trust, one level down

"Never trust, always verify" is the foundation of the modern estate, and it is applied to users and devices: identity, conditional access, least privilege, monitoring. In the agentic era the same principle has to apply to the agent's actions, because the agent is a principal that composes its own actions at runtime. Least privilege on its login says nothing about which tool it calls next, with what arguments, on whose behalf, or whether it was manipulated into calling it.

The control is a delegation envelope. Each agent operates inside attested limits: which tools it may call, which data classes it may read, which option sets it may decide over, which spend or size it may commit. The keys that sign consequential actions sit outside the agent and refuse anything outside the envelope, so a compromised or hallucinating agent cannot exceed its limits, because the limit is enforced by something it does not control. Every tool call is checked against the envelope before it executes and logged whether or not it passes. Every input is treated as untrusted, so prompt injection, poisoned documents and manipulated retrievals are handled by filtering and by the envelope, not by asking the model to be careful.

That last point catches the data-leak path most policies miss. The obvious leak is a prompt sent to an external model, and classification-driven routing handles it. The quiet one is a retrieval that reaches too far: an agent with broad read access pulls whatever scores highest, and a badly scoped index means a client's file appears in another client's answer. No data left the firm, no policy was broken, and the estate saw a permitted read. The control is the workflow's approved-input contract, enforced by the harness rather than requested of the model.

Four properties that make a run verifiable

A harness is the layer between a capable model and everything it can touch. On Fulcrum, four properties do most of the work, and each answers a question from earlier in the argument.

• Offline verification. A completed run produces a signed evidence bundle a third party verifies in a fixed sequence of deterministic steps, with no network access, no call back to us, and no need to re-run the workflow or hold the model. Bundles are Ed25519-signed and verify on a laptop with the wifi off.
• Default-deny capabilities, fixed at the session boundary. An agent's capability set is granted explicitly at the start of a session and cannot widen during it, so prompt injection cannot acquire a tool the session did not start with.
• Deterministic controller dispatch. Which agent runs next is decided by a controller, not by a model improvising a plan. Two runs are comparable, and the eight stages of a controlled workflow are a dispatch table, not a suggestion.
• Typed, signed handoffs. Work passed between agents is a typed structure with a signature, not free text, so an agent that reads untrusted documents cannot pass an instruction to an agent that holds write capability.

The bundle holds the inputs and their hashes, the capability set the session was granted, every dispatch the controller made, the signed handoffs, the computations and the engine that performed them, the constraints evaluated and their results, and every approval with the identity that gave it. It deliberately excludes credentials, raw untrusted documents, and prompts as proof, because a prompt is evidence of intent, not of behaviour.

Governance rendered from state, not maintained beside it

Underneath, a run emits a graph, not a log. Fulcrum records each run with PROV-O, the W3C vocabulary for what was derived from what, by which activity, under whose responsibility; querying is SPARQL and checking is SHACL, so a violated compliance shape is a rejection recorded at the point the constraint was breached, not a finding in a report written afterwards. Because the vocabulary is standard, an auditor's own tooling can read the chain without us shipping a viewer.

That changes what governance costs. A model card becomes the versions emitted in every record. An impact assessment carries its evaluation results and affected-population counts, updated as the workflow runs. Post-deployment monitoring becomes four numbers watched weekly: confidence drift, abstain rate, escalation rate and reviewer disagreement. The documents still exist and a supervisor will still ask for them, but they are rendered from the workflow's state rather than maintained beside it, so they never go out of date and never contradict the record.

Reporting inside the window

Here is what the record buys on the worst day. Suppose an agent processed four hundred client communications on Tuesday using an input that turns out to have been tampered with. Filter the records on the source hash. Twenty-three match. Eleven were escalated and caught; twelve went through under threshold. Names, times, approvers and versions are in the record. The early warning is filed that afternoon, and the notification inside seventy-two hours has a population, not an estimate.

Without the record, the same incident is a reconstruction from application logs, a model gateway and three people's memory of what they approved. The report is late and the caveats are long. You cannot report in a day what it takes a month to reconstruct, which is the whole reason to build the record before you are asked for it.

Have an AI workflow the compliance dashboard is green on? Bring it. We will build the controlled version inside your stack with the record attached, and leave you owning it. Download the field note, or send us the workflow.

The decision record, the evidence bundle and the harness properties are drawn from the Rob-otix Ai field note "Configured is not controlled" (2026). Figures in the incident example are illustrative.