Replay

Replay answers "would this repair actually have fixed the traffic that failed?" with a deterministic pass or fail, before the proposal reaches review. It exists because a fluent explanation and a clean code review cannot establish that a change preserves the expected output on the historical shapes that produced the incident. Replay is shown inside the incident's Repair tab so the proposal and the evidence validating it stay together.

Fixtures without customer data

A replay dataset is built automatically from approved incident evidence when a repair proposal is requested. It inherits the privacy posture of the evidence: observations contain structure, not values, so fixtures are materialized with representative values generated from the structural shapes. A string field gets a representative string, a number field a representative number; no customer value exists to leak.

The dataset is immutable and self-describing: it records its incident, integration, redaction policy, evidence count, and a hashed manifest. Immutability matters because the fixture is created before a candidate is evaluated, so the expected result cannot drift to match whatever the model produced.

Isolated execution

• Supported operations run in a separate JavaScript interpreter with resource limits and no network access. The adapter receives only synthetic JSON and has no host filesystem, process, or module capabilities. Each fixture starts with a fresh interpreter.
• Only the bounded transformation vocabulary runs (the same one repair proposals are limited to); arbitrary application code is outside the replay contract by design.
• The supported transformation vocabulary produces comparable results for the same dataset and adapter version. Every requested fixture must return a validated outcome or an explicit error.

Results you can review

Every fixture produces a pass or fail with stable mismatch paths, so a failure reads like $.candidate.salary: expected string, produced number, not "validation failed". Checks cover status ranges, acceptance, business object type, transformed output, and named assertions. The Repair tab compares the current implementation with the proposed repair, then keeps detailed run history and fixture provenance in a disclosure. The full run result is preserved next to the approval decision it informed.

Interrupted validation

A worker interruption does not authorize a repair. Execution uses expiring claims so a later attempt can resume safely and an older attempt cannot overwrite its result. A repair resumes its saved candidate and replay, with at most three execution attempts. An unrecoverable legacy run ends with an explicit error. Review the incident evidence and request a new proposal if recovery is exhausted.

Boundaries

The legacy custom-source replay endpoint has been retired. Requests to it return 410 with custom_replay_retired after authorization. Request a repair proposal from the incident's Repair tab to validate a supported transformation. Existing run evidence remains readable. Custom application-code execution is not a public API.

• A passing replay does not merge, deploy, or promise your full test suite passes; it establishes one specific claim about historical evidence.
• A failing or unsafe candidate stays unavailable for approval; there is no override.
• Your repository's CI, review, and release process remain the authority on shipping.

During a release rollback, interrupted attempts receive the terminal error execution_interrupted_by_rollback before older workers start. Completed validation reports remain available. After service recovery, request a new proposal if you need another validation.

Evidence capacity

Dataset creation and repair generation use all currently missing evidence links. At more than 1,000 fixtures, the request returns 409 with replay_evidence_capacity_exceeded, limit: 1000 and the current total. It does not silently replay a sample or create a partial repair. Inspect the full incident evidence and its recovery status. A successful subsequent reconciliation can reduce the current set; do not discard observations to bypass the limit. Legacy incidents without a maintained evidence snapshot use their recorded timeline and the same fixture limit.

An explicitly selected dataset whose observation IDs no longer match the complete current evidence returns 409 replay_evidence_snapshot_changed. Create a fresh dataset or start proposal generation without selecting the stale dataset. Automatic preparation rebuilds an immutable dataset when the current evidence changes.

Next steps

• Validate repairs before delivery: the workflow around replay.
• Repair proposals: what gets validated.