Why an LLM never picks the treatment
The project started out asking a language model to rank treatments. That approach is now archived, and the rule that replaced it shapes everything else: recommendations come from a versioned knowledge base, not a model.
Written retrospectively and published on July 19, 2026.
There is an earlier version of this project in the repository, under legacy/. It worked the obvious way: feed a patient profile to a language model, ask it which treatments look best, rank the answers. It is retired rather than deleted, because how it failed is worth keeping.
The problem is not that such a model is usually wrong. It is that you cannot tell when it is. There is no trace to inspect, no source to check, and the same input can produce a different answer tomorrow. For a tool a clinician is meant to reason with, that is disqualifying.
So the rule is written into the project charter (§8.3) rather than left as a preference:
Clinical recommendations come from a declarative rule engine reading a versioned knowledge base. LLMs do not choose regimens, generate dosing, or interpret biomarkers for treatment selection.
What language models are still allowed to do
Draft prose. Translate, with clinical review. Extract structured data from a clinical document, for a human to verify. Write boilerplate code. All of it upstream of the decision, none of it inside the decision.
What this costs
Coverage. A model will answer anything; a rule engine only answers what someone has authored and cited. That is why so much of this project is the unglamorous work of writing knowledge base entries with sources attached, and why the coverage gaps are published rather than hidden.
The trade is deliberate. A narrower tool whose reasoning you can audit beats a broader one you have to trust.
Comments
Threads are public and indexed — please keep personal medical data out of them. Found a clinical error? Open an issue instead.
Comments are not switched on yet — the backend still needs to be configured.