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.
bounded mapping
- 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.
- 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
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.