When an AI system proposes or performs work, a useful record should help another person reconstruct the decision. What was requested? What information was available? Who or what authorized the action? What actually happened?

A fluent explanation generated afterward is not a substitute for a record captured as the workflow runs. The explanation may be helpful, but a reviewer also needs the underlying references, identities, decisions, and outcomes.

Separate the stages of the work

Consider a hypothetical assistant drafting a message to a supplier about a delivery change. The draft can exist before anyone approves it. An approval can exist before a sending attempt. A sending attempt can fail.

If one field called “completed” covers all three stages, a reviewer has to guess what occurred. A clearer record distinguishes a proposal, an authorization decision, an execution attempt, and its observed outcome. It should also represent a rejected or abandoned proposal without implying that it was executed.

Start with a decision you can identify

Give the request a stable identifier and describe the particular action. Then connect it to the relevant actor, resource, context, and evidence. A later record should be able to refer to this request without relying on a person’s memory of a conversation.

OWASP’s AI Agent Security Cheat Sheet describes structured records for action context, authorization, approvals, and outcomes. The following example applies those ideas to a deliberately small, synthetic workflow. It is not a prescribed universal schema. OWASP AI Agent Security Cheat Sheet ↗

{
  "request_id": "example-supplier-update-001",
  "action": "send_supplier_update",
  "actor": "example-program-assistant",
  "resource": "example-program-brief",
  "context_version": "context-2",
  "policy_version": "policy-1",
  "decision": "approval_required",
  "human_owner": "example-program-lead",
  "approval_id": null,
  "execution_status": "not_attempted",
  "evidence_reference": "synthetic-supplier-update"
}

Every identifier in this example is fictional. The record says that an approval is required and no sending attempt has occurred. If a later action is approved, the record of that decision should be connected to the request and the context that was reviewed.

Keep context and outcome connected

An approval for one proposal does not explain a different proposal. Record the version of the relevant policy and context so a reviewer can inspect what the decision referred to. If the evidence changes, make the new decision visible.

For an execution attempt, preserve the result returned by the destination and any uncertainty about it. An accepted request is not always the same as a completed business outcome. A failed or ambiguous attempt should remain distinguishable from a successful one.

NIST’s Generative AI Profile discusses maintaining system inventories with oversight responsibilities, provenance, known issues, and model versions, as well as retaining evaluation history. That supports the surrounding documentation practice; it does not define this example’s action-record format. NIST Generative AI Profile ↗

Record enough without collecting everything

A reviewable record does not require copying every source document, private message, or sensitive value into a new log. Decide what evidence is necessary, where it belongs, who may inspect it, and how long it should be retained. References can be more appropriate than duplicated content.

The record itself needs protection. If people can silently rewrite the history or attach an approval to another action, a detailed list of fields will not solve the problem. Identity, access, retention, and the integrity of the stored record need their own engineering decisions.

Use the worksheet for the planning conversation

The AI authority canvas exports a planning brief, not an execution log. Its reference exercise shows how simulated decisions change with scope, ownership, evidence, and approval context. It gives reviewers something concrete to inspect while keeping the limits of the exercise visible.

A practical next step is to take one proposed action and ask whether another person could reconstruct its path from request to outcome. Where they cannot, improve the workflow and the record together.