How to build an AI ontology, step by step: from working pipeline to model

Last time I argued that choosing between a fast AI pipeline and an operational ontology is a scoping decision, not a religion. Fine, several readers said, but what does building the map actually look like? Not the seminar version. The Tuesday-afternoon version.

This is that post. We are going to take one workflow at one facility and map it to an ontology, step by step, with every artifact shown.

One honest disclosure before we start: Cedar Ridge Post-Acute, our 120-bed skilled nursing facility, is fictional. The method, and the scars behind it, are from real builds. I made the facility up so I could show you everything without showing you anyone's operation. (The first time I did this for real, I modeled far too much. Cedar Ridge gets the version of me that already paid that tuition.)

Step 0: know what you already have

Cedar Ridge starts where most facilities start: a working pipeline, built fast, doing one job well. Hospital referrals arrive by email and eFax. An LLM reads the packet into a fixed set of fields. Exact rules run the facility's acceptance policy. Staff get a one-screen summary with a recommendation, and a human makes the call.

If you read the last post, you know the confession: this pipeline already contains an ontology in street clothes. A typed schema. A written policy. Statuses. An event log. The tutorial is not "start from zero." It is "take the knowledge you already encoded and promote it, deliberately, into a model."

Step 1: harvest the workflow in five layers

Do not open a modeling tool. Open your eyes. Watch real referrals move through the building (the intake desk, not the policy manual; the manual describes the intended workflow, which is a different document). For each case, write down five kinds of facts:

• Events. What actually happened, and when? Referral received. Documents classified. Insurance flagged. Clinical review started. Decision recorded.
• States. What was the case waiting on after each event? Awaiting documents. Awaiting payer verification. Ready for review. Accepted, bed not ready.
• Decisions. Who had to decide what? Can we meet this resident's needs? Is the information sufficient? Which unit? Is the payer verified?
• Actions. What could someone do next? Request missing records. Approve acceptance. Decline with reason. Reserve a bed. Escalate.
• Evidence. What supported each claim? The discharge summary. The medication list. The payer's reply. A nurse's observation.

Five layers, one afternoon of shadowing, maybe two. This list is the raw ore. Everything else in this tutorial is refinement.

Step 2: build the decision catalog

Pick the single most consequential decision and catalog it completely. At Cedar Ridge, as at most facilities, it is: "Can we accept this referral?"

Decision owner	Admissions nurse; DON for escalations
Inputs	Care needs, medications, behaviors, mobility, isolation status, payer, bed and staffing picture
Required evidence	Discharge summary, med list, physician orders, payer verification
Hard constraints	The facility's exclusion list; services it is not licensed or staffed to provide
Professional judgment	Can these needs be met safely, on this unit, with this week's staff?
Possible outcomes	Accept, Decline (with reason), Hold, Request information, Escalate
Reason required	Always
State transition	ClinicalReview → Accepted (or Held, or Declined)
Downstream actions	Reserve bed, notify pharmacy, draft the payer request, start the intake packet
Audit	Actor, time, evidence, and reason, every time

This one table is worth more than a hundred database columns, because every row came from watching a person decide something real. (It also exposes the quiet truths: "reason required, always" is culture, not technology. Write it down while it is still culture.)

Step 3: compile the catalog into ontology v0

Now, and only now, open the modeling tool. The compilation rule: objects are the nouns people act on; links are how the decision connects them; actions are what people are permitted to do; evidence and events ground all of it.

Cedar Ridge's version-zero ontology lands at ten objects: Resident, Referral, Care Need, Facility Capability, Unit and Bed, Staff Skill, Authorization, Task, Event, Placement Decision. Plus roughly ten governed actions. That is not a typo. Ten and ten runs the entire admission mission. Version zero should embarrass the enterprise-architecture part of your brain.

The one modeling move that matters most: capability is conditional. Cedar Ridge does not "support wound care." It supports wound care on Unit B, on shifts where a certified nurse is scheduled, when supplies are stocked, under current census. Model capability as that intersection and "empty bed" becomes "serviceable capacity," which is the number the admissions nurse actually needs.

Step 4: make facts carry their receipts

Here is the pattern that separates a real operational ontology from a pretty diagram. The hospital's discharge summary says the resident needs two-person assistance. Your receiving nurse observes one-person-with-walker. A naive system overwrites the first with the second. A governed system keeps both:

Every consequential fact carries its source, author, time, and verification status. This is how the system answers "what did the hospital claim versus what did we verify?" later, which is a question someone will eventually ask with a lawyer in the room. (The LLM's job here is exactly one thing: reading "assist x2," "2PA," and "requires two staff for transfers" in messy documents and proposing the same normalized CareNeed. It proposes. It never verifies.)

Step 5: know where to stop

The rabbit hole is real. Every field in the EHR whispers "model me." Refuse, using one test: does this information change a decision or an action? No? It stays in the source system, retrievable when needed, promoted only when a concrete use case demands it.

The boundary principle from last time, worth repeating verbatim: the ontology should be complete enough to run the target workflow, not complete enough to describe the entire business. Cedar Ridge's ontology does not know what a 401(k) is. It never will.

Step 6: ask the questions the pipeline could not answer

This is the payoff, so let us be concrete. Three questions, straight from Step 1's decision list, that the pipeline could not answer and the ontology answers as queries:

• "Which beds are actually suitable for this resident arriving at 4 p.m.?" Care Needs, joined to conditional Capability, joined to the shift schedule and equipment. Not "which beds are empty."
• "Where do the hospital's claims and our observations disagree?" Assertions versus findings, grouped by resident, sources attached. Step 4 made this a filter, not a forensic project.
• "The 2 p.m. shift change lost our wound-certified nurse. Which accepted residents are affected?" Capability recomputes; affected placements surface with reasons.

And the answer format matters as much as the answer. A dashboard says "seven referrals delayed." The ontology-backed system says: these seven, here is each blocker, here is the owner, here is the evidence, and here are the permitted next actions. The first is reporting. The second is operations.

Step 7: let real cases correct the model (this is the feature)

Month one at Cedar Ridge goes exactly the way month one always goes. The floor's actual intake process turns out to differ from the binder in three places. A payer everyone assumed was a hard no turns out to be a hold-and-verify. The administrator asks for the rules to be editable without calling a developer. And two weeks in, leadership wants transportation coordination added, which nobody mentioned in discovery.

The pipeline absorbs each of these as a code change: another conditional, another migration, another quiet bolt-on. Scar tissue. The ontology absorbs them as governed model changes: a rule's outcome edited, with an owner and a version; a new Transport Task object linked to Placement Decision; a changelog a human can read. Same corrections, radically different residue.

This is what "the ontology evolves the project forward more accurately" means in practice. It is not that the map is right on day one. It is never right on day one. It is that the map is the only artifact where being wrong is cheap to fix and impossible to hide. Real cases correct the model faster than any workshop, and the corrections compound instead of accumulating as scar tissue.

The one-page version

For the wall next to your desk, the whole idea compresses into one reference sheet: what an ontology is, how the LLM uses it, and the implementation layers underneath.

And the division of labor underneath it, unchanged from last time because it is the invariant:

Start with one mission. Watch the real work. Catalog one decision completely. Model ten objects, not two hundred. Make facts carry receipts. Know where to stop. Then let reality do the editing.