Decision records and responsibilities in AI workflows

A decision record connects a workflow’s outcome to the evidence, authority, actions, and people behind it. It should let someone reconstruct what happened in a particular case, assess whether the decision was acceptable, and identify who must resolve anything still outstanding.

That requires more than preserving the model’s response. A refund recommendation, permission to issue a refund, a submitted payment request, and a confirmed payment result establish different things. When the response to a payment request disappears, the record must preserve the uncertainty and the responsibility for resolving it. When work moves to another person, it must show what that person accepted and which responsibilities remain with the original owner.

This resource develops a practical approach through one hypothetical support case, a reusable record schema, and a responsibility matrix. The approach applies to conventional software, predictive models, language-model workflows, and agents. Its purpose is to make consequential decisions inspectable and unfinished work recoverable. The proposed schema and operating arrangements are design recommendations; the example is constructed.

Define the decision and the obligation it creates

Begin with a bounded business question: which customer’s claim is being considered, what resolution is proposed, and what would establish that the obligation has been discharged?

One case can contain several decisions. A customer selects a purchase, an employee approves an exception, an application authorizes an operation, and a case owner accepts closure. These decisions need separate identities when their evidence, authority, or consequences differ. Linking them prevents a general approval recorded early in the conversation from being mistaken for permission to perform a later, materially different action.

A useful record preserves three related accounts:

• The basis for the decision: the request, relevant facts, applicable policy, material uncertainties, and the proposal.
• The authority and actions: who could approve or execute the proposal, what they authorized, what was attempted, and what the authoritative systems subsequently reported.
• The remaining obligation: which acceptance conditions have been met, what remains unresolved, who owns the case, and who owes each next action.

These accounts can draw on an existing case system, transaction database, document repository, and application logs. There is no need to create a separate tracing platform if those systems already provide reliable links and appropriate access. The requirement is functional: starting from a disputed outcome, an authorized reviewer should be able to find the relevant evidence and follow the decision through its consequences.

Preserve observations and the limits of those observations

Each record should distinguish an assertion from the evidence that supports it.

“The model recommended a refund” records a proposal. “The eligibility check passed” records a checker’s result. “The payment service accepted the request” records an acknowledgment under that service’s contract. None of these statements, by itself, establishes that the customer received the remedy owed.

The same discipline applies to human review. An approval record can establish who approved a specified proposal and what information was available to them. It cannot establish that they understood every document or conducted an adequate review. The competence, workload, and effectiveness of that review require their own assessment.

Keep concise reasons that an operator can examine: the policy provision applied, the evidence supporting a conclusion, an unresolved conflict, or the reason for an exception. Attribute each reason to its author. A model-generated explanation is another output to assess.

In a 2023 study, Turpin and colleagues changed biasing features in multiple-choice prompts for GPT-3.5 and Claude 1.0. The models’ answers changed without their generated explanations acknowledging the influence. That finding concerns the tested models and tasks; it supports treating plausible explanations cautiously rather than assuming they faithfully reveal the process producing an answer. [1]

Do not request or retain hidden chain of thought. Record observable inputs, outputs, tool interactions, control decisions, and concise evidence-based explanations. These support reconstruction of the workflow without claiming access to the model’s internal reasoning.

A complete record can document a wrong or unauthorized decision. Its value lies in making the decision examinable and its consequences easier to address. Correctness, authorization, and record quality remain separate properties.

A refund case from approval to confirmed closure

The following case is entirely hypothetical. The people, policy, identifiers, amounts, and payment-service behavior are invented to illustrate the design. No payment or model execution was performed.

Establish the request and the applicable rule

An authenticated customer reports that a kettle arrived damaged. The account contains two purchases:

Table 1. Constructed order records used throughout the example.

Fictional policy P3 permits a full item refund for reported damage within 30 calendar days of delivery, after the customer confirms the order and remedy. No return is required in this example. Older claims require a support lead’s discretionary exception approval, limited to the item’s paid price.

Maya owns the support case, C17. The model helps interpret the message and present the relevant purchases. The application obtains account identity from authentication, calculates the refundable amount from the order system, and applies the policy.

For this service, closure requires:

1. An authorized refund against the intended purchase and original payment.
2. The payment provider’s defined successful completion state.
3. An internal refund record consistent with that external result.
4. An accurate confirmation available in the customer’s authenticated case view.
5. No outstanding obligation within that service boundary.

