The blogBrick by brick · Episode 3/5
Published on
A good answer addressed to nobody
The real bottleneck isn't the model's intelligence. It's the state of whatever you want to plug it into.
"Brick by brick" series, Episode 3/5 · 1. The code Auditor · 2. Documented search · 4. ITFacto · 5. The model is the last question
The compliment that wasn't one
When you show a documentary search system to a practitioner, there's a precise moment where their enthusiasm drops. They don't always say so, but you can see it.
They asked a general question, to test it. They got a good answer, sourced, honest. They nod. Then they think about the case waiting on their desk, and the question they actually wanted to ask isn't that one. Their question starts with "for this patient, who has this and that, and who has already had this done".
An accurate answer addressed to nobody is still a document. It has value, it doesn't gain you much: the practitioner already knew how to search the literature, they've never been short of literature. What costs them time is connecting their case to it.
Put differently: my system didn't know what it was being talked about. That's the gap the third brick closes.
The real bottleneck isn't intelligence
Here's the idea this episode wants to land, and it holds well beyond healthcare.
In almost every project, what blocks progress isn't the model's ability to reason. It's the state of whatever you want to plug it into.
The information exists. It's there somewhere, in a line-of-business application, a case file, an export. But it's written in a format that matches no other, with in-house codes, identifiers that don't reconcile, free-text fields filled in differently by each department. Every one of those systems works perfectly. They simply don't talk to each other.
The problem has an unglamorous name: interoperability. It doesn't make headlines, it's mentioned in no model announcement, and it decides the real timeline of projects.
Why I chose the best-equipped sector
There's a logic to that choice, and it extends the previous episode's.
Healthcare is probably the field that has worked hardest on the question. There's an international standard for exchanging health data, shared terminologies for naming conditions unambiguously, and in France a national server that makes those terminologies available. Decades of standardisation, dedicated institutions, public funding.
In other words: the best possible conditions. If, even there, holding the chain together meant measuring what each system actually applies, then the argument held for everyone.
That's exactly what I found.
The demonstrator does something simple to state. It reads a patient record in the standard format. It takes the problems coded in it - as identifiers that mean nothing to a human - and resolves them into French labels by querying the national terminology server. 97.3% of the codes encountered get a French designation there, which is excellent and still leaves one code in thirty-seven untranslated. Then it puts a question that has become specific to the engine from Episode 2, and gets back an answer in which every sentence cites the extract that grounds it.
Nothing to reinvent. Everything to connect. The work wasn't creating intelligence, it was making existing bricks hold together when they'd never met.
What servers say, and what they do
Here's the part I wasn't expecting, and which ended up being the heart of the demonstrator.
I plugged the same client into three patient-record servers - a reference simulator and two sandboxes from a major vendor. Then I measured what each one actually enforced, instead of reading what it announced.
All three behave differently, and two depart from their own documentation.
The first validates an authorisation token when you present one, but requires none in order to read. The second has no authorisation layer at all: it doesn't even publish the configuration that would describe how to connect, because there's nothing to describe - it lets you read, full stop. The third is the only one of the three that genuinely enforces the scopes it grants.
The best example is the first. Its configuration states in black and white that it accepts standalone application launch. Yet it refused every one of my requests, until I worked out that it was waiting for launch options encoded in the address - in practice, an empty JSON object encoded in base64. Three characters. Nothing in the specification hinted at it, and nothing in the error message said so.
That's what interoperability looks like in 2026. Not an absence of standards: they exist, and they're good. The gap between the standard as announced and the standard as applied. A gap you only discover by measuring, and which the demonstrator's page now shows server by server - because that's precisely what the project has that's worth showing.
Note in passing that this isn't the first time I've hit this wall. Two years earlier, inside a company, a perfectly functional application went to production and was never used, for a reason of the same order: the information it needed didn't exist in any usable form. That's the story of Episode 4.
Knowing where to stop is part of building
A word on what this demonstrator is not, because restraint is a design decision like any other.
It runs on synthetic records. It is a documentary search tool. It is not a medical device, not a diagnostic aid, not a treatment decision aid, and it does not at any point claim to be heading that way.
That isn't boilerplate added at the bottom of the page. It's a boundary drawn before the first line was written, and it determined what I allowed myself to build. A system that brings a record alongside public documentation and shows its sources is one thing. A system that suggests what to do is another, with an entirely different regulatory frame, validation requirements and liabilities.
Confusing the two would be an engineering fault before it was a legal one. A good part of engineering consists of knowing how far the system goes, and saying so plainly to whoever uses it.
The same standard applies to the bricks you borrow. The terminology the demonstrator queries is licensed: its version, the terms of use, and the attribution of the agency that publishes it are displayed on the page. Nobody asked me for that - but a system whose vocabulary has no stated origin is no more traceable than a system whose answers have none.
The brick
It fits in one sentence, and it's the one I've carried into every project since:
The value of an AI system lies less in the model than in what you've correctly connected it to.
Which translates, at the first meeting, into a very unspectacular and very decisive question: what does this system need to be plugged into, and what state is that data in?
The answer to that question contains the project's real timeline. Not the technical choice, which is settled in an afternoon. The connecting is counted in weeks, sometimes months, and nobody puts it on the initial plan.
Last word
Three bricks laid. Describe quality before producing it. Answer while showing your sources, or say nothing. Connect the system to the real world so its answer is addressed to someone.
Three bricks built alone, in front of a screen. And that is precisely their limit.
A demonstrator has no users. It has no executive committee to convince, no team that will have to change its habits, nobody who will decide after three weeks to go back to the old way. None of that can be simulated.
The next brick isn't the last one laid. Chronologically it's the first, and it is of a different nature: twenty months inside a company, five applications, and people across the table.
That's Episode 4.
📖 In the same series - Episode 1: the code Auditor (my first project doesn't build anything) · Episode 2: documented search (cite your sources, or say nothing) · Episode 4: ITFacto (twenty months, five applications, real users) · Episode 5: the model is the last question (the four questions for the first meeting).
The three systems described in this series are online and public. I design traceable, verifiable AI systems, from use case to deployment - more about my background, or write to contact@lamoulinette.ai.