Recommendation + policy state + evidence + authority + review + exception + outcome
An AI decision record is the structured evidence that explains how a consequential AI supported recommendation became an institutional decision. It preserves the recommendation, applicable policy state, material evidence, decision authority, human actions, exceptions, authorization, resulting action, and outcome context needed to reconstruct why the institution moved as it did. It is not the same thing as an application log or model trace.
The record should explain the decision, not merely the system activity
Enterprise systems already produce large amounts of technical evidence. Logs can show requests, errors, timestamps, and service activity. Model traces can show prompts, intermediate steps, tool calls, or generated outputs. Observability can show latency, health, throughput, and operational behavior.
Those sources are useful, but they do not necessarily answer the institutional question: why was this action permitted, rejected, modified, escalated, or stopped?
A decision record is organized around that question. It connects the material state of the decision so a later reviewer does not have to infer institutional meaning from a collection of unrelated technical events.
A minimum decision record schema
The exact record will vary by workflow, but consequential decisions usually need a common set of fields. The purpose of the schema below is to define the minimum institutional story rather than prescribe one storage format.
| Field | What it should preserve | Why it matters |
|---|---|---|
| Decision identifier | A stable identifier for the controlled decision instance | Allows related evidence and events to be associated with one decision |
| Workflow and version | The workflow, control configuration, or relevant version in effect | Shows which operating logic governed the decision |
| Recommendation | The proposed action or decision state and material context | Establishes what the AI supported path actually proposed |
| Time state | When the recommendation entered control and material state changes occurred | Supports reconstruction when evidence or authority is time sensitive |
| Policy state | Applicable rules, outcomes, constraints, and unresolved conditions | Explains which institutional requirements changed the path |
| Evidence state | Required evidence, source references, freshness, completeness, and conflicts | Shows the factual basis available when the decision moved |
| Authority state | The authority rule, eligible actor, delegation, threshold, or jurisdiction | Explains why the decision maker was permitted to act |
| Human action | Approval, rejection, modification, evidence request, hold, escalation, override, or other material action | Preserves where human judgment changed the path |
| Exception and escalation | Unresolved conditions, exception class, escalation reason, and next authority | Keeps abnormal states inside the reconstructable decision story |
| Authorization | The final permitted action and any limits attached to it | Separates institutional permission from the original recommendation |
| Execution result | What downstream action occurred and whether it completed as expected | Connects the decision to the operational effect |
| Outcome context | Material result available after action | Supports later review and improvement of the control model |
The compact model is: recommendation + policy state + evidence + authority + review + exception + outcome. The additional identifier, timing, workflow, authorization, and execution fields make that model operationally reconstructable.
A decision record is not an application log
An application log records technical events generated by software. It may show that a user opened a page, a service called an interface, or a request returned a status code. Those facts can be important during investigation.
The decision record captures institutional meaning. It should explain which evidence was considered material, which policy condition applied, why a particular authority was valid, what human action occurred, and what action the institution ultimately permitted.
Logs may contribute evidence to the record, but the record should not require a reviewer to reverse engineer the decision from raw system activity.
A decision record is not a model trace
A model or agent trace can preserve the reasoning path of a technical system, including prompts, generated messages, tool calls, intermediate outputs, or retrieval events. That can help engineers understand how a recommendation was produced.
The institutional decision can extend beyond the model trace. Policy may come from another system. Evidence may be supplied independently. Authority may depend on organizational delegation. A reviewer may reject the recommendation. An escalation may move the decision to another actor. The final authorized action may therefore differ from the original model output.
The decision record should connect those institutional states rather than assuming the model trace is the whole decision.
A decision record is not the same as observability
Observability helps teams understand the behavior and health of systems. Metrics, traces, and events can reveal latency, availability, throughput, failure rates, resource use, and other operational characteristics.
A decision record answers a different question. It explains why one consequential decision moved from recommendation to final state. Observability can support that reconstruction, but operational telemetry does not by itself establish the decision basis.
| Evidence source | Primary purpose | Typical question answered |
|---|---|---|
| Application log | Record software and user events | What technical event occurred? |
| Model or agent trace | Expose how the technical recommendation was produced | What did the model or agent do? |
| Observability | Understand system behavior and health | Was the system operating as expected? |
| Decision record | Preserve the institutional decision path | Why was this action allowed, changed, escalated, or stopped? |
Preserve evidence references and decision relevant state
A decision record does not necessarily need to duplicate every source document or data set. It should preserve enough information to identify the evidence used, its decision relevant state, and where the authoritative source can be found when that source remains available.
For time sensitive evidence, the record should make freshness visible. For conflicting evidence, it should show that a conflict existed and how the workflow handled it. For evidence that was required but unavailable, the missing state itself may be material to the decision.
This prevents a later reviewer from seeing only the final action while losing the factual conditions that existed when the decision was made.
Record the authority basis, not only the actor identity
Knowing who clicked approve is not the same as knowing why that person had authority. The record should preserve the authority basis that applied to the specific decision.
That can include role, delegated scope, threshold, jurisdiction, operating state, independent review requirement, override authority, or another contextual condition. If the decision was escalated because the first reviewer lacked authority, that transition should remain visible as part of the record.
This is especially important in workflows where the same actor is authorized for some cases and not others. The decision record should make the contextual boundary reconstructable.
Human action should be represented as a state change
A human reviewer can do more than approve. The record should preserve the material action the person took and the resulting state.
Approval, rejection, modification, request for evidence, hold, escalation, override, and stop can all be meaningful institutional actions. Where rationale is required by the workflow, that rationale should be attached to the relevant action rather than stored as an unrelated note.
This creates a clearer record of how human judgment affected the decision instead of reducing the human contribution to a binary flag.
Exceptions and overrides need their own evidence
Normal path decisions are usually easier to reconstruct because the workflow follows expected states. Exceptions are often where the record matters most.
If a policy conflict, evidence problem, authority gap, system failure, or other exception changes the path, preserve the exception class, the reason it was unresolved, the authority that handled it, and the resulting action. If an override exists, record who was permitted to authorize it, what condition was overridden, what justification was required, and what final boundary remained.
An override should not erase the fact that the normal control path would have produced a different state.
The record should distinguish authorization from execution
A workflow can authorize an action that later fails to execute, executes only partially, or is changed by a downstream system. A useful record keeps those states distinct.
Authorization explains what the institution permitted. Execution explains what actually happened operationally. Preserving both allows a later reviewer to distinguish a decision problem from an execution problem.
This distinction also matters when an authorized action has a limited validity window. If execution happens after the decision has become stale, the record should make the timing visible rather than treating authorization as permanently valid.
Outcome evidence closes the loop without rewriting history
When outcome information becomes available, it can be attached to the decision record as a later state. The outcome should not replace or alter the evidence that existed at the time of authorization.
This separation allows the institution to compare what was known when the decision was made with what happened afterward. That can help identify recurring evidence gaps, overly broad authority boundaries, unnecessary escalation, weak recommendation patterns, or control rules that need to change.
The decision record therefore supports both reconstruction and operational learning while preserving the historical decision basis.
Design the record before production
If the record is designed only after deployment, the workflow may discover that material decision states were never captured. Define the required fields while the workflow itself is being designed.
A practical design review should answer these questions:
- What identifier binds recommendation, control state, human actions, authorization, execution, and outcome together?
- Which recommendation fields are material to the institutional decision?
- Which policy outcomes must remain visible?
- Which evidence references, freshness states, and conflicts must be preserved?
- What establishes the valid authority basis?
- Which human actions can change the decision path?
- How are escalation, exception, and override states represented?
- What exact action was authorized?
- What execution result must be captured?
- Which later outcome fields are useful without altering the original decision state?
If these questions cannot be answered, the workflow may have extensive logging without having a complete institutional decision record.
Where Vidamonti fits
Vidamonti treats the decision record as part of the live control path rather than as an audit artifact assembled after the fact. Recommendation state, policy outcomes, evidence, authority, human actions, escalation, exceptions, authorization, and downstream action can remain connected as the decision moves.
The objective is not to replace existing logs, traces, or observability systems. Those systems remain valuable technical evidence. The decision record provides the institutional layer that explains why a consequential recommendation was allowed to become action.
Explore the product capability in Decision Record, the evidence model in Policy and Evidence, and the authority model in Decision Authority. For the broader category, see From AI Recommendation to Institutional Action.