Deterministic-first: when a machine should be certain
There is a quiet assumption in a lot of AI work that the model should do everything. Feed the raw input to a large language model, ask nicely, and let it sort out the rest. It is a seductive idea, because it collapses a hard engineering problem into a prompt. It is also, most of the time, the wrong place to start.
We build the other way around. We reach for deterministic code first, and we bring a model in only where the problem is genuinely ambiguous. The result is software that is mostly predictable, cheaper to run, and far easier to trust.
Deterministic where the answer is knowable
A great deal of what looks like an AI problem is not one. If a document arrives in a format you have seen before, you do not need a model to guess at its meaning. You need code that reads it, validates it, and fails loudly when something is off. The answer is knowable, so a machine should be certain about it.
Jurana, our legal automation platform, is built on this principle. When it ingests a ledger or a statement in a known format, it reads that format deterministically. Same input, same output, every time, with no probability attached. Only when it meets something it does not recognise does it fall back to an AI model to interpret it. The model is the exception, not the engine.
This matters because deterministic code can be tested, reasoned about and audited. When a client asks why the system produced a particular number, we can point to the exact rule that produced it. That is a very different conversation from a shrug and the words the model decided.
AI where the problem is genuinely ambiguous
None of this is an argument against AI. It is an argument for putting it where it earns its place. Some problems really are ambiguous: free text with no fixed shape, images that vary in ways you cannot enumerate, intent that has to be inferred rather than parsed. That is where a model does something no amount of hand written rules can, and that is where we use one without hesitation.
The skill is in drawing the line. Ask a model to do work that a parser could do perfectly, and you have taken something certain and made it probabilistic. Ask deterministic code to handle true ambiguity, and you get a brittle tangle of special cases that breaks on the first input nobody predicted. Good systems put each tool on the right side of that line.
Boring on purpose
Software built this way tends to look unexciting from the outside, and we take that as a compliment. Most of it is mostly boring and completely dependable, with intelligence concentrated exactly where ambiguity lives. That is the point. The certainty is deliberate, and so is the intelligence.
