What belongs in a decision log

A decision log is the complete record of every assignment an AI agent makes: what came in, what the agent decided, how confident it was, what the decision rested on, and whether a person intervened. It is the operator's evidence. When a supervisor, an auditor or a citizen asks why a document went where it went, the log answers in one entry, and the answer does not depend on anyone's memory.

The nine fields every entry needs

Field	What it records	Who needs it
Case identifier	A stable reference for the document or message, linked to the record in the target system	Everyone; it is how a question becomes a lookup
Timestamp	When the document arrived and when the decision was made	Auditors; deadline questions
Input reference	Where the original is stored and its hash, so the input can be shown unchanged	Auditors; disputes
Candidate classes	The classes the agent considered, each with its confidence	The department, for corrections
Decision	The class chosen, or the fact that the case was escalated	Everyone
Confidence and threshold	The certainty of the decision and the threshold in force that day	Operator; audit
Basis	The rule, example or feature the decision rested on, in plain words	Supervisor; auditor
Human intervention	Who overrode, corrected or decided, when, and their reason	Audit; the department
Downstream action	The task created in the target system and its reference	The department; reconciliation

A log without the basis is a log of outcomes, not decisions

Most systems record what happened. Few record why. The difference matters the day someone asks. "Assigned to Building Control, confidence 0.91" answers nothing. "Assigned to Building Control because the document cites a file number in the building register and matches the example set for permit correspondence; confidence 0.91 against a threshold of 0.80" can be checked by a person who has never seen the agent. The basis field is written in the department's words, not the model's, so that the person reading it is the person who owns the process.

The log is the boundary made visible

The agent classifies, extracts metadata, routes into the existing target system and creates a task; it never approves, posts, pays, deletes or triggers deadlines. The log shows that boundary being kept, case by case. Every entry's downstream action is a task created, never a booking made. If an auditor asks whether the agent could have paid an invoice, the answer is not a policy statement but ten thousand entries in which it did not.

Who reads the log, and what each reader looks for

1. The operator, daily: the confidence distribution and the escalation rate, to catch drift before the department does.
2. The department, weekly: escalated cases and corrections, to see where its own process has edges the agent cannot learn.
3. Management, monthly: the hit rate against the agreed target, cases processed, time saved, in the written evaluation.
4. An auditor, on request: the full entry for any case, and the intervention path, as evidence.

Retention, access and the EU

The log is kept for the retention period the organisation sets for the underlying records, in the same jurisdiction as the documents. Access follows the organisation's roles: the department sees its Vorgang, the auditor sees what the audit covers, nobody sees more than their role. Operation entirely within the EU, responsibility from Düsseldorf. GDPR-compliant processing with an AVV included. A complete decision log available as evidence for EU AI Act audits. A defined human intervention path, documented and triggerable at any time.

What the log proves that a report cannot

A monthly report says the hit rate was met. The log shows each case that made up the number and each case that did not. That is the difference between a claim and evidence, and it is why we would rather be judged on the log than on the slide. It is also why the log exists from the first day of the Pilotbetrieb: acceptance in week three is a review of log entries against the department's own judgement, not a demonstration.

Frequently asked questions

Is a decision log the same as an audit trail?

An audit trail records that something happened and who did it. A decision log records why, with the candidate classes, the confidence, the threshold and the basis in plain words. Every decision log is an audit trail; most audit trails are not decision logs, because they stop at the outcome.

Who can see the decision log?

Access follows the organisation's roles. The department sees the entries for its own Vorgang, the operator sees all Vorgänge it operates, an auditor sees what the audit covers. The log lives in the same jurisdiction as the documents and is kept for the retention period the organisation sets.

Does the log include the document itself?

It includes a reference to where the original is stored and a hash that proves the input was unchanged. The document stays in the organisation's own system. The log therefore adds no second copy of personal data, which keeps the data processing agreement simple.

What happens to the log if the operation ends?

It is handed over in a readable format together with the handover document, and the organisation keeps it for its own retention period. The log is the organisation's evidence about its own decisions; it is never held back.

How is the log used during the Pilotbetrieb?

From day one. Acceptance in week three is a review of log entries against the department's judgement, which is how the hit rate is measured. Weeks four to seven use the same entries to tune the confidence threshold and to correct the classes, and the written evaluation at the end is drawn from them.

The decidable next step

If nobody in your organisation can say today why a document was filed where it was, a Pilotbetrieb produces that answer from week three: one Vorgang, fixed price agreed before the start, seven weeks with four of them productive operation on real documents, every decision logged. Request a first conversation. The handover rule the log records is explained in Confidence threshold and the human fallback.