Deterministic-first AI automation: let rules do the work, let AI explain it
Every few weeks someone shows us an AI tool that "fully automates" a compliance workflow. The demonstrations are usually impressive, and the question we ask of each one is the same: when the tool is wrong, how does anyone find out before the penalty notice arrives?
This post explains the architecture we use instead, which we call deterministic-first automation, and why we believe it is the only honest way to put AI into workflows where mistakes cost money.
The core idea
We split every workflow into two kinds of steps.
- Steps with a right answer. Does invoice line 14 match the register entry? Is this ITC claim within the permitted window? These are matters of arithmetic and rules. Explicit code can decide them with certainty and show its working, so we do not let a language model decide them.
- Steps that need language and judgement. Explaining a mismatch to a client, drafting a reply to a notice, summarising what changed since last month. This is where modern AI earns its place, provided a person reviews the draft before it is sent.
Deterministic-first means the rules engine is the system of record and the AI layer is an interpreter sitting on top of it. The model never invents a number: it explains the numbers the rules produced, and every sentence it drafts links back to the data that supports it.
The architecture in one picture: numbers from rules, language from AI, judgement from people.
What this looks like in practice
In our GST reconciliation work, matching GSTR-2B against a purchase register is pure rules: normalisation, tolerance windows, and categorised mismatch types. The output of that stage is a table any auditor could recompute.
Only then does AI enter, turning "mismatch category 3, vendor GSTIN suspended in period" into a paragraph a client understands, or drafting the skeleton of a reply to an ASMT-10, with citations into the reconciliation table and a reviewer's sign-off required before anything is sent.
Why not end-to-end AI?
Three reasons.
- Confidence is not correctness. Models present wrong answers with the same fluency as right ones, and in a filing workflow a fluent wrong answer is the most expensive kind.
- An audit needs a trace. When a regulator asks why a figure was claimed, "the model said so" is not an answer. A rules trace is.
- Errors should be boring. Deterministic systems fail loudly and reproducibly, so a broken rule is fixed once. Model errors are stochastic, and the same input can fail differently tomorrow.
The test we apply
Before any automation ships, we ask one question: if this system's worst single mistake this year lands on a partner's desk, can they defend it in one sitting with what the system logged? If the answer is no, the architecture is wrong, no matter how good the demo looks.
That is the standard we build to. There is more on how we apply it in our custom AI automation engagements, and if it matches what you need, write to us at hello@lambdac.dev.