---
title: "Naming things is the hard part"
author: Dr Arman Ouveysi
date: 2026-07-07
room: Lab
tags: ontology, knowledge-representation, medical-ai
canonical: https://drouveysi.com.au/essays/naming-things-is-the-hard-part/
summary: "Clinical ontology is where medical judgement gets frozen into structure a machine can use. It looks like admin. It is the most consequential design work in the field."
---

# Naming things is the hard part

There's an old joke in computer science: there are only two hard problems, cache invalidation, naming things, and off-by-one errors. I spent years thinking the naming one was the weakest part of the joke. Then I started building systems that have to reason about medicine, and I now believe naming things is not just hard. In my corner of the field, it's most of the job.

The formal word for this work is ontology, which sounds like a philosophy seminar and is actually the most practical thing imaginable. An ontology is the structured map of what exists in a domain and how those things relate: which symptoms there are, which conditions, which medications, what counts as severe, what implies what, what rules out what. It is the working answer to a question that sounds trivial until you try to answer it in a form a machine can execute: *what is the system allowed to think a headache is?*

![Ontology tree showing different ways headache concepts can relate](https://drouveysi.com.au/assets/articles/lab/naming-things-is-the-hard-part/fig-01.svg)

Try it. A headache is a symptom. Fine. Is a migraine a headache, or a condition that causes one? Is "the worst headache of my life" the same entity as an ordinary headache with the intensity dial turned up, or is it its own thing? Any emergency doctor will tell you it had better be its own thing, because that exact phrase is the textbook flag for a subarachnoid haemorrhage, and a system that files it under "headache, severe" has just flattened the single most important distinction in the entire presentation. One design decision. Made in a spreadsheet, probably on a Tuesday. **Someone's life will stand on it.**

That's the discipline in miniature: every node and every edge in the map is a clinical judgement, frozen into structure.

Now scale the problem up to all of medicine and add the second difficulty: the raw material. Medicine's vocabulary is not a designed system. It's **two thousand years of sediment**. Terms coined by Greeks, renamed by Victorians, redefined by committees, and abbreviated by registrars at 4am. The same event answers to "heart attack" in the waiting room, "MI" in the notes, and half a dozen formal codes in the classification systems, and those aren't even perfectly synonymous with each other. Meanwhile patients, reasonably, speak an entirely different language layered over the top. "Dizzy" is one word doing the work of five: the room spinning, the world greying out on standing, unsteadiness on the feet, a vague muzzy-headedness, and impending faint. Those five have different causes, different urgencies and different next questions. A human clinician untangles the word in seconds with two follow-ups, mostly without noticing they're doing it. A machine can only untangle it if someone taught the map that the word is ambiguous, what it's ambiguous *between*, and which follow-up cleaves the possibilities apart. That teaching is ontology work.

The obvious response is that medicine already has coding systems: big, famous ones, decades of committee effort, hundreds of thousands of concepts. It does, and they're genuinely impressive, and they were built for the wrong job. The great medical terminologies exist to classify what already happened: for records, for billing, for statistics. They assume a trained human has already done the reasoning and just needs to file the conclusion. Point them at the *front* of the encounter instead, at a person typing "I feel weird and my heart is doing something", and the seams show immediately. They're organised around diagnoses rather than the undifferentiated mess people actually arrive with, they encode committee compromises, and they have holes precisely where conversational medicine needs footing. Filing systems, asked to be reasoning systems. It isn't their fault, but it is our problem.

So you build the map you need, and immediately meet the tension that defines the craft. Too coarse, and the system is blind: if the map only has "abdominal pain", the machine literally cannot represent the difference between a grumbling appendix and period pain, and everything downstream inherits the blindness. Too fine, and the system is brittle: ten thousand exquisite distinctions that no real conversation can reliably land on, where every actual input falls between the cracks of your beautiful categories. There is no universal right answer to this tension, because the resolution depends on purpose. The map has to match the decisions the system actually makes. A triage system needs razor-sharp resolution around red flags and can stay blurry across the benign middle; a coding system needs the opposite. Ontology is downstream of purpose, and most bad ontologies are good ontologies for a different job.

Here is why I think this work counts for more than tidiness, and why it's the hill I'll defend at any dinner party unwise enough to ask. A language model, left to its own devices, already has an ontology. It absorbed one from its training data: implicit, statistical, buried in the weights, slightly different in every context, and completely uninspectable. Ask it whether chest tightness and chest pain are the same thing and it will have an opinion, and the opinion will drift with the phrasing of the question. When you build an explicit ontology, you are not adding structure where there was none. You are *replacing* an invisible, unaccountable map with a visible, arguable one. Every judgement that was latent in the model's vibes becomes an artefact: written down, reviewable by clinicians, testable by evals, fixable when wrong, and stable across every conversation. That is the entire difference between a system whose medical worldview you can audit and one whose medical worldview you have to hope about.

![Centuries of medical records: manuscripts, index cards, punch cards, dissolving into data.](https://drouveysi.com.au/assets/articles/lab/naming-things-is-the-hard-part/fig-02.webp)

There was a moment, when these models first got good, when a lot of people concluded that structured knowledge was obsolete: the model "knows" medicine now, just let it flow. The field has spent the time since learning, at various costs, that the opposite is true. The fuzzier and more capable the reasoning engine, the firmer the rails need to be, because **capability without constraint just means the failures get more articulate**. Free text goes in, accountability is supposed to come out, and the only thing that can live in the middle is structure that someone chose on purpose.

Naming things is the hard part because **naming is deciding**. Where the boundary of a concept sits, which differences carry weight, what counts as an emergency: these get decided either way. The only real choice is whether they're decided deliberately, in the open, by people who can be argued with, or implicitly, by a model, invisibly, and differently every time. I know which map I want underneath a system that talks to sick people. And I've come to love that building it is somebody's actual job. Some weeks, mine.
