The Verdict Engine
An independent judge for modernization. It runs the old system and the new one on the same inputs, compares every field, and signs a verdict your auditor can replay. It is a fixed program, tested before use. It is not an AI model.
It compares the two systems field by field
Every record, every field, aligned by key and judged against your equivalence policy. A one-cent difference halts the run and names the field that caused it.
The verdict names the field and the cause, not just pass or fail.
Three verdicts, not two
Every comparison tool returns pass or fail. That is the problem. A tool with only two answers has to pick one even when it has verified nothing — and it will pick pass, because nothing went wrong.
| Verdict | What it means | Exit |
|---|---|---|
| equivalent | Both systems produced the same result, within the policy you approved. | 0 |
| divergent | They differ. The receipt names the field and the cause. | 1 |
| indeterminate | We could not verify this, and we will not pretend otherwise. Nothing comparable was produced, or the construct is outside what we can decide. | 2 |
The third verdict is the one no other tool returns, and it is the reason the first two can be trusted. An engine that never says indeterminate is not more capable. It is less honest.
The dangerous answer is not a wrong one. It is a confident empty one.
A tool that reports success having checked nothing looks exactly like a tool that works. It ships, and you find out when the numbers stop reconciling. We attack our own Verdict Engine on every build to make sure it cannot do that.
| Injected defect | What a naive comparison tool does | Ours |
|---|---|---|
| Candidate writes nothing | reports passed, exit 0 | indeterminate |
| Transaction posted twice | key collapses, reports passed | failed |
| Balance drifts one cent | within float tolerance | failed |
| Fixed-point money becomes floating point | passes until it compounds | failed |
| Timestamps written blank | field is ignored anyway | failed |
| Statement rows reordered | set comparison passes | failed |
Each row is a defect we deliberately introduced into our own code to check the alarm sounds. A test that cannot fail is not evidence, so every safeguard is verified by breaking the thing it protects.
Replace subjective testing with evidence a committee can read
The verification engine runs unattended across your estate. It refuses to certify a release until it can show the replacement behaves the same — and where it cannot show that, it says so rather than passing.
Runs without supervision
Millions of transactions checked automatically, removing the bottleneck of engineers comparing outputs by hand.
Deterministic halts
If the target diverges from the legacy baseline by a single cent, the run halts and names the exact field and rule.
A record that holds up
Every check leaves a permanent record your auditors can re-run months later. Sign-off becomes a review, not a leap of faith.
It does the safe work itself. It stops before anything else.
Every verdict produces work with a named owner. Six kinds of work run unattended, because none of them can turn a difference into an acceptance: re-run the comparison, escalate to a deeper lane, extend the corpus, re-parse with a wider grammar, widen observation, and apply a normalization your team already approved.
Proposing a new normalization, classifying a change as intentional, promoting a claim — these stop and ask. Not by convention. A configuration that would let them run unattended is rejected by the software. Authority can be reduced. It cannot be increased.
- name: Verify behaviour against the legacy system
run: lightyear verify --estate core-banking --policy ci.json
round 1 412 resolved rerun, escalate-lane, widen-observation
round 2 106 resolved reparse, extend-corpus, apply-ledger-entry
halted human-decision-required
96 awaiting your decision queued to named owners
27 blocked on access authorised baseline required
542 blocked on our backlog our parser, not your system
exit 2
Exit 0 lets the release proceed. Exit 1 halts it on a divergence. Exit 2 halts it because something could not be verified — the exit code most tools do not have.
Wire it in once and verification stops being a phase you schedule. It becomes a property of the pipeline, like your build or your tests: every change is measured against the system it replaces, the evidence accumulates commit by commit, and the release either carries proof or it does not ship.
Sign-off stops being an event at the end
Today a modernization programme verifies at milestones. Someone runs a comparison, writes a report, and a committee reads it weeks later — by which point the code has moved on and the evidence describes a system that no longer exists.
In a pipeline, every commit carries its own evidence. Sign-off becomes an accumulated record rather than a meeting, and the question at go-live changes from “can someone check this?” to “read what we already have.”
We run it on ourselves this way. Every push to our own repository runs the engine in GitHub Actions — the same command, the same exit codes, on public code you can read. It is one step in a workflow file, not an integration project.
Three ways to run it, and no difference between them. An engineer at a terminal, a step in the build you already have, or the AI assistant your team is already using to write the replacement. Same engine, same limits, same refusals — there is no assistant mode with looser rules.
| Read what the project covers and its limits | Approve a difference as acceptable |
| Start a run it has reviewed | Start a plan it has not read |
| Follow progress and read the record | Change scope, policy or budget |
| Produce a signed evidence bundle | Turn an unverified result into a pass |
Deciding a difference is acceptable is a judgement about your business. A named person in your organisation makes it, sees how many comparisons it silences, and signs it with an expiry date.
Once it starts, it does not need watching. Closing a laptop does not cancel work, and a retry with the same request identifier returns the same run rather than starting a second one — so a dropped connection never costs you a duplicate database run.
Any system in. Proof out.
The judge, the verdicts, the rules and the signed evidence are the same for every technology. What changes is how we run each system and observe what it did. We call that a lane, and we qualify every pair of lanes before we sell it: known-good references must pass, deliberately broken conversions must be caught, and anyone must be able to replay the evidence.
Verdict core
The qualified judge, three verdicts, hidden expected results, owned rules, signing and offline replay.
Lanes
Run the original and the replacement on real infrastructure and capture rows, files, messages and transactions in one canonical form.
Qualification
A signed record for each source and target pair: controls passed, faults caught, the error bound, and the limits in plain words.
What our judge is qualified on today
| Source → target | Status | Evidence | Limits |
|---|---|---|---|
| Oracle → PostgreSQL | Qualified · limited | Reference 10/10 · 39/39 deliberate faults caught · 62/62 runs replayed offline · 260 datatype behaviours | One ERP operations and purchasing journey family; review is in-house |
| Oracle → AlloyDB | Qualified · limited | 260 datatype behaviours compared on Oracle and AlloyDB | Datatype behaviour only; no application journey yet |
| z/OS batch (COBOL, JCL) → Java | In qualification | Read-only collection appliance and adapters; live z/OS runs with our capacity partner next | Not yet qualified on live mainframe execution |
| SAP ASE (Sybase) → PostgreSQL | In qualification | 54 ASE behaviours and 187 conformance cases declared; live lane next | Declared behaviour, not yet observed on a live server |
| Db2 → PostgreSQL | In qualification | Semantic adapter with conformance receipt | Schema and data level; no live journey yet |
| CICS → Java services | Roadmap | — | — |
| SQL Server → PostgreSQL | Roadmap | — | — |
A qualification expires when the platform's major version, our lane or our judge changes, and is listed again only once requalified.
Read and map, today, across the whole estate
Before any comparison runs, our source-only analysis inventories and maps the estate offline, without changing a file.
The agents write the code. We tell you whether it's right.
Whoever does the conversion, your team, a systems integrator, or any AI coding agent, the judge stays the same and the evidence stays yours. Better models produce more code, faster. The question of whether it still behaves the same only gets bigger.
New lanes are qualified as milestones, with published evidence. Tell us your source and target and we'll show you the qualification plan.
Talk to usSee it on one of your processes
A Verification Sprint takes four weeks, from $50,000, and ends with a signed verdict.