Replay and approve

Check the fix before anyone ships it

The shapes in approved evidence become an immutable replay dataset with representative values. Repair candidates run inside resource limits with no network. Deterministic comparison decides whether the candidate passed. You decide whether it goes anywhere.

proposed repairapproved
low risk · 24

bounded mapping

$.candidate_email$.email_address
incident
3 candidate outcomes missing · 1 tenant
dataset
rds_seed_candidate_missing · 3 immutable fixtures
isolation
child process · network denied · 64 MB · 5 s
source
deterministic · no AI provider used

before repair

failed

0/ 3 fixtures

proposed repair

passed

3/ 3 fixtures

deterministic checks · 8 of 8 passed

  • Supported proposal format
  • Bounded operation count
  • Supported operations only
  • Safe field paths
  • Distinct source and target fields
  • Linked to incident evidence
  • Operations justified by cited evidence
  • Within approval risk policy

Approved by Demo Owner · workspace owner · 17 Aug 2026

sha256:9f2c…c41d

Replay fixtures and schema checks support this bounded mapping.

replay datasetrds_seed_candidate_missing
immutable
fixtures
3 · redacted with pol_seed_1
isolation
child process · network denied
limits
64 MB memory · 5 s wall clock
comparator
deterministic · transport and business outcome

current mapping

failed

0/ 3 fixtures

candidate-email-fix

passed

3/ 3 fixtures

fixturebeforeafter
fixture_candidate_accepted_1failpass
fixture_candidate_accepted_2failpass
fixture_candidate_accepted_3failpass

The replay boundary

  • Immutable fixture sets generated from observed shapes or value profiles
  • Isolated child process, network denied, 64 MB, 5 seconds
  • Deterministic comparators, identical input gives identical result
  • Your own handler on the same fixtures, run by you through the CLI and shown as reported by your runner
  • Two routes to a fix: a built-in mapping for simple field changes, or your own change from your repository or coding agent, checked by your runner

The approval boundary

  • Evidence-linked proposal with assumptions stated
  • Recorded approval with rationale
  • GitHub issue or draft pull request, created only after approval
  • No deploy. No merge. No change to customer code.

Runs outside your request path. Fails open. Stores structure, never raw payloads.

Bring us the integration failure you need to prove

Seamward is onboarding teams with real third-party reliability problems. Start with one integration.