The provider’s completion state does not independently establish when the customer’s bank displays the credit. A service that promises confirmation of bank posting would need an additional acceptance condition and evidence.

Bind approval to the current proposal

The customer initially selects O1042 and confirms proposal A1. Before the application commits an operation for dispatch, the customer corrects the selection to O0991.

The application records request revision 2, invalidates A1, and prevents its dispatch. This update is coordinated with the transition that commits an operation for dispatch. If the correction arrived after that transition, the application would first have to establish the earlier operation’s outcome and create any necessary correction work.

The older purchase falls outside P3’s ordinary window. The record therefore shows that routine eligibility failed and that an exception decision is required.

Leo, an authorized support lead, examines the current request, the order record, the absence of a prior refund, and P3’s exception provision. He approves a $60 goodwill refund for the reported damage. His concise reason records the exercise of discretion; it does not convert the customer’s report into independently verified evidence of damage.

Exception approval EX2 identifies:

• Request revision 2 and proposal A2.
• Order O0991 and its original payment.
• The $60 amount and full-refund action.
• Policy P3 and Leo’s authority to approve this exception.
• The evidence reviewed, decision time, and reason.

The customer then confirms A2 separately. Customer confirmation establishes the requested remedy; Leo’s approval establishes organizational permission for the exception.

A changed order, amount, recipient, or material policy basis would require revalidation. Neither confirmation can be reused as general permission for another action.

Record the authorized attempt and preserve uncertainty

The executor checks the current proposal, customer confirmation, exception approval, account ownership, and relevant business-record versions. It also checks that the item has neither a completed refund nor another unresolved refund operation.

For this hypothetical design, both automated and staff-initiated refunds pass through the same controlled service. That service reserves the item and persists operation refund-C17-A2, bound to A2’s immutable arguments, before contacting the payment provider. Reservation bookkeeping has separate coordination state so that creating the reservation does not itself invalidate the substantive order evidence.

The provider response is lost.

The attempt record says response_timeout. The external outcome becomes unknown. The item remains reserved, and the case stays open. The application makes a pending-status message available to the customer and does not issue a replacement refund.

A timeout describes what the caller observed. It does not establish that the remote operation failed. The Amazon Builders’ Library explains this ambiguity and describes a retry design using caller-provided request identifiers, atomic handling of identifiers and effects, and rejection of changed parameters under an existing identifier. Its account also makes clear that duplicate-recognition periods depend on the service. [2]

Here, the fictional provider supports status lookup using the client operation identifier. No retry occurs in the example. In an implementation, the receiving service’s actual retry and lookup contracts would determine the permitted recovery actions.

Hand off reconciliation and complete the case

Maya assigns reconciliation to Ana in payments operations. Ana accepts the task with access to the relevant evidence and permission to query payment status. The accepted handoff specifies the operation, unresolved question, deadline, and escalation route. Maya remains accountable for resolving the customer’s claim.

Ana’s first lookup identifies the original operation and reports that it was accepted but is still pending. The record changes from unknown to pending, retains the provider’s transaction identifier F9, and creates a further follow-up obligation. The reservation remains in place.

A later lookup reports the provider’s defined successful completion state for F9. The application records that observation, posts the internal refund once, and resolves the reservation together with that posting. It then makes an accurate final confirmation available in the customer’s case view.

The closure check examines the current request revision, the authorization bound to A2, the provider result, the internal posting, the absence of a duplicate refund, the unchanged O1042 purchase, and the required confirmation. Maya accepts closure on that evidence.

Table 2. Hypothetical state progression. Each row requires its own evidence; a later state does not erase the earlier uncertainty.

An empty search result would not automatically establish non-execution. Its meaning would depend on the lookup contract, including visibility delays. Similarly, a timeout or routine reservation expiry must not make the item available for a second refund while the first remains unresolved.

The case record explains why an exception was permitted, what the customer confirmed, what the application attempted, what remained uncertain, and how that uncertainty was resolved. It also identifies who carried the case while the specialist performed the recovery task.

Organize the record around operating questions

The schema below is a starting structure. It separates the current case view from the underlying events and evidence. Field names are illustrative and can be mapped to existing systems.

