How to build an audit trail for AI decisions

A customer asks why an AI workflow accepted a supplier's payment terms. The team finds the model response, the tool calls, and an approval, but the contract at the linked URL has changed. The trace still opens. The team cannot establish which terms the reviewer accepted or whether the payment system ever received them.

A useful audit trail must let a permitted reviewer reconstruct that business decision from retained evidence. It should also show where reconstruction stops: a missing source, an unresolved conflict, or an action whose result remains unknown. A fluent explanation generated after the complaint cannot fill those gaps.

We will follow one illustrative supplier case from conflicting documents through review, execution, and a later amendment. The records below are a proposed design, not a client result or a statement about how every contract must be interpreted. A business owner must define the applicable rules before a workflow can enforce them.

Follow one decision from proposal to confirmed action

In our example, the AI proposes the 60 days requested in a later email, although the signed supplier agreement says that payment is due in 30 days. For this workflow, the procurement owner has specified that an unsigned request does not change the accepted term without an authorized amendment.

The reviewer corrects the proposal to 30 days and records why the email does not control this case. The system then prepares an update to the payment system. Approval of that update and confirmation that it happened are separate records, because a correct decision can still fail during execution.

The accepted decision can remain valid while the action is pending or its result is unknown, so a single "done" field would hide the stage that still needs attention. Our permissions guide develops the approval and expected-state checks behind that distinction.

Connect the business record to its execution trace

A trace can already contain useful business attributes. OpenTelemetry's trace documentation describes spans with attributes, events, and links, so the design depends on which business facts the product records and how long it retains them. We still need stable relationships that survive separate runs, human reviews, and later case updates.

The record below describes the case immediately after the first payment-system update has been verified, using readable labels for the stable identifiers that connect its evidence and review. A deployed system would also retain actual timestamps and authenticated actor references. This is a review view across connected records, not a requirement to put every field in one database table.

The proposal should point to the run's model identifier, prompt or workflow version, retrieval configuration, and tool results where those affected the recommendation. Those details help explain a failure without forcing the business reviewer through every span. Retain the explanation that was shown to the reviewer as a produced output, not as proof of the model's hidden reasoning.

There is an established vocabulary for these relationships. The W3C PROV primer describes entities, activities, responsible agents, and derivation between versions. In that vocabulary an agent may be a person or software, rather than specifically an AI agent. Our decision and review records apply those ideas to this workflow; the business-specific approval rules remain ours to define.

Extract candidates before asking for a decision

At ingestion, the application assigns identifiers to the source version and its passages, then stores the parsed text with the original document reference. The model receives those identifiers with the text. It can select evidence from that supplied set, but it cannot create an authoritative source reference by writing a plausible identifier in its response.

For the supplier case, ask the model to extract a candidate from each document before choosing a payment term. Capture the agreement reference, parties, proposed document type, term, effective-date language, and missing information. A document's description of itself remains a claim to check; the word "signed" in a filename does not establish approval authority.

The following JSON is a shortened illustrative extraction result, not a complete API schema. The labels refer to versions and passages supplied by the application. The model has found both values, but has not established whether the email can change the agreement.

{
  "agreement_ref": "supplier-agreement",
  "candidates": [
    {
      "source_version": "agreement-A",
      "passage_ref": "payment-clause-A",
      "document_type_claim": "signed_agreement",
      "payment_days": 30,
      "authority_status": "unverified"
    },
    {
      "source_version": "email-A",
      "passage_ref": "request-paragraph-A",
      "document_type_claim": "change_request",
      "payment_days": 60,
      "authority_status": "unverified"
    }
  ],
  "missing_information": ["authorized amendment for the requested change"]
}

Use a defined output schema so downstream code receives predictable fields, including explicit unknown values instead of guessed facts. OpenAI's Structured Outputs documentation distinguishes schema adherence from mistakes in the content. A correctly typed payment_days value still needs evidence checks before it can influence the accepted decision.

Validate evidence before applying the business rule

Validation has several jobs that should remain distinguishable in the record. Ordinary code can check whether a reference exists, belongs to the case's organization, and points to the retained version. It can also check required fields and allowed value types. Those checks cannot establish that a clause governs this agreement or that an email sender could authorize a change.

