Engineering note
We replayed 12 days of a batch estate and diffed every decision.
The scariest sentence in a modernization program is "trust us, it does the same thing." Nobody should trust that sentence, least of all a bank. So we built the alternative: import the estate, replay a window of its own recorded history through the replacement runtime, and diff what the runtime would have done against what actually happened — job by job, day by day, with the disagreement categories named.
The setup
The estate under test is a 17-job AutoSys wire-processing chain — the
shape every payments floor runs: feed ingest, validation, duplicate
screening, a fan-out into positions and cash projection, an AND-join
into automated reconciliation, a human breaks-review, a duty-manager
release approval, dispatch, GL posting, regulatory reporting, archive,
plus an independent housekeeping chain. Three of those jobs are
human gates. The JIL carries everything a real export carries —
owner, machine, alarm_if_fail,
quoted descriptions, comment blocks.
The history is an autorep-flavoured CSV: twelve business
days, SU/FA statuses, start and end times, one
rerun (duplicate row, last wins), and one genuinely bad night — the
automated recon failed on day seven, and everything downstream
of it correctly never ran.
What the proof checks
The estate is converted into an event-sourced engine graph (gateways
synthesized at fan-outs and joins, every job given an error route to a
terminal held node, so failure containment is structural).
Then each day is replayed: history's successes return, history's
failures raise — exactly once, because a historical failure is a
fact, not a flake; retrying it would rewrite the past. Human
gates auto-approve and are recorded. The diff then has five ways to
disagree:
- Missing — history ran a job the engine never reached: the model is too loose.
- Unexpected — the engine would run a job history shows idle: a hold you did not model, or a model too eager.
- Status mismatch — history and engine disagree on how a job ended.
- Containment break — history shows a job running downstream of a same-day failure: a force-start, or a wrong dependency.
- Order finding — history's timestamps violate a modeled dependency: the model is simply wrong, and the proof says so.
Any category non-empty on any day and the verdict is DIVERGED. All empty, every day: PASS. The per-day engine event logs ship inside the bundle, so every comparison is reproducible from the evidence alone.
The result — and the deliberate failure
The clean window: twelve days, PROOF PASS — including the failure night, because containment held and the engine agreed with reality about what should never have run.
Then we lied to it. One appended row claiming a downstream job ran on the night its upstream failed: the verdict flips to DIVERGED, naming the job, on the right day, in the right category. Our test suite makes this falsifiability mandatory — seeded corruptions that fail to flip the verdict fail the build. A proof that cannot fail is not a proof; it is a false statement everyone trusts.
Why this matters for modernization
Estates like this are held in place by fear, not by feature lists. The operators who wrote the job definitions retired; the dependency graph lives in tribal memory; and so every migration plan dies at "how do we know it behaves the same at 2 a.m.?" A replay proof answers that question before cutover, from records you already keep, in an afternoon — and hands your risk team an artifact instead of an assurance.
Run it yourself: the scanner is free and runs air-gapped
(handeware-scan --demo to see it on a synthetic estate, then
point it at your own exports). When it finds your batch chains,
handeware-prove takes the estate plus your history export
and returns the verdict. Or start with the
fixed-price pilot and we will run the
first proof with you.