Each case needs an identifiable obligation, decision basis, disposition, accountable owner, and handling rule. Collections for approvals, external actions, and checks are populated when those events occur. A recommendation-only workflow does not need payment-style action fields.

Table 3. A reusable decision-record schema. Each group answers an operating question; it is not a requirement to copy every underlying artifact into every case.

Use shared, versioned manifests for configuration. A case can refer to one manifest identifying the application release, model identifier, prompt or template, tools, authorization rules, and relevant checks. Repeating their full contents in every case adds duplication without improving identification.

Record only the model version information actually available. A provider alias and observation date can be useful, but they do not identify an undisclosed underlying revision. Even a well-specified configuration does not guarantee exact replay when external data, service behavior, or nondeterministic outputs have changed.

An evidence reference should resolve to the version consulted, rather than whichever version happens to be current. Record policy applicability separately from publication or modification dates. The newest document is not automatically the rule governing an earlier transaction or an in-flight request.

Give events enough structure to preserve history

For consequential events, retain an event identifier, case and operation links, actor or originating service, event type, observed time, recorded time, and supporting evidence references. Where ordering matters, use case revisions or explicit predecessor relationships rather than relying solely on timestamps from different systems.

Preserve original and revised proposals. Record later evidence as later evidence. An observation obtained during recovery must not appear to have been available when the original decision was made.

The following abbreviated view shows C17 immediately after Ana accepts reconciliation. Detailed approvals, evidence, and checks remain in the referenced records.

case_id: C17
request_revision: 2
proposal_id: A2
case_state: open
accountable_owner: Maya

authorization:
  policy_ref: P3
  exception_approval_ref: EX2
  customer_confirmation_ref: CC2
  enforcement_event_ref: G2

action:
  operation_id: refund-C17-A2
  payload_ref: A2
  dispatch_state: dispatched
  latest_attempt_result: response_timeout
  external_state: unknown
  observation_ref: E8
  item_reservation: held

open_work:
  - obligation: establish_original_payment_outcome
    assignee: Ana
    handoff_state: accepted
    accepted_at: "2026-10-20T14:06:00Z"
    due_at: "2026-10-20T14:36:00Z"
    escalation_to: Maya

  - obligation: provide_final_case_confirmation
    assignee: Maya
    state: waiting_for_confirmed_payment_outcome
    trigger: payment_outcome_established

Example record view. All values and timestamps are hypothetical. The 30-minute deadline is an illustrative operating choice.

Avoid one overloaded status field. In this snapshot, dispatch occurred, the response timed out, the external outcome is unknown, a specialist accepted the recovery task, and the case remains open. All five statements can be true simultaneously.

Missing values also need meaning. Not applicable, not captured, temporarily unavailable, and unknown outcome imply different operating limits. An absent approval cannot silently mean that approval was unnecessary.

Keep continuing accountability separate from task assignment

Continuing accountability concerns bringing an obligation to an acceptable disposition. Next-action assignment concerns performing a particular task. Decision authority concerns permission to approve an action, exception, deferral, or closure.

A single person may perform several of these functions. Distinguishing them does not require creating separate departments or assigning a committee to routine cases. It requires making the relevant decisions explicit.

NIST’s voluntary AI Risk Management Framework 1.0 calls for documented responsibilities and communication, executive responsibility for development and deployment risks, and planned continuing review. Those principles support explicit assignments; the framework does not prescribe the case schema or organizational arrangement used here. [3]

A responsibility matrix for the example

Table 4. Responsibility matrix for the hypothetical service. The functions can be combined where appropriate; their decision rights remain distinct.

Routine acceptance can be performed by software under an approved rule. The record should then identify that rule and the owner’s delegation rather than inventing a human approval. A discretionary exception needs the actual authorized decision.

Advice from legal, security, or another specialist can inform that decision without transferring ownership of the business outcome to the adviser. The record should show who supplied advice, who held the decision right, and who accepted the resulting operating choice.

Define an accepted handoff

A handoff should identify the receiving person or staffed role, the obligation being transferred, the current state, the evidence location, the required permissions, and the deadline or escalation condition. It should also record acceptance.

Sending a ticket establishes that work was dispatched. Acceptance establishes that the receiving party has taken responsibility for the specified next action. A staffed queue can provide that acceptance through a defined intake contract, provided its duty owner and escalation route are identifiable.

