85% of our decision-tree conditions were unreadable to the engine

A decision tree branches on conditions. Ours were often written like this — EGFR L858R or other classical sensitizing mutation — which reads perfectly well to a clinician and means nothing to the clause evaluator, which resolves flat finding keys and nothing else. A condition it cannot resolve evaluates to false.

We scanned every algorithm file to find out how widespread this was. The numbers were worse than expected — and worse than our own first estimate. An initial sample of the first 30 algorithms suggested 27% of them fell through on every patient; sweeping all 152 corrected that upward to 30%. The corrected figure is the one below.

What the audit found

• 152 algorithm files scanned, containing 443 free-text condition: strings.
• 376 of them — 85% — are prose-shaped, meaning the evaluator returns false rather than a real answer.
• 45 of 152 algorithms (30%) have a step 1 that is entirely prose. Those fall through to their default indication on every patient, which makes their branching decorative.

What changed immediately

The engine now warns when it meets a prose-shaped condition instead of silently evaluating it to false. That converts an invisible failure into a visible one, which is the cheapest useful step. The full audit is published at docs/reviews/openonco-state-audit-2026-05-17.md.

Why the fix is slow

Rewriting 376 clauses into structured form is not a search-and-replace. Each one encodes a clinical intent that has to be re-expressed as a finding or a red flag without changing what it means — and under this project's own rules, an LLM does not get to make that call. So the queue is worked disease by disease, with clinical review.

We are publishing the number rather than waiting until it is flattering. A tool that asks clinicians to check its reasoning owes them its own worst measurements.