Part VI: TriageBench, End to End

We have spent five parts building the pieces separately.

Now we will put them together.

This chapter follows one benchmark from its source material to the point where it can produce a defensible result. It is not a clean classroom example. It is based on a real clinical decision support system built by Gum Tech for UK doctors.

The doctors used the platform to turn their clinical decisions into complete patient-assessment pathways without writing code. They wrote the questions, the possible answers, the next steps, the assessments and the recommended over-the-counter products by hand between 2017 and 2020, before large language models became part of the process.

That makes the material unusual.

It does not contain loose medical facts scraped from the web. It contains the sequence of decisions a doctor chose to make while a case was still unfolding.

The question is what part of that system can be turned into a clean benchmark.

Chapter 18: From clinical pathways to a benchmark#

Step 1: Find the decision worth measuring#

The original system can do several things.

It can ask a patient questions. It can follow different routes based on their answers. It can produce an assessment. It can advise someone to speak to a doctor. It can recommend suitable over-the-counter products where appropriate.

Trying to evaluate all of that with one score would create a vague medical AI benchmark.

So the first version starts earlier and asks a narrower question:

Given the conversation so far, can a model decide whether to ask another question or stop, and can it select the same next step as the doctor-authored pathway?

This is sequential triage reasoning.

The model is not shown a complete case and asked for a diagnosis. It has to act while information is still missing.

Sometimes the safe action is to ask one more question.

Sometimes another question adds no value and the correct action is to return an assessment.

The difficulty lies in knowing which situation you are in.

Step 2: Write the capability contract#

Before generating tasks, freeze what the first version will measure.

Visible input

The system sees:

• the opening complaint;
• the clinical pathway family;
• the questions already asked;
• the patient's answers so far;
• the valid next-question or assessment candidates for that state.

Required output

The system returns:

• ask_question or return_assessment;
• one candidate identifier.

Hidden reference

The evaluator keeps:

• the doctor-authored next action;
• the correct next question or assessment;
• source provenance;
• the pathway family used for grouped analysis.

Primary metric

The prediction is correct only when both the action and selected destination match the reference.

This is exact-decision accuracy.

The contract deliberately does not score free-form diagnosis, treatment quality, urgency or patient-facing communication in version 0.1. Those are important capabilities, but they need their own reference and scoring work.

Step 3: Turn complete routes into decision states#

The ten clinical pathway families contain 2,914 complete routes from an opening complaint to a final assessment.

A route is useful, but it is not the smallest evaluation unit.

Consider a route with five questions. It contains several moments where the model has to choose what to do next:

1. after the opening answer;
2. after the second answer;
3. after the third answer;
4. before the final assessment.

Each moment becomes a decision state.

If we projected every route independently, shared beginnings would appear many times. Instead, repeated conversation prefixes are collapsed into one unique state.

The resulting set contains:

The difference between 2,914 routes and 4,050 states is important.

A model is not evaluated only at the end of a consultation. It is evaluated at the points where its next decision matters.

Step 4: Keep the full conversation state#

The current question is not enough.

The same question can be reached after different answers. Those earlier facts can change the meaning of the next step.

Each task therefore keeps the full dialogue prefix.

A simplified model-facing task looks like this:

{
  "case_id": "triage-example-001",
  "pathway_family": "Headache",
  "dialogue": [
    { "role": "clinician", "content": "Did the pain begin suddenly?" },
    { "role": "patient", "content": "No" },
    { "role": "clinician", "content": "Have you had a recent head injury?" },
    { "role": "patient", "content": "No" }
  ],
  "candidates": [
    { "id": "question-a", "type": "ask_question", "text": "..." },
    { "id": "assessment-b", "type": "return_assessment", "text": "..." }
  ]
}

The ellipses are only there because this is an explanatory example, not a released clinical record.

The actual reference stays private.

Step 5: Use a closed decision set first#