For meaning, compare the extracted value with the cited passage and its surrounding definitions. A model can help identify an exclusion or a conflicting clause, but its assessment needs evaluation against expert-reviewed examples. Keep unresolved interpretation visible, and use authenticated business records or an authorized reviewer to establish authority where document text alone is insufficient.

Suppose the agreement's status is confirmed through the contract record, but no authorized amendment can be found for the email. The extraction of 60 days is valid as a request. Selecting it as the accepted term is the error, which belongs in rule application rather than being reported as an extraction failure.

The orchestration layer can create the following result from those checks. It preserves the rejected proposal and prepares the conflict for procurement; the model does not get to turn a missing authority check into an approval by explaining its preference for the newer source.

{
  "proposal_ref": "proposal-A",
  "proposed_payment_days": 60,
  "evidence_check": "request_value_supported",
  "rule_version": "procurement-rule-A",
  "acceptance": "blocked",
  "reason": "amendment_authority_not_established",
  "next_step": "procurement_review",
  "review_input": {
    "candidates": ["agreement-A", "email-A"],
    "proposed_term": 60,
    "signed_agreement_term": 30,
    "unresolved_question": "Does an authorized amendment change this term?"
  }
}

Persist the review and control what can resume

The review interface should show the evidence conflict, the applied rule, and the exact proposed action beside the editable decision. When procurement selects 30 days, save a new review referencing the proposal and evidence set. Record the authenticated reviewer, reason, and scope so a later run can use the accepted result without erasing what the model proposed.

Persist the pending review before suspending execution. On resumption, load the saved review and compare its evidence references, rule version, and target state with current values. The workflow should either continue with an approval that still applies or create an explicit stale-review state; it should not ask the model to infer permission from conversation history.

LangGraph's persistence documentation describes checkpoints for saving workflow state and recovering execution. That mechanism can support the pause, but checkpoint recovery does not establish that a business approval remains valid. The version checks and permitted transitions must still be implemented in the application.

Keep case identity, review identity, and external operation identity separate. An external update that times out must enter reconciliation using its operation reference, rather than start again because the workflow resumed. Where the destination supports idempotency, reuse the operation's key; otherwise the implementation needs a destination-specific way to check whether the first action happened.

The human correction also needs a destination of its own. A case correction updates this review; an evaluation candidate enters a curated test set; a proposed policy change goes to its owner. Do not update prompts, retrieval rules, or training data directly from every reviewer edit, because the scope of the edit may be narrower than the shared behavior being changed.

Use dependencies to turn an amendment into review work

When the amendment arrives, retain it as a new version and extract its changed terms and effective scope. Compare it with the previously accepted evidence, using exact field comparisons where possible and semantic comparison where clauses have been rewritten. The comparison should return changed findings, unchanged findings, and unresolved matches rather than only a narrative summary.

Use stored dependencies to select candidate decisions before letting a model explain their impact. In this example, the dependency connects the agreement's payment clause to Decision A and its payment-system action. If the comparison cannot match the clause reliably, select the broader known agreement dependencies and mark impact unresolved instead of clearing the cases.

A review-work record can be created before the new term is accepted. The example below shows that selection has found a candidate, while its business applicability and the next decision still belong to the review process. It does not authorize an immediate update to the payment system.

{
  "trigger_version": "amendment-A",
  "candidate_decision": "decision-A",
  "dependency": "agreement.payment_term",
  "change": {"previous_days": 30, "proposed_days": 60},
  "scope_status": "requires_owner_confirmation",
  "review_status": "pending",
  "review_queue": "procurement",
  "prior_decision": "retained",
  "external_action": "not_authorized"
}

Record the event that created this work and deduplicate repeat delivery against the same decision and source change. Otherwise a retry can create several reviews for one amendment. A later amendment must remain a separate event, with an explicit relationship to any pending review so the owner can see whether its evidence has already changed again.

Choose stages that make failures diagnosable

One model call can produce a proposed extraction, conflict analysis, and recommendation, which may be useful for an early prototype. It still needs application checks before acceptance. If all intermediate reasoning is reduced to a final answer, the team loses the evidence needed to distinguish retrieval, extraction, authority, and selection failures.

