Handeware Enterprise

Engineering note

We replayed 12 days of a batch estate and diffed every decision.

Handeware engineering · August 2026 · artifacts linked are real output, synthetic data

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.