Why show candidates instead of asking the model to write any medical question it wants?

Because version 0.1 needs a deterministic claim.

If the model writes a new question, several answers may be clinically reasonable. Judging them requires a new rubric and expert review. That would mix question generation with routing ability.

The closed set asks a cleaner question:

Can the model choose the doctor-authored next step from the valid options?

This resembles many real systems. A model often chooses from actions exposed by software rather than inventing a new tool or workflow from scratch.

Free-form question generation can become a later track. It should not blur the first one.

Step 6: Build counterfactual pairs#

A single accuracy score can hide shallow behaviour.

Suppose two cases contain the same conversation until one patient answer changes. The doctor-authored pathway then takes a different next step.

A model that ignores the changed answer might still score reasonably across the whole test. A paired comparison exposes the problem directly.

TriageBench creates 9,716 matched pairs where:

• the preceding dialogue is held constant;
• one answer changes;
• the expected next action may change or stay the same.

The pair asks two questions:

1. Did the model change its decision when the clinical pathway changed?
2. Did it remain stable when the pathway did not change?

This is more informative than adding thousands of unrelated examples. It tests whether the model responds to the fact that was changed.

Step 7: Split by pathway family#

An 80/10/10 row split would look normal and be wrong.

Many states share the same opening complaint, questions and route prefix. If neighbouring states appear in training and test, the test is not genuinely new.

TriageBench keeps every state from one complete pathway family in one split.

This is approximately 80/10/10 by states. The percentage is not the important part. The isolation is.

No complete pathway family appears in more than one split.

Step 8: Score the smallest defensible claim#

The primary scorer checks two fields:

predicted action == reference action
and
predicted candidate == reference candidate

If both match, the exact decision is correct.

Supporting metrics explain the result:

• coverage;
• ask-versus-assess accuracy;
• exact next-question accuracy;
• exact assessment-route accuracy;
• counterfactual-pair accuracy.

The supporting metrics are not alternatives to the primary metric. They answer why a system received its score.

A model may know when to stop but choose the wrong assessment. Another may select good next questions but continue asking after the pathway has enough information. The total score alone cannot show that distinction.

Step 9: Test the evaluation before testing models#

The reference answers run through the scorer first. They must score 100% on every deterministic metric.

That proves the released tasks and scorer agree with each other. It does not prove the benchmark is difficult or valuable.

Next come the weak baselines:

• random candidate selection;
• always ask;
• always assess;
• always select the first candidate;
• valid format with an intentionally wrong destination;
• probes for reference or template leakage.

The class distribution already reveals one useful warning. There are 2,914 stop-and-assess states out of 4,050 total states. An always-assess system would therefore get the broad action right about 72% of the time before making a single useful clinical distinction.

This is why action accuracy cannot be the primary metric.

Exact destination selection and counterfactual consistency make the shortcut visible.

Frontier-model results should not be published until these diagnostic baselines have been run and inspected. No placeholder leaderboard is needed.

Step 10: Compare complete systems#

When model runs begin, the receipt must include more than the model name.

For every result, record:

• exact model and provider version;
• complete prompt;
• candidate presentation order;
• generation settings;
• retry policy;
• token and time budget;
• evaluation date;
• task, scorer and harness versions;
• result-file hashes.

Candidate order is worth calling out. If the first candidate changes and the score changes with it, the benchmark has found a position bias rather than a clinical capability difference.

Run order-reversal and prompt-perturbation checks before accepting a result.

Step 11: Calculate uncertainty at the right level#

The 4,050 states are not 4,050 unrelated clinical samples.

States inside one pathway family share language, structure and authored decisions. Treating each state as independent makes the result look more precise than it is.

For model comparisons:

1. score both systems on the same states;
2. calculate the per-state difference;
3. resample complete pathway families rather than individual rows;
4. report the paired score difference and clustered confidence interval;
5. show results by pathway family and action type.