For this workflow, a fixed sequence of extraction, validation, rule application, and review offers explicit boundaries without requiring several agents. Independent documents can be processed in parallel, but the same rule and review path must reconcile their findings. Add an agent when the task needs an investigation that chooses where to search next, rather than to give each stage an agent label.

Separate stages introduce their own cost: more stored state, versioned interfaces, and potentially more model calls. They are useful when their outputs let the team retry a failed extraction without repeating a confirmed external action, inspect a rejected proposal, or compare a new model on the same evidence. Those are concrete benefits to test against the simpler design.

Evaluate the stages on the same controlled supplier cases and keep an end-to-end test as well. A human may rescue a poor extraction and make the final decision look correct, while a correct extraction may feed an incorrect precedence rule. Reporting only final acceptance would hide both the reviewer workload and the source of the defect.

Capture the basis when the decision is made

Preserve the later email with its version, passage, agreement identity, status, and effective scope, because it remains relevant evidence even though the reviewer rejects its authority for the selected term. A citation to the right sentence cannot explain the choice if the record has lost whether the document was a request or an accepted amendment.

The record also needs two different times: when the workflow obtained the evidence and when the evidence applies to the business case. An amendment can arrive after its stated effective date. Without both times, a reviewer cannot distinguish an earlier decision made with the available evidence from a later reassessment that uses newly received information.

Record the proposal's evidence references before it enters review, then bind the accepted review to that exact version. If a required reference cannot be saved, leave the decision unaccepted and route the failure to its owner. Otherwise the product can create an approved outcome whose basis was never recoverable, even if later log searches appear complete.

A stable record is not automatically protected against alteration. Restrict who can change accepted records, add corrections as linked revisions, and record administrative changes through a separately controlled path. An append-only application screen is insufficient if the same account can silently replace the underlying evidence. The required protection depends on the threat the buyer needs to investigate.

If the workflow later calculates a due date from the accepted term, preserve the invoice date and the calendar rule used by that calculation. Keep the distinction between a source value and a derived result. The same requirement applies to numerical findings with units or conversions: a cited input alone does not explain the calculation.

Preserve what the reviewer changed and what they approved

Review A corrects a proposal for this agreement. It does not establish that every email must always lose to every signed document. The accepted procurement rule and the evidence status explain this particular choice; a valid amendment could produce a different result without either review being inconsistent.

A data correction, case exception, and shared-policy change need different records because they authorize different future behavior. If the reviewer grants a temporary exception, retain its agreement scope and end condition. If they propose a policy change, route it to the policy owner instead of silently treating the correction as training guidance for other cases.

An approval covers the facts presented at review. Suppose the amendment arrives after acceptance but before the payment-system update is sent. The workflow should compare the current evidence and target state with the approved versions, then suspend the affected action when they no longer satisfy the approval conditions. The pending review needs a named owner and a reason the operator can inspect.

Now suppose the update is sent, but the request times out before confirmation returns. The decision is still accepted; execution is unknown. Keep the operation reference and reconcile against the target system before repeating the change, because the first request may already have succeeded. The guide to unfinished agent work explains why reported success needs an independent completion check.

Decide which changes require reassessment

When procurement later receives an authorized amendment accepting 60-day terms for the same agreement, the owner records its effective scope and decides which open or completed cases require review. The workflow can then find decisions that used the earlier term without assuming that the arrival of a newer document invalidates every earlier outcome.

A document-level reference can identify candidate cases for review, but it cannot prove that an unrelated formatting change affected the payment finding used by an accepted decision. Linking the finding to the relevant clause and extracted value enables a narrower review, provided extraction and dependency checks support that precision.

A model's summary that "nothing material changed" is not enough to dismiss a case when the relevant clause could not be recovered. Start with the known document dependencies and expand to the affected agreement's case list if those links are incomplete. Show the uncertainty explicitly so an operator can choose a review scope rather than mistake a failed comparison for a clean result.

Selecting a case for review leaves Decision A as the historical record of the 30-day acceptance while the new review is pending, without automatically reversing the earlier outcome. The owner must separately decide whether continued use of that decision is allowed, paused, or limited during reassessment; "under review" alone does not tell downstream systems what they may do.

