Behavior replay for AI decisions: reconstruct what happened, don't just rerun it

The request was the same. Everything else was new.

A commercial lender is asked why its application sent a customer's credit request to specialist review ninety days ago. The customer says the same request is now approved automatically.

The incident team pulls the original payload and trace ID. An internal console has a button labeled Replay. They press it. The case runs through today's application and comes back auto-approve. Same customer, same limit, same financial statements, different answer. The team logs it as model inconsistency.

But the two runs weren't the same application. The original ran on workflow version 12, policy bundle 31, a 180-day feature lookback, model version 4, mapping version 9, a specific retrieval snapshot and the customer record as it was then. The new run used version 15, policy 36, a 90-day lookback, model version 7, current mappings, a rebuilt index and a corrected customer record.

The rerun is still useful. It shows what today's application would do with an old request. It doesn't show what the old application knew, was allowed to do, or actually did.

What does "replay" actually mean for an AI system?

Replay is several different operations sharing one word. Each answers a different question and carries a different risk of creating real-world effects, so each needs its own name and controls.

Labeling all six "replay" invites mistakes. An investigator takes a rerun as evidence. An operator takes a redelivery for a safe retry (see retries and idempotency). A developer takes log playback for reconstruction. A live action inherits an approval that no longer applies.

Four replay modes, declared up front

One screen can offer all four modes. The runtime shouldn't treat them as interchangeable.

What must you keep to replay an AI decision?

Enough to rebuild the case at a declared level of faithfulness: the version and its resolved dependencies, inputs and context, state and timing, authority and policy decisions, approvals, and confirmed outcomes.

Think of it as a case record, a logical package rather than one physical archive. Some parts are protected snapshots. Others stay in their systems of record, referenced by stable ID, version and digest.

• Definition: the published workflow version, contracts and mappings.
• Dependencies: the model, prompt, schema, policy, feature, index and sub-workflow versions that actually resolved (see versioning AI workflows).
• Inputs and context: original inputs, record revisions, the evidence that was eligible and what was selected.
• Authority and policy: who acted for whom, scope, policy decisions and obligations, approval state.
• State and time: durable state, waits, events and their order, effective times, expiries, migrations.
• Decisions: each decision, overrides and what finally authorized the change.
• Effects: operation IDs, attempts, receipts from the system of record, reconciliation and final state.

The record should carry enough meaning to rebuild the case without becoming an uncontrolled copy of every sensitive document, prompt and credential. References, digests, versioned contracts and selective snapshots give stronger accountability with less duplicated data. A trace ID helps join technical calls, but it isn't the same thing as the identities of proposals, decisions and approvals. An audit trail built for evidence is what makes this possible.

Faithfulness has several dimensions

Replay isn't simply faithful or unfaithful. Each dimension can be recovered to a different degree.

Exact reproduction won't always be possible. A provider's model may be gone. A probabilistic model may not return the same tokens. An external system may not answer historical queries. Report those gaps instead of quietly substituting current conditions and calling it reproduction.

Time and randomness need explicit handling

Behavior can change just because the clock moved. Policies depend on age, expiry, business days, exchange rates, regulatory effective dates and time since approval. Reconstruction needs a time model that separates when something happened, when the system received it, when a step ran, which business date the rules used, and when the replay itself is running.

Probabilistic steps add another limit. Capture seeds, model artifacts, runtime versions and provider details where they matter and are available. Even then, the same tokens aren't guaranteed. The original model output stays the historical record. A new model call is a behavioral comparison, not proof of what happened inside the model the first time.

How do you stop replay from touching production?

Put replay behind a hard boundary with no live credentials or write paths by default. Each consequential call returns its recorded result, a stub, a sandbox response, a dry run or a denial.

The boundary has to cover more than payments and account changes. It also covers email, webhooks, notifications, disclosures, support tickets, document publishing, analytics writes, cache updates, model feedback and external searches that leave a trace or carry legal weight. An investigation should never become another business action.

What-if runs are change-impact tools, not verdicts

A what-if run replays a past case against a proposed change, with no side effects. It answers practical questions. Would the new prompt change the classification? Would the new policy change escalation? Would the new mapping change the proposal? Would a new context rule pick different evidence? Would a new route cut cost without changing outcomes?

Record a structured comparison of path, context, decisions, policy, approvals, cost and evidence. A different result may come from the model, but it may equally come from new context rules, a changed mapping, a policy obligation, a revised record or a new review rule. Don't blame the model just because it's the most visible part. And a what-if result isn't proof that the original outcome was wrong.

Live re-execution needs today's authority

A past approval, policy decision or workload credential doesn't authorize a new live effect. Before any re-execution, re-establish who is acting and for whom; evaluate current policy, scope and residency; check the current state of the record and what has changed; decide whether the original approval still applies to an unchanged proposal; and reconcile any uncertain earlier attempt.

If the goal is to finish an uncertain earlier action, keep the same operation ID after reconciliation. If the business is deliberately authorizing a new action, give it a new operation ID and new authorization. History informs the decision. It isn't a standing permission.

Human decisions can't be replayed by pretending

Reconstruction keeps the original review package, the reviewer's authority, decision, conditions and expiry. It doesn't claim to reproduce the reviewer's private reasoning. A simulation has to choose openly: hold the human decision fixed, route to a new review in the sandbox, use a declared policy proxy labeled as such, or compare whether the new version would need a different reviewer or threshold. Otherwise a simulation borrows a person's approval for a proposition they never saw.

Replay must respect permissions

A case record often holds more sensitive material than the original answer: retrieved documents, model inputs, policy facts, identity attributes, tool payloads and diagnostics. Replay access needs the same rules as production: who sees which fields, which tenant and purpose rules apply, whether raw content, redacted content or just integrity proofs are shown, whether a what-if run may use the same data locations, and how replay artifacts are kept and deleted. Keep the minimum evidence needed for the replay you've committed to support, not everything forever.

Common anti-patterns

Ten rules for behavior replay

1. Treat inspection, reconstruction, what-if, redelivery, retry and re-execution as different operations.
2. Declare the mode, faithfulness, side-effect posture and known gaps for every replay.
3. Keep a case record with the version, resolved dependencies, context, state, decisions, authority and effects.
4. Use historical time, state and record revisions explicitly.
5. Treat new model calls as comparisons unless exact conditions are available and declared.
6. Default every write to a recorded result, stub, sandbox or denial.
7. Record a structured comparison for every what-if run.
8. Require a current-state check before any live action.
9. Apply tenant, privacy, residency and retention rules to replay evidence.
10. Design replay coverage in before deployment, not after an incident.

The result: understanding before effect

Replay isn't valuable because it makes every past decision perfectly reproducible. It's valuable because it forces you to name what must stay stable, what can be rebuilt, what must be simulated, what's gone for good, and what must never repeat without today's authorization.

Done that way, replay supports incident investigation, audit, model and policy change analysis, release testing and controlled recovery, without confusing historical evidence with current permission. Replay should reproduce understanding long before it's ever allowed to reproduce an effect.