Failure 01
It misunderstands the question
You ask about last quarter; it answers about last month. Nothing looks wrong — the number is real, it is just the wrong number.
AI engineering
Most AI demos are convincing. The hard part is being right.
Any language model will answer a business question fluently. The engineering problem is not fluency — it is making sure the answer is true, every time, for a number that is going into a board pack. Here is how the systems I build do that, without skipping the parts that matter.
The model never produces a number
This is the principle everything else follows from. The figures are fetched first, by fixed, pre-written, pre-tested queries. The model’s job is to decide which figures to fetch, and then to write the sentence around them. It is never the source of a number.
That single constraint removes most of the ways an AI system embarrasses you.
Three ways an AI gets your numbers wrong
And a fourth that is worse than all of them.
Failure 02
It looks in the wrong place
It joins the wrong table, or applies a filter that does not exist and silently ignores it. You get a confident answer to a question you did not ask.
Failure 03
It states a figure that is not there
The hardest one. The prose is fluent, the number is plausible, and it appears nowhere in your data.
And the worst one
It shows one person another person’s data
The fourth, and the one that ends relationships.
The path a question takes
Four gates. The track narrows at each one — the argument is constraint, not capability.
01Gate
Understand
85 verified questions
Your question is matched against a bank written and checked by hand, using exact word rules rather than a nearest guess.
If it fails
No match → the agent plans it out with tools instead, with the same checks on every figure.
02Gate
Fetch
14 approved functions
78 approved filters
It picks from a fixed menu of data functions. There is no facility for the model to write its own database query.
If it fails
An unrecognised filter is a hard error, not a quietly ignored one.
03Gate
Ground
Every number checked
Once the answer is written, every figure in it is extracted and checked against the data that was actually fetched.
If it fails
Not found → the whole answer is discarded and rebuilt directly from the data.
04Gate
Scope
Per-user data boundaries
Tools that cannot honour a user’s store restrictions are removed from the model’s options entirely.
If it fails
Out-of-scope data in the finished answer → the whole response is refused, not trimmed.
153 of 153 accuracy checks must pass before any of this ships.
Verified questions, not similarity search
Eighty-five questions, written and checked by hand. When you ask something, your words are matched against that bank by plain rules — word stemming, a dictionary of alternative phrasings, and a scoring gate with terms that must be present.
This is deliberately not the popular approach. The common method turns questions into vectors and finds the closest previous one, which has a bad property: it always finds something. When your question is unlike anything it has seen, it returns its nearest miss with full confidence. Exact rules fail loudly instead, which is what you want. The cost is that the bank is maintained by hand. That is the trade, and I made it on purpose.
The dashboard and the assistant must mean the same thing
This sounds like a detail. It is the thing that quietly destroys confidence in every analytics system.
If the dashboard counts a returning customer one way and the assistant counts them another, you get two different numbers for the same question and you stop trusting both. So every metric, filter and time window is defined once, in one place, and both read from it. Neither has its own copy. Neither can drift.
Two architectures, and when I would pick each
| The closed toolbox | The guarded query writer | |
|---|---|---|
| How it gets data | Picks from 14 pre-built, tested tools | Writes a database query itself |
| Can it write SQL? | No. There is no such tool in the system. | Yes — and every query passes a gate first |
| The gate | Not needed — a bad query cannot be composed | Read-only statements only; approved tables only; no semicolons, comments, file or sleep functions; a row limit added automatically |
| If it fails | Falls back to a deterministic answer | Reads the database error and retries, up to three times, then stops |
| Where the model runs | Hosted, with a fallback chain | On your own server. Nothing leaves the building. |
| Best when | The questions are known and the answers must be exact | The questions are open-ended and the data cannot leave |
Every answer is tested before it ships
Before anything ships, a suite re-asks a fixed set of questions with known answers and checks three things: was the time period read correctly, is every number traceable to data that was actually fetched, and does the result match what the dashboard itself reports for the same metric. The documented pass rate across six suites is 153 out of 153.
Underneath sits a second net: 52 data checks, including the one most pipelines skip — an assertion that last quarter’s numbers are still last quarter’s numbers after tonight’s refresh. A pipeline that quietly rewrites history is a worse problem than a model that guesses, because nobody notices for months.
Plainly
What I have not built, and will not claim I have
The systems described here use exact, verified retrieval and a fixed set of data functions. They do not use a vector database, embeddings or similarity search — that was a design decision, not an omission, and the reasoning is above.
They also do not include automatic detection of personal data, defences against deliberate attempts to manipulate the model, or a second model judging the first one’s answers. Those are real techniques and I can build them where a project needs them. They are not running in these systems today, and I would rather you heard that from me than found out later.
Want to see it answer a question on your own data?
Send me a sanitised extract and a list of the questions your team asks every week. I’ll tell you which of the two architectures fits, and why.
Tell me what’s slow, manual, or unreliable.
Twenty minutes on a call is usually enough for me to tell you whether software is the answer and roughly what it would cost. If it isn’t, I’ll say so.
Available for freelance builds alongside senior engineering work. One or two projects at a time.