After the new review, Decision B records the accepted 60-day term for its specified scope and links back to Decision A. The current view identifies A as superseded where B applies, while earlier cases outside that scope retain their prior outcome and an exclusion reason available to the reviewer. This avoids rewriting history to make an earlier decision appear to have used evidence that arrived later.

Choose what evidence to retain

A working source URL is convenient, but its continued availability is a dependency the buyer must choose to accept. The choice between a full version, a relevant excerpt with context, and a controlled archive reference determines how much a reviewer can reconstruct and what storage and access controls are needed.

For the supplier case, an excerpt of "30 days" would be too narrow if another clause defines when the period starts. Retain enough context to reconstruct the specific decision, and document what the chosen record cannot establish. Our RAG guide covers source parsing and retrieval failures that can remove this context before a proposal reaches review.

When a source expires, is deleted under the approved retention process, or becomes inaccessible, the review view must distinguish those states. Do not silently replace the citation with the latest contract. Show that the historical decision remains recorded but its source cannot currently be inspected, then route any required reconstruction or reassessment to the designated owner.

Retention is a lifecycle decision, not an instruction to store every prompt and document forever. Agree the retained fields, access roles, retention period, deletion process, and remaining explanatory limits with the responsible data owner. Apply that choice to copies, exports, and diagnostic storage as well as the primary record, so the product's description matches what it actually retains.

Give each reader a permitted explanation

The supplier may need the accepted payment term and permitted supporting language, while procurement needs the source versions and review history to explain how that term was selected. An engineer may need diagnostic events without access to unrelated commercial records. These views should derive from the same decision references so their differences reflect permissions rather than conflicting accounts of what happened.

Check access when a person opens the evidence, including a direct citation or export. Earlier authorization to process a document does not by itself define who may download it later. In a denied view, show that evidence is restricted without leaking its contents through an excerpt, filename, or generated explanation. Test those routes with the intended reader roles.

Reconstruction has a further limit: the record can establish what evidence was retained, what the reviewer accepted, and what the target system confirmed. It cannot prove every influence on a model's output, guarantee that the original decision was correct, or make a rerun reproduce it. Keeping these limits visible is part of a useful review, especially when evidence is incomplete.

Turn the supplier case into an acceptance demonstration

Ask the team to run the illustrative case with controlled documents and named test roles, then inspect the result through the business review screen. Keep the original records available as each change is introduced. The demonstration should show the accepted outcome and its supporting records without requiring an engineer to assemble an explanation from logs after the fact.

To check case selection as well as the individual review screen, seed an affected case and a case outside the amendment's scope, then verify why each was included or excluded. If the system cannot account for the candidate set, it has not demonstrated that it found the decisions requiring review.

Record failures as specific acceptance requirements with an owner and an observable expected result. "Improve auditability" is difficult to test; "preserve the prior decision when a new amendment triggers review" can be inspected directly. Our evaluations guide explains how to turn observed failures into checks without replacing domain judgment with a general quality score.

Scope the first build around a disputed case

For a buyer, the first useful output is a reviewed case record and a change demonstration. Bring the workflow owner who defines acceptance, the reviewer who resolves conflicting evidence, and the data owner who sets access and retention. The engineering team can then identify which relationships already exist and which must be added for that workflow.

Use one agreement, one accepted decision, and one relevant change to specify the missing records, review transitions, execution verification, and evidence limits that the first build must address. A team that can demonstrate those behaviors has something the buyer can assess before extending the design across other decisions, and the unresolved cases become explicit work rather than a broad promise of auditability.

Sources and further reading

The primary references below support the terminology for traces and provenance, structured output limits, and workflow persistence. The supplier case, review rules, retention comparisons, and acceptance demonstration are our proposed workflow design, not requirements prescribed by those references or claims of certification.

• OpenAI: Structured Outputs: output schemas and remaining content errors.
• LangGraph: Persistence: saved workflow state and recovery.
• OpenTelemetry: Traces: spans, attributes, events, and links used to describe execution.
• W3C PROV Model Primer: entities, activities, responsible agents, and derivation between versions.
• How to scope AI agent permissions: approval, expected state, and execution authority.
• Why AI agents report unfinished work as done: confirmation and incomplete outcomes.
• Why RAG systems fail in production: source quality, retrieval, and evidence access.
• How to build LLM evals: failure analysis and acceptance checks.