DEV Community: Mohamed

Why trustworthy medical AI makes uncertainty visible instead of hiding it behind a polished clinical note.

Mohamed — Sun, 26 Jul 2026 11:51:18 +0000

A doctor mentions a medication during a consult. The AI writes a different medication name in the clinical note.

It is still a real medicine. The spelling looks correct. The note is well formatted. Nothing looks obviously broken.

That is what makes the mistake dangerous.

When people talk about AI errors, they often imagine something absurd: a made-up diagnosis, nonsense text, or an answer that is visibly wrong. Those failures are easy to catch. The harder failures are plausible enough to pass through a normal workflow without anyone stopping to question them.

In a medical record, “looks right” is not enough.

A useful note is not automatically a trustworthy note

Medical AI scribes can save clinicians a great deal of time. They turn a recorded consult into a structured note, so the clinician does not have to type everything from scratch.

But the system is working from spoken language. People talk quickly, use abbreviations, interrupt each other, and mention words that sound alike. An AI can misunderstand a medicine, make a weak connection between two facts, or write a note field with more certainty than the conversation supports.

The problem is not that AI should never help write a note. The problem is what happens when the system is unsure.

If uncertainty stays hidden, the clinician receives a polished answer that looks ready to accept. If uncertainty is visible, the clinician can make the decision that matters.

That was the safety goal behind my work on a medical AI scribe: make the system useful without letting a believable mistake quietly become part of the record.

Make uncertainty visible

A warning at the bottom of a page is not enough. It is too easy to miss, especially when the rest of the output looks clean.

Instead, every medication the system recognises should show a clear status. That includes medication names that appear to be exact matches. A name that looks correct can still have been misunderstood in context.

The reviewer can immediately see which terms need attention, choose a suggested correction, or enter the right name themselves. The system does not ask them to investigate a vague warning. It gives them a clear decision and a quick way to act on it.

The important change is simple: uncertainty becomes part of the workflow, rather than something hidden behind a successful-looking note.

Do not let AI mark its own homework

It is tempting to ask an AI whether its own answer is correct. That may produce a better guess, but it does not create a reliable check.

For important parts of the note, the system needs fixed rules: checks that give the same answer every time when they see the same evidence.

For example:

Does the medication name match a trusted medical terminology?
Is a note field supported by facts that were actually extracted from the conversation?
Is there enough evidence to show this field as a fact, or should it be marked for human review?

If the system cannot support a value, it should not write it with confidence. It should leave it empty or flag it clearly for review.

The AI can still do what it is good at: listening, organising information and proposing a draft. But it should not be allowed to decide that its own uncertain output is safe enough to enter a record.

A correction must also be safe

Safety does not only live in the big AI decisions. It also lives in the small actions around them.

A clinician correcting a medication should never accidentally change other text in the note. An empty confirmation should not overwrite a value that was already there. A review step should make it obvious what will happen before the change is saved.

These details can sound minor. They are not.

A medical record is a chain of decisions: what the AI heard, what it proposed, what the system checked, what the clinician reviewed, and what was finally saved. A small unsafe step anywhere in that chain can undermine the rest.

Good safety work is often less visible than a new AI feature. It is validation, clear statuses, sensible defaults and carefully tested edge cases. But those are the things that keep a helpful tool from becoming quietly unreliable.

Human review should mean something

“Human in the loop” is an easy phrase to say. It only matters if the human can genuinely see where the system may be wrong and can correct it without friction.

A real review step needs to answer three questions:

What is uncertain?
Why is it uncertain?
What can I do about it?

If the answer is only “please check this,” the reviewer is being asked to do extra work without help. If the system points to the exact medication or note field, explains its status and offers a safe correction path, review becomes a meaningful control.

The clinician is not there to rubber-stamp the AI. The interface should help them disagree with it when it matters.

What this does not solve

These checks do not make an AI system medically infallible. They cannot decide what a doctor truly intended in every conversation. They do not replace clinical judgement.

What they can do is more honest: stop the system from hiding uncertainty behind confident language.

When the evidence is strong, the system can help quickly. When the evidence is weak, the system should say so. And when a decision needs a clinician, the workflow should make that decision visible and easy to take.

That is what trustworthy AI looks like in production.

Not an AI that never makes mistakes. A system that makes uncertainty impossible to ignore.

I’m Mohamed Azahrioui, a backend and AI-safety developer building deterministic, auditable controls for production AI systems.

This is a software-engineering article, not medical advice.

[Boost]

Mohamed — Fri, 17 Jul 2026 17:42:43 +0000

Mohamed

Jul 17

A 200 Is Not a Read

#ai #python #security #opensource

6 min read

A 200 Is Not a Read

Mohamed — Fri, 17 Jul 2026 17:42:25 +0000

TL;DR: Your AI agent will answer from a page it never actually read, with a straight face, and the transcript won't tell you. An HTTP 200 means the bytes arrived, not that you got the page. FetchGate turns "did we actually read it?" into a deterministic RETRIEVED / FAILED / UNKNOWN verdict, and hard-fails before the model can bluff.

Give an AI agent a web tool and watch what happens when a fetch fails quietly instead of cleanly. The page comes back as an empty JavaScript shell, a Cloudflare "just a moment" screen, or a 403 dressed up as a 200, and the agent does not stop to notice. It answers anyway, from whatever it already had in its weights, and nothing in the transcript tells you it never read the page. What you get is a confident guess wearing the costume of a retrieval.

I keep coming back to this shape: a tool answers one question with confidence and leaves a second, more important one unanswered. This time the second question is the smallest and the sharpest one I have worked on: did we actually read the page, yes or no?

