Enterprise / Products / Prove
Handeware Prove · handeware-prove
Replay your own history. Get a verdict, not an assurance.
Every modernization program dies at the same sentence: "how do we know it behaves the same at 2 a.m.?" Prove answers it from records you already keep. Point it at a scheduler estate and a run-history export; it replays each day through the Handeware Engine and reports, job by job, whether the replacement would have made the same decisions — before anything is cut over.
- Input
- Estate export + history CSV
- Output
- proof.html · proof.json · event logs
- Runtime
- Offline, in your boundary
- Exit codes
- 0 PASS · 2 DIVERGED · 1 error
What a proof actually checks
The estate becomes an event-sourced graph — gateways synthesized at
fan-outs and joins, every job given an error route to a terminal
held node so failure containment is structural rather than
conventional. Then each day is replayed against its recorded facts.
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.
| Finding | What it means when it fires | Who should care |
|---|---|---|
| Missing | History ran a job the engine never reached. The model is too loose — a dependency you have is not a dependency we modeled. | Migration lead |
| Unexpected | The engine would run a job history shows idle. A hold, a calendar, or a condition nobody wrote down. | Operations |
| Status mismatch | History and engine disagree about how a job ended. | Migration lead |
| Containment break | History shows a job running downstream of a same-day failure. Either somebody force-started it at 3 a.m., or the dependency is wrong. Both are worth knowing before cutover. | Risk · Operations |
| Order finding | History's timestamps violate a modeled dependency. The model is simply wrong, and the proof says so rather than passing quietly. | Migration lead |
| Coverage gap | History contains a job the model does not know about. A proof over a partial model is not a pass, and we refuse to call it one. | Everyone |
Any category non-empty on any day and the verdict is DIVERGED. All empty, every day: PASS.
One command
handeware-prove ./estate/wire_eod.jil \
--history ./exports/autorep_march.csv \
--out ./wire-eod-proof
History CSVs come as they come. Headers are matched with spaces and
underscores squashed, so JobName, job_name and
Job Name all resolve; RunDate,
LastStart and LastEnd are understood;
statuses map from AutoSys SU/FA, Control-M
Ended OK/Not OK, and generic exit-style values.
Anything genuinely ambiguous is refused loudly with its line number
rather than guessed at — evidence tooling does not get to improvise.
A proof refuses to write over an existing bundle. Evidence does not get rewritten in place, and a re-proof lands in a fresh directory — so the trail of what you knew, and when, survives.
The proof can fail — that is the point
A proof harness that cannot fail is a false statement everyone trusts. Ours is falsifiable by design and by test: seeded corruptions — a dropped dependency edge, a flipped status, a job that "ran" downstream of a failure, timestamps that violate an ordering — must flip the verdict to DIVERGED with the correct category populated, and the untouched baseline must still pass. If a mutation fails to flip the verdict, our build goes red.
Twelve days of a 17-job wire chain, including a contained-failure night. PROOF PASS.
Read the passing proof →The same estate with one seeded lie appended. PROOF DIVERGED, naming the job.
Read the diverging proof →What it does not claim
- It is not a migration. A proof tells you whether a modeled replacement matches recorded reality. Moving production is a separate, deliberate act — one you take with the proof in hand.
- It cannot see what history did not record. If your export omits a job, the proof reports a coverage gap and refuses to pass. Better a loud gap than a quiet assumption.
- It does not replace your change process. It gives that process an artifact instead of an opinion.
Start
Run the Scanner on your estate first — it finds the batch chains and tells you which are provable.
Handeware Scanner →We run the first proof with you on a bounded slice of the estate, and hand over the bundle and a migration plan.
The pilot →