Every time an agent proposes an action, the platform files a verdict in an append-only record: what was proposed, by which agent under which certificate, on which facts, which bounds were checked, which one decided, and what happened next. Refusals and holds are filed as well as allowed actions. Nothing can be edited afterwards, so any decision can be rebuilt.
What goes into each record?
| Field | What it captures |
|---|---|
| Task and parent task | Where the action sits in a chain of work |
| Agent identity and certificate version | Who proposed it and under what authority |
| Capability and proposed parameters | Exactly what was requested |
| Facts relied on, with provenance | What the agent knew and how far it could be trusted |
| Bounds evaluated | Role scope, certificate, sources, the customer's limits, platform guardrails |
| Deciding bound | Which of them produced the outcome |
| Verdict | Allowed, held, refused or withheld |
| Approver and edits, if held | Who decided and what they changed |
| Result from the target system | Confirmation, reference or error |
| Model and version | Which model produced the proposal |
The deciding bound is the field most logs lack and most investigations need. "Refused" tells you little. "Refused: the agent's certificate for refunds lapsed yesterday" tells you what to fix.
Refusals and holds are recorded because they are decisions too. A refusal shows a control working. A pattern of refusals shows an agent repeatedly attempting something outside its role, which is a signal about its brief or its inputs. Holds show where people are being asked to decide and how they decide. An audit that sees only completed actions sees half the story.
How is the record kept trustworthy?
Append-only. Entries are added, never changed. Corrections are new entries that reference the old.
Tamper-evident. Each entry is linked to the previous one cryptographically, so any alteration breaks the chain and is detectable.
Written before the action. The verdict is filed before the action reaches the target system. If filing fails, the action does not proceed.
Separated from agents. No agent can write to the record directly. Only the platform files verdicts.
Models often produce an explanation of their reasoning. The record can store it, but it is the agent's own account, which may not reflect what actually drove the output. The trustworthy parts are the facts supplied, the bounds checked and the verdict. Build investigations on those.
What does reconstruction look like?
Take a lender that receives a complaint that a borrower's payment holiday was refused without explanation. The complaints team pulls the task. The record shows the servicing agent drafted an approval of the holiday, which is within its depth. The platform held it, naming the customer's limit on consecutive holidays as the deciding bound. A servicing officer rejected the held item but added no reason. The rejection letter was then drafted from a template that did not explain the limit.
Within minutes the team knows the decision was a person's, made correctly under policy, and that the failure was the unexplained letter. Without the record, the complaint might have been blamed on "the AI".
Which rules does a record like this help with?
For high-risk AI systems, the EU AI Act's Article 12 requires record-keeping through automatic logs, and Article 14 requires effective human oversight; a verdict record with approvals supports both. Under GDPR, being able to show the basis for a decision about a person helps you respond to their questions. Outside those, supervisors in most markets expect a firm to be able to show who decided what and why. This is an explanation of the rules, not legal advice; confirm how they apply to you with counsel.
What stays with a person?
Interpreting the record. It shows what happened and why each action was allowed. Whether that was the right outcome, and what to change, are human judgements. People also set retention and decide who may read which parts of the record.
Where Pryme fits
In Pryme, every verdict is filed in an append-only record, including which of the five bounds decided. The record is the same whatever agent or model raised the action, which is why it belongs in an operating system, not a framework. New agents file from their first action; see how to add a new AI agent.
The agentic operating system requirements checklist lists record requirements to test, and the full design is in the governed agentic operating system guide.
Questions people ask
Is the decision record the same as application logs?
No. Logs record technical events. The decision record captures authority: what was proposed, what was checked, and why the outcome followed. You usually keep both.
Who can read the record?
Access should follow need: operations for their own tasks, risk and audit across everything, regulators on request. The record contains personal data, so access is controlled and logged.
Does recording everything create too much data?
It creates a lot, but each entry is small and structured. The cost of not having the entry when a decision is challenged is much higher.