Until acceptance, the sending party retains responsibility for arranging the next action. If the recipient declines, lacks access, or cannot meet the deadline, the record should preserve that result and route the problem back to someone who can act.

Transferring overall case accountability requires a separate explicit acceptance. A shift change can transfer both the case and its outstanding tasks, but assigning Ana a payment lookup transfers only that task.

Several obligations may proceed in parallel. Reconciliation can sit with payments operations while customer communication remains with support. A single “next owner” field would conceal that division; an open_work[] collection can preserve it.

Acceptance does not remove uncertainty

A person may authorize a bounded delay while payment status is investigated. That decision should state what is unresolved, why the delay is acceptable within their authority, what may continue, and when the decision expires or must be revisited.

Such acceptance does not make the payment successful. It also does not permit the approver to waive constraints outside their authority.

Similarly, repairing a technical defect does not necessarily resolve an affected customer’s case. A restored balance may leave a fee, an inaccurate notice, a disclosure, or a missed deadline requiring separate action. Keep those consequences assigned until the relevant acceptance conditions are met.

Preserve necessary evidence without duplicating sensitive inputs

The record should retain enough evidence to answer its operating questions. Copying every input into a broadly searchable log can create an unnecessary second repository of customer, employee, or confidential business information.

Choose among three forms of evidence retention:

• A restricted, versioned reference when the authoritative source will remain available to the appropriate reviewers.
• A narrowly scoped extract when a specific passage or field set is necessary and retaining the whole source would add exposure.
• A protected snapshot when later reconstruction genuinely depends on the exact input and the source cannot otherwise preserve it.

The choice should follow the reconstruction need. In C17, the operational record needs order identity, relevant dates, paid amount, prior-refund state, the customer’s request and confirmation, and the approval. It does not need payment credentials or unrelated correspondence.

OWASP’s logging guidance recommends limiting direct recording of credentials, sensitive personal information, and payment data, and protecting records against unauthorized access and alteration. It also addresses retention of copies and extracts. These are relevant safeguards for a decision record, even when that record lives outside a conventional logging system. [4]

Make restricted references usable

A reference should identify the source system, object and version, relevant location, access route, and responsible custodian. It should distinguish the source’s effective date from the time it was retrieved.

For retrieved documents, preserve the passages actually supplied to the model or reviewer when they are material to the decision. A search index version alone cannot establish which passages appeared in a particular context. Conversely, a record of supplied passages cannot establish that the search found every relevant exception.

Before relying on a reference, determine whether it will remain resolvable for the intended review period. If the source expires sooner, choose deliberately between retaining a permitted extract, arranging appropriate source retention, or accepting a documented reconstruction limit.

A content hash can help detect a changed object. It cannot recover deleted content, establish source authority, or demonstrate what the model attended to. Hashing sensitive information also does not automatically make it anonymous.

Preserve qualifications when redacting

Redaction should remove unnecessary identifying or confidential material while preserving the meaning needed for review. Removing the date that determines eligibility, the exception that changes a policy, or the role that establishes authority can make a record misleading.

Keep the redaction method or version identifiable when it affects interpretation. Where necessary, provide different views: a limited operational view, a restricted evidence view, and an export suitable for a particular audit or dispute. Access to the case summary need not grant access to every underlying document.

Treat copied customer text and retrieved documents as untrusted content when displaying or processing records. Their presence in an evidence repository does not give them authority to change workflow instructions or permissions.

Set retention by purpose and applicable obligations

Assign responsibility for deciding the record’s purpose, permitted users, retention trigger, review or deletion date, and any authorized exception. The summary record, detailed evidence, and temporary diagnostic data can have different schedules.

There is no universal period proposed here. Retention choices must reflect the actual business purpose and applicable requirements. A possibility that someone might ask a question years later does not, by itself, justify indefinite collection and retention.

Deletion and correction processes should cover replicas, exports, and extracts as appropriate. When evidence is removed, preserve a permitted indication of the resulting reconstruction limit where necessary. An append-only design should protect history during authorized retention without silently becoming a requirement to retain every sensitive payload forever.

Keep the record reliable when the workflow fails