With only ten pathway families, uncertainty will be wide. That is honest. A larger number of generated states does not create a larger number of independent clinical domains.

The benchmark can grow by adding new doctor-authored pathway families, not by repeating existing prefixes more times.

Step 12: Inspect failure modes#

Every wrong answer should enter one of four first-level categories:

1. Premature assessment: the system stopped when the pathway asked another question.
2. Unnecessary questioning: the system asked when the pathway returned an assessment.
3. Wrong destination: the broad action was right but the selected next step was wrong.
4. Counterfactual inconsistency: the system ignored, or overreacted to, one changed answer.

Then inspect concentration.

Does one pathway family create most premature assessments? Do failures increase with longer conversations? Does candidate order matter? Are two assessments linguistically similar enough to confuse the system? Does performance collapse when one answer changes the safe route?

Those questions turn the benchmark into a research instrument.

Step 13: Publish the boundary with the result#

A high TriageBench score means:

Under the published interface and evaluation settings, the system often selected the same next action and pathway destination as the doctor-authored UK clinical triage system on the held-back pathway families.

It does not mean:

• the system is safe for unsupervised patient care;
• it can diagnose conditions outside the pathways;
• its medical knowledge is current in every respect;
• it communicates appropriately with every patient;
• it improves clinical outcomes;
• it has regulatory approval.

Those are different claims and require different evidence.

The benchmark remains valuable because it measures one capability other medical benchmarks often miss: making the next decision while a clinical conversation is incomplete.

Step 14: Release a chain, not a landing page#

The first public release should include:

1. the benchmark page and verified leaderboard;
2. this worked explanation in research form;
3. the benchmark paper;
4. public schemas, scorer, harness and tests on GitHub;
5. approved examples and a dataset card on Hugging Face;
6. a hidden evaluation service;
7. result receipts;
8. a benchmark card and changelog;
9. submission, correction and maintenance policies.

Every artefact should show the same benchmark version.

Every result should link back to the exact method that produced it.

What TriageBench teaches us#

The most useful lesson is not medical.

It is that valuable benchmarks often begin inside working systems.

The clinical platform was not built to create an LLM leaderboard. It was built so doctors could encode patient-assessment decisions and update them without waiting for software releases.

Years later, that structure makes a new evaluation possible.

The route from system to benchmark was:

1. find one important decision;
2. preserve the full state needed to make it;
3. hide the reference;
4. keep related cases together;
5. choose the least subjective scorer;
6. test the scorer and shortcuts first;
7. report uncertainty at the source-family level;
8. publish only the claim the evidence supports.

That pattern transfers to other domains.

A customer-support workflow can test whether a system asks for missing account information or takes the next approved action.

A financial process can test whether a system requests another document or makes a decision under a defined policy.

A compliance workflow can test whether a system escalates, investigates or closes a case as evidence arrives.

The hard part is not turning records into prompts.

The hard part is deciding what those prompts can honestly prove.

End-to-end checkpoint#

TriageBench now has the shape of a complete benchmark:

1. one narrow capability;
2. a frozen model-facing contract;
3. doctor-authored references;
4. unique full-dialogue decision states;
5. matched counterfactual pairs;
6. pathway-family-isolated splits;
7. deterministic exact-decision scoring;
8. an oracle scorer test;
9. a required weak-baseline suite;
10. complete-system result receipts;
11. pathway-family-aware uncertainty;
12. a failure taxonomy;
13. a public/private release boundary;
14. an explicit interpretation boundary.

The task generation, schemas, deterministic scorer and reference test are implemented. The weak model runs, clustered result analysis and first public leaderboard remain release work. They should produce real measured results, not illustrative numbers.

Sources#

• HealthBench
• NHS Pathways
• OpenAI: A shared playbook for trustworthy third-party evaluations
• Anthropic: A statistical approach to model evaluations

Previous: Part V | Guide index | Next: Appendices