Why Zero Drift exists
AI builds.
Defined rules decide.
Models can explore, design and write software at extraordinary speed. But a tax calculation, a customer balance, a permission check or a safeguarding rule cannot be probably correct. We use probabilistic tools to build deterministic systems.
An invoice is not a guessing game.
Suppose an invoice records a quantity of three and a unit price of £40. A model can help extract those candidates from a messy document and flag a missing field. The defined rule—quantity × unit price—computes a £120 subtotal. The system records the source fields, rule version and computed answer; VAT and payment authority follow their own explicit rules. Ask the model to propose. Do not ask it to become the calculator or the ledger.
Reproducible is necessary. It is not sufficient.
Deterministic means that the same inputs, rule version and relevant state produce the same result. A wrong formula can be perfectly deterministic. Dependable software also needs an authoritative rule, valid inputs, tests that challenge the implementation and a person responsible for deciding what the rule should be.
A payroll example makes the distinction clear: AI can help an engineer understand a rule and draft the code. The running product applies the agreed calculation to recorded inputs. If the rule changes, the version changes and the evidence should show which version produced each result.
The era test
Can this be a good guess, or must it be exactly right?
That question decides where inference belongs. Uncertainty can be valuable when the job is exploration, drafting or explanation. It is unacceptable when the result creates an obligation.
A good answer moves the work forward.
- Draft an explanation for a person to review
- Surface patterns worth investigating
- Generate and compare implementation options
- Summarise evidence without becoming the evidence
The same input must follow the agreed rule.
- Calculate tax, payroll or a customer balance
- Enforce who may see or change a record
- Apply a statutory deadline or eligibility rule
- Retain, suppress or disclose safeguarding data
What changed
Code became cheap. Judgement and proof became more valuable.
The old constraint was the time and coordination needed to write software. AI changes that cost boundary: a small, experienced team can explore more approaches and produce more implementation work. The commercial consequence is not a universal speed claim. It is the opportunity to test whether a complete system can be delivered with less coordination, less repeated labour and a lower operating burden.
That speed does not remove the need for architecture, a complete specification or testing. It makes them the governing assets. Under-specify the work and the model fills the gap with the statistically likely answer. Skip the checks and a plausible mistake becomes production software faster than ever.
This is not an argument for less AI. It is an argument for using AI where it is strongest, surrounded by a system that knows the difference between persuasive and correct.
Measured in working software
Two server implementations. No differences across 2,510 observations.
Ember’s comparison recorded 2,510 observations across the old and replacement servers with zero differences inside the measured boundary. It is evidence of parity for those observations, not proof of every possible behaviour or that the original behaviour was correct. The useful receipt names what was exercised, how it was compared and what happened.
See how the replacement was controlled →The deterministic gap
The future is not AI everywhere.
It is inference wherever a good answer is useful, and deterministic software wherever being wrong has consequences. AI builds the system. The specification fixes the obligation. The checks decide when the work is finished.
That gap is where Zero Drift works.