The visible axis: tokens

The popular version of this problem is about cost. A raw article can be tens of thousands of tokens, so people measure it, complain about it, and reach for cleaner extraction and stealth browsers to shrink it. That cost is real, and it is being handled.

But cost was never the dangerous part. Context windows grew, extraction improved, and the cost problem mostly dissolved. The dangerous part sat underneath it the whole time and never moved: whether the fetch produced a read at all.

The invisible axis: whether the fetch happened

The failure itself is simple. A model is handed no content while a question is waiting to be answered, so it fills the gap. That is what models do; it is not misbehavior. The bug is not the model guessing but the harness that lets an empty retrieval reach a final, grounded-sounding answer.

It shows up in three ways:

the fetch returns nothing and the model answers from its training weights,
the fetch returns nothing and the model answers from a stale prior it happens to hold,
the fetch succeeds, technically, but returns the wrong content (a challenge page, a consent wall, a soft 404), and the model reads that and answers as if it read the article.

What I am building here is not new groundedness work, and I want to be honest about the neighbors. RAG faithfulness checks like RAGAS and TruLens, abstention work on knowing what you don't know, and citation UX like Perplexity's "could not access this source" all live near this problem and earn their keep. But they evaluate whatever text arrived, after the fact; none of them assert that a fetch of the intended resource actually happened. That narrow delta is the whole point: a check at the fetch boundary, upstream of grounding, that hard-fails before the model ever gets to answer.

The name of the mistake

The mistake is treating an HTTP 200 as evidence. A 200 means the bytes arrived; it says nothing about whether those bytes are the page you asked for or a wall standing in front of it. A JavaScript app returns a 200 whose body is almost all script and almost no readable text. Cloudflare returns a 200 with a full "verify you are human" page. Both pass every naive check, which is why the question cannot be "did the request succeed" but has to be "did we come away with the page".

The gate, not the fields

The obvious fix is to hand the model more metadata: the status code, byte counts, a note that the page looked empty. It does not work, because richer fields the model can read are richer fields the model can ignore. The model will wave past a byte count of zero the same way it waves past an empty body. If it gets a vote on whether it read the page, you have handed the decision back to the component you did not trust in the first place.

So the decision lives outside the model, in the orchestration layer, as a deterministic gate. The gate reads what the fetch runtime measured and returns one of three verdicts:

RETRIEVED: we can point to real, sufficient content. The model may answer and cite it.
FAILED: we can point to a definite reason there is no read, such as a 4xx or 5xx, a timeout, an HTTPS to HTTP downgrade, or an empty body. The agent stops.
UNKNOWN: we cannot classify it either way, often because the page is a JavaScript app that needs rendering. The agent stops, or renders and checks again.

Three layers feed the verdict, and the strictest of them wins. The transport layer looks at the status and the redirect chain. The extraction layer keeps readable text separate from raw bytes, so that a 17-byte price JSON counts as a read while a 400 KB script shell does not. The third layer, a content-validity fingerprint, watches for the walls. It is a best-effort heuristic that will rot over time, so it is only ever allowed to pull a verdict down to UNKNOWN; it can never manufacture a read, and the only path to a hard FAILED is a transport signal. The gate fails closed or fails labeled; it never fails fluent.

Where the browser earns its weight

For pages that are genuinely empty to a static reader, the gate escalates to a real headless browser, lets the page render, and classifies again. The point is to render, not to evade: a page that is still walled after an honest render stays UNKNOWN and hard-fails. The gate opens a browser tab the way a person would; it does not defeat a control the site put up on purpose.

Provenance is a security property

Answer quality is the obvious reason to care, but not the sharpest one. Agents act on what they read, which makes silent fetch failure an attack surface as well as a bug. If I can make your agent's fetch quietly fail, or serve it a decoy, I can steer what it does next. Retrieval suppression, cloaking, and context poisoning are all attacks on an agent that trusts a 200.

That is why every decision ships with a receipt: the final URL after redirects, the status, raw bytes versus extracted bytes, and a content hash. A receipt is only as strong as what it proves, so it comes with two honest limits. The hash pins down what was read, which makes a later claim re-checkable, but it is not tamper-evidence; a cloaked page hashes cleanly. And provenance is not authenticity: the gate closes the fail-silent-on-empty hole, not the case where a fetch succeeds on wrong content that slips past the fingerprint. It raises the bar from "no evidence" to "evidence that passed the checks". That is worth having, and it is not everything.

There is a third limit: a read is not an answer. RETRIEVED means enough content arrived, not that it contained the fact you needed. Checking that is groundedness work, and it composes downstream, after the gate has done its one job.

The pattern underneath

This is the third time I have built the same shape. ReachGate decides whether a vulnerability is actually reachable in your code before a human touches the finding. TrustGate decides whether an agent may take a risky action given the live state of the data behind it. FetchGate decides whether a page was actually read before the agent answers from it.

The domains differ, but the idea is the same: let a deterministic engine make the call, let the model only explain it, and ship every decision as proof you can check yourself.

FetchGate is the smallest of the three, a gate that comes down to nearly one bit: read or not. But the fetch boundary is where an agent's grip on reality is thinnest, and it is the one place the other two do not cover. It is open source and deterministic, runs with no model and no API keys, and ships with a test that tries to sneak a fabricated read past the gate; the forgery gets caught, by design. A 200 is not a read, and an agent that cannot tell the difference will tell you it read a page it never saw, with a straight face, every time.

Get it

pip install "fetchgate[mcp]"

It is open source and deterministic. If it saves you one silent bad answer, a star on the repo helps others find it.