The record is most valuable during interruptions, disputes, and corrections. Its construction should therefore follow the same failure boundaries as the actions it describes.

For a consequential action requiring retained authorization, persist the proposal, applicable authorization, and operation identity before dispatch. If that required business record cannot be stored, hold the action or route it through an authorized alternative. This is a transaction precondition for that action, rather than a requirement to stop all work whenever optional diagnostic logging fails.

After dispatch, inability to store a response creates a recovery problem. It does not establish that the external action did not occur. Resume using the durable operation identity and the receiving service’s authoritative observations.

A local transaction can preserve the intent to send a request and the obligation to follow it up. It cannot establish that a remote service completed the operation. Record the remote evidence separately.

Protect the record from the component whose behavior it describes. A model may propose a reason or summary; it should not be able to fabricate an authoritative payment observation, rewrite an approval, or remove an adverse check. Attribute observations to authenticated services and people, and control changes to the resulting records.

Preserve corrections as linked events during the authorized retention period. A corrected amount or later finding should identify what it supersedes and why. The current case view can show the latest accepted state while retaining the history needed to understand earlier actions.

Integrity controls can help detect alteration. They do not establish that the original entry was true or that omitted events never occurred. Compare consequential records with the systems that own the underlying facts.

Use the record for audits, correction, and change assessment

Decision records support several different forms of review. Their value depends on keeping those purposes distinct.

Audit whether the case met its requirements

An auditor should be able to move from a case disposition to the decision basis, permission, external effect, required communication, and closure decision. The relevant question is whether the acceptance conditions were met with adequate evidence.

Keep an intake index that includes rejected, withheld, repaired, and unfinished cases, as well as successful closures. Otherwise a later audit may have no way to examine work that disappeared before producing a polished result.

A well-recorded individual case does not establish a service-wide error rate. Population claims still require appropriate sampling and valid judgments. The record supplies observations for that work.

Correct the outcome without rewriting the original decision

When new evidence arrives, append it with its observation time and connect it to the affected decision. Preserve what was known earlier.

If a reviewer discovers that Leo lacked exception authority at the time of EX2, a later approval cannot make the original execution authorized retroactively. The case needs an explicit finding, an assessment of its consequences, and any required remediation.

If an apparently completed refund later fails under the provider’s process, record the new state and reopen or create the linked obligation required by the service contract. The prior closure remains a historical decision made on its stated evidence.

Identify which decisions a change affects

Version references make an affected-case search possible. A team can locate cases using a withdrawn policy, defective parser, changed permission rule, or problematic model configuration.

The search result should state its coverage. If a provider exposed only a stable alias, the record may identify a potentially affected period without identifying the precise underlying model revision. Missing records similarly limit the cases that can be found.

Reassessment should address the changed mechanism. A policy change may alter future eligibility. A defect may require reviewing earlier decisions. A new permission expands possible consequences. These changes require different evidence and responses.

Replaying a recorded case can support investigation, but a replay should be isolated from live side effects and identified as a new execution. Its outcome does not replace the historical record or establish what happened originally.

Test whether another operator can resume the work

Before expanding collection, use a completed case and an interrupted case to inspect the record design. Ask a qualified operator who did not handle them to identify the applicable decision, locate its evidence, distinguish confirmed facts from unresolved observations, and name the person responsible for the next action.

If the operator cannot do that, locate the missing relationship: an inaccessible source version, an approval without a bound action, an ambiguous payment state, or an unaccepted handoff. Add the information that resolves that failure. Additional logging is useful when it answers a defined question.

References

Primary sources checked November 2, 2026.

1. Turpin, M., Michael, J., Perez, E., and Bowman, S. R. (2023). Language Models Don’t Always Say What They Think: Unfaithful Explanations in Chain-of-Thought Prompting. NeurIPS 36. Sections 3.1-3.3.

2. Featonby, M. Making retries safe with idempotent APIs. Amazon Builders’ Library. Live article; no publication or revision date displayed in the inspected page.

3. National Institute of Standards and Technology (2023). Artificial Intelligence Risk Management Framework (AI RMF 1.0). NIST AI 100-1, January. Executive Summary and GOVERN categories.

4. OWASP. Logging Cheat Sheet. Live guidance; no publication or revision date displayed in the inspected page. Sections on excluded data, event collection, protection, and disposal.