Start with one process. Know the price before you start.
Every engagement starts with a Verification Sprint: a fixed fee, a fixed scope and a signed result. What happens after that is your decision, made on evidence.
What you get, and what we need from you
What we need from you
- Read-only access to the source for the process in scope
- Its inputs and outputs, or a way to run it on test data
- The replacement, if you have one. If you don't, our factory builds one during the sprint
- One person who decides what "the same" means for your business, such as rounding or timestamps
How the four weeks run
- Week 1. Agree the scope and the definition of "the same". Connect read-only.
- Week 2. Run the original and capture what it does.
- Week 3. Run the replacement on the same inputs and compare every field.
- Week 4. Deliver the signed evidence pack, the risk number and a plain-language readout.
Verification Sprint
- One batch job or business process, verified against the system it replaces: a replacement you already have, or one our factory builds during the sprint
- Every difference named, field by field, with its cause
- Your risk number: how much of that process's logic no test you own has ever exercised
- A signed evidence pack your auditor can replay offline
- Read-only, inside your cloud, from day one
Quantify true risk before you choose a vendor
Before signing a multi-year contract with a systems integrator, point Lightyear at your estate. In four weeks we report how much of your core business logic has never been exercised by any test you own.
That single number reshapes scope, budget and vendor negotiation. You cannot safely modernize what you have never measured.
paths in scope
you already own
present in the code
ever exercised
Captured production traffic covers the happy path. Undocumented rejection and error paths are where modernization defects survive to go-live. Your own figures replace these at the end of week four.
Verification Sprint
- One batch job or business process, verified field by field
- Your risk number for that process
- A signed evidence pack your auditor can replay
System modernization
- Everything above, running inside your own environment
- Continuous side-by-side comparison, with every accepted difference signed off by a named owner
- Scored against tests the AI is never allowed to see
- Full cutover rehearsal, including the rollback
- One of our engineers sitting with your team
Estate transformation
- Many parts of the estate moving at once, safely
- One screen showing what is proven and what is not, live
- An audit trail your regulator can replay, years later
- Your systems integrator works inside the same proof
Most programmes start with the person who owns the modernization, or the one who owns the risk. What we install stays after the programme ends — so the thing that proved the migration keeps watching the system for years afterwards.
Inside your cloud, reading only
Both systems stay exactly where they are. We watch each one, compare them, and leave a record. Nothing is ever written back to your estate.
The Verdict Engine is the only component that sees both sides.
Frequently asked
Do you compete with code-generation platforms?
No. We sit underneath them. Generation is collapsing in price and will keep collapsing — a better model should change your throughput, not your confidence. We are the layer that decides whether generated change is safe to switch on, and we are deliberately agnostic about who wrote it. Several of our engagements verify a candidate produced by someone else's platform.
What do you need from us to start?
Read-only access to source and, for the assessment, enough captured input and output from the running system to be representative. We will tell you if it is not representative — that finding is usually the most valuable output of the first month.
Why does the product refuse to claim equivalence?
Because equivalence is a claim we make only from live evidence, and the authorised z/OS baseline is the piece still to come. The gate is enforced in code, so the moment you supply that baseline the claim unlocks. Until then the product shows you exactly where it stands.
How is this different from a golden-master test suite?
A golden master compares against outputs someone chose to capture. We measure which decision paths that capture actually reaches, then manufacture the inputs to close the gaps — usually rejection and error paths, which barely appear in production traffic and are where modernization defects survive to go-live.
Does the comparison report contain sensitive data?
Yes, by design. The expected and actual values are the evidence, and masking them would destroy the artifact. Classification, access control and retention on run directories are agreed with your security team before the first capture. This is a conversation we start early rather than discover in procurement.
What happens to the harness after the programme ends?
It stays. A modernization is a project; behavioural regression is permanent. Most customers keep the harness running against the estate long after the migration, which is when it stops being a cost line and starts being infrastructure.
Start with the number nobody has given you
Four weeks. One process. One number that changes how you plan everything after it: how much of what your system actually does has ever been tested.