What we do
We build systems where a model does the reading, the extraction and the drafting, and a deterministic layer decides whether the result is allowed to proceed. Codes are checked against the actual code set rather than recalled. Totals are computed, not generated. Required fields are enforced by the schema. Anything the rules cannot clear goes to a person with the reason attached, rather than going out and failing later.
The result is a workflow that moves at machine speed on the ordinary cases and stops hard on the ones that matter, which is the opposite of what happens when a model is left to decide for itself.
Where this pattern earns its keep
Healthcare claims and insurance filings, where a rejected submission costs weeks and a wrong one costs more than that. Tax and statutory returns, where the arithmetic has to be arithmetic. Pre-sales and bid responses, where the answer has to match what the organisation has actually committed to elsewhere. Regulatory submissions, where the format is as binding as the content.
The common shape is the same every time: high volume, low tolerance, and an external party who will reject the work if it is wrong.
Why we do it this way
A model asked to fill a form will fill it. It will produce a plausible code, a plausible total and a plausible justification, and nothing in the output tells you which parts it knew and which it inferred. In a workflow that gets audited, that distinction is the whole thing.
So we draw the line explicitly and write it down. Every field in the output carries where it came from, which rule cleared it and what a reviewer would need to check. When somebody asks six months later why a submission looked like that, the answer is in the record rather than in a reconstruction.
WHAT THIS RESTS ON
Built and shipped
Regulated billing and claims automation delivered end to end for a clinical practice
Field-level provenance
Every output traceable to its source and the rule that cleared it
Audit discipline
The same traceability standard we apply on GxP and prudential platforms
Questions we hear before engagements
How is this different from just using an LLM with good prompts?
A prompt asks the model to behave. A gate makes the behaviour impossible to get wrong. We use prompts for the drafting and code for the decisions, because only one of those can be relied on when it is checked later.
What happens to the cases the rules reject?
They go to a person with the specific reason attached, not back into a queue. The exception path is part of the design rather than what happens when the design fails.
Can you work inside our existing system?
Usually yes. This pattern more often wraps around an existing system of record than replaces it, which is also the faster route to it being used.
Related capability
If your system has to be right, let’s talk.
Start the conversation →