How to Build an Enterprise Ontology That Actually Delivers Agent Reliability

Black-box decisions, confident, inconsistent, and explainable only after an expert manually traces one back to its source, are a recurring cost: expert hours, and the trust that erodes every time nobody can defend the answer. A payer scaling prior authorization on AI runs into exactly this, and healthcare AI keeps running into it broadly, payers included. The fix is three layers, built three different ways: select the domain ontology that already exists, generate and curate the enterprise-specific rules on top of it, then capture and feed back what happens when real cases run through it. That sequence is how you build agents that produce consistent, explainable, SOP-aligned decisions from the start, so the trace already exists before a bad denial makes the news.

We use "ontology" here to cover three layers most definitions split apart: the borrowed code sets, the payer's own policy structure, and the operational reality and decision traces of incoming prior authorization requests. That's broader than the standard sense. Ontology vs. taxonomy vs. schema walks the standard, narrower distinction between those three terms, if you want it before reading on.

Just like everything else you'd ship in the enterprise, this build works by starting narrow, validating, expanding, then feeding back what you learn, a loop that never really closes. If you've run Agile before, the shape will feel familiar: start small, test, productionize, iterate.

We'll carry one example the whole way through to show how. A healthcare payer, growing fast, putting AI on prior authorization: the pre-service decision about whether a requested drug or procedure is covered and medically necessary. A wrong answer here denies a valid request or approves one that should have been stopped. Both cost real money and real trust. That's what makes prior authorization worth an ontology in the first place. The payer is illustrative and composite, not a named customer.

Does building this structure make the AI understand prior authorization?

One bound on what these layers can promise before anything else: machine-readable and machine-interpretable aren't the same claim. The machine only ever applies what a person already declared, correctly for every case that declaration covers, and it fails visibly the moment a case arrives that it doesn't.

Take one authorization request. member-4471 enrolled-in commercial-PPO. request-88213 asks-for semaglutide. semaglutide covered-for type-2-diabetes. Three facts a system can check, each a triple. Deciding one prior-auth request means checking many of these against each other and against the rules. Everything from here is about where those triples come from, who gets to decide they're true, and what happens to the one nobody declared for.

What does an enterprise ontology actually consist of?

What do I mean when I say the payer's enterprise ontology? I mean all three layers composed: the borrowed code sets, the benefit and policy structure they build for themselves, and the living record of what actually happens when requests get decided. That is wider than common usage, which reserves the term for the middle layer alone.

I am stating it plainly because a technical reader will push on it, and should. The narrow usage is defensible. I take the wide one because the three layers only make sense together, and because treating the live decision record as somehow outside the ontology is precisely how a payer's configuration goes stale while everyone believes it is current.

In plainer terms: a domain ontology you choose, an organization- specific ontology you build, and a live transaction layer you capture.

Why do relationship types matter more than graph size?

Most teams picture a knowledge graph and start counting nodes. That is the wrong thing to count. Mike Dillinger, who built LinkedIn's economic graph and now runs Hypergraph, put it plainly when he came on the podcast: the size of the graph is secondary, and the relations are what matter. His way of seeing it stuck with me. The set of relations hanging off a node is, for all practical purposes, the definition of that node. Give a concept one kind of relation and you have an impoverished definition. Give it ten kinds and the system has something rich enough to reason over.

That is what people mean, loosely, by "sparse versus dense" here, though it is not graph density in the formal sense, edges relative to how many are possible. What actually matters is relation variety: how many distinct, informative relation types describe a concept. A node starved of relation types is thinly defined, nothing to reason across, no matter how many edges touch it. Adding edges only helps when each one carries a distinct, informative relation. Pile on edges of one generic relation and you've added volume, not meaning, and this is the part worth internalizing before you build a thing. Mike tells the story of a pharma company that poured millions into a single relation, "associated with," until everything in the graph was related to everything, every query returned the whole world, and the graph was useless. Dense in one generic relation just buries the signal under bloat. He has a stack of these knowledge-graph autopsies, and walks through more of them on the ContextOps episode.

The discipline that avoids both is a small, deliberate vocabulary of relations. A few dozen, in Mike's experience: few enough for a human to curate and audit, yet combined in enough ways to describe millions of concepts. Keep the core set small enough to validate, and let combination give you the reach. How many relation types a givenrule needs is a resolution question; catching a graph that has over-invested in one empty relation is an evaluation question. Here it is enough to fix the instinct: you are building a web of typed, informative relations, and the relations are what carry the meaning.

Layer 1: How do you choose a domain ontology?

The hardest-looking layer is the one the payer mostly does not build. The domain ontology already exists for your field: published code sets and standards, true regardless of your company. You select the concept types your use case touches, map them to those standards, and prune to the subset you actually use.

The concepts that exist across all of healthcare billing, independent of this company, are already published as code sets:

• Diagnoses: ICD-10-CM
• Procedures and services: CPT and HCPCS
• Drugs: NDC and RxNorm
• Inpatient stays: DRGs

No payer invents these. You adopt them and take the subset your lines of business touch. Before modeling anything from scratch, go looking, because the instinct that "our plans are too specific for any standard" is almost always wrong and cheap to disprove.

For our semaglutide request, the drug resolves cleanly to its NDC and the diabetes indication to an ICD-10 code, both selected from an existing standard.

One edge case: what about a concept no public code set carries, like this payer's own definition of a preferred provider tier? You mine your golden-source documents, the provider contracts and plan designs, for a candidate structure, still largely automatable. One thing carries forward from this: a fact mined with no domain to sit in is well-formed and semantically homeless. It hangs.

Either way, what you've selected and pruned here is what Layer 2 has to build on top of next.

Layer 2: How do you build your organization-specific ontology?

Turn policy into grounded rules. This layer takes the SOPs, policies, procedures, and regulations your organization actually follows, and turns them into rules, grounded in the domain ontology Layer 1 already gave you. A clause buried in Medical Policy MP-2201, "step-therapy required before semaglutide is covered," approved by the medical policy lead, attaches to the semaglutide concept Layer 1 already selected, or to a concept you mine and govern the same way when none exists, the preferred-provider tier from Layer 1's own edge case is one. Build it disconnected from Layer 1 and you get the same failure the rest of this piece keeps returning to at the level of one fact, except now it's the whole layer that hangs.

Taxonomy first, ontology after. No code set encodes what this payer covers, for whom, under what conditions, so you generate that structure from your own documents. The cheapest first move is the taxonomy: a classification of the concepts this company cares about, often sitting there already in some form, borrowed or inherited from some other project. The relations and the rule on top of it, the part that can actually enforce something, are what turn it into an ontology, and that's where the real work and the real cost live. Then a person curates it, and that step carries real weight.

Two examples, both the kind of thing that surfaces on any real project:

• Same words, different meaning. "Medical necessity" is defined one way for a commercial plan and another for the Medicaid line. A system that grounds a request to the wrong definition will confidently apply the wrong rule.
• Same concept, different grain. A "provider" is a single rendering clinician by NPI to the utilization-management team, and a contracted group by tax ID to the network team.

Notice that even this disambiguation is anchored to Layer 1: NPI and tax ID are themselves borrowed, federally-standard identifiers that predate this payer entirely. No public code set will reconcile which one applies here, because that choice belongs to this company's own org chart, while the identifiers underneath it were always borrowed.

That is why this layer costs what it costs. The knowledge is real, written down across a hundred policy PDFs, and ambiguous or tacit enough that it has to be validated rather than trusted.

Once curated, this layer still will not stay true on its own. Layer 3 is what keeps it that way.

Layer 3: How do you capture the transaction layer? (Context Graph)

Mine the conversation, feed it back. This layer mines the reasoning behind resolved cases, human to human and now human to agent, and feeds the durable parts back up into Layer 2's rules. The first two layers you build once and keep validating. The third never stops moving, because it is the record of how the work actually happens. Most published ontology guides end at "you built it." This layer decides whether what you built is still true next month.

Here is what teams get wrong about it: they assume the live knowledge sits in the system of record, the auth platform, the ticketing tool, the warehouse. Most of what it holds is the outcome, that a request was approved or denied, sometimes with a reason code or a reviewer's note attached. The reasoning behind that outcome, and the updated understanding that should change the next decision, usually lives somewhere the system never sees: in conversation.

That conversation looks like:

• The Slack thread where a nurse reviewer asks the medical director why a request pended.
• The peer-to-peer call where the policy team finally settles what "medically necessary" means for the new Medicaid line.
• The WhatsApp message that closes an edge case at 9pm.
• Increasingly, human to agent: the analyst pasting a policy into Claude to interpret it, or a Claude Code session wiring up a new criteria rule.

That reasoning is some of the most current understanding in the company, and for most enterprises, most of it goes uncaptured. This interaction layer is the substrate the Context Graph names: the real ground for enterprise AI is your documents and databases, plus the traces of people and agents doing the work, reasoning out loud and correcting each other. Mining it is not a free pass to pull every Slack channel and call transcript into a pipeline. A conversation can surface a candidate change; it does not become an authoritative rule until someone with policy authority confirms it, and what gets mined at all has to run through the same permission, minimization, and provenance constraints that already govern this company's other regulated data. The transaction layer of the ontology is the durable, validated distillate of that stream, fed back up into the enterprise ontology below it. The ELI5 version of the context graph is here.

Agent transcripts, still unresolved. The human-to-agent half is where I am still working things out. The human-to-human side we at least know how to mine; a resolved thread has a shape. Agent transcripts are newer and noisier, and I do not yet have a clean rule for how much of a Claude Code session is durable knowledge and how much is one analyst thinking on a Tuesday. It is clearly signal. I am less sure how you separate it at volume, and I would rather say so than pretend the capture problem is solved.

The rule to build against. Capture the reasoning behind the outcome. For the payer, the overturned denial is a signal the auth system already hands you. The knowledge worth keeping is why it was overturned: the medical director's explanation in the thread, the definition that got settled on the call. Skip that and the ontology is accurate on go-live and drifting by the end of the quarter, which is exactlywhat payment-integrity teams already live with as configuration drift. The fastest-moving layer of your knowledge is the one currently sitting in chat, unread.

What does a grounded ontology let you check?

A mined triple is homeless until it's grounded to a domain concept. Vocabulary's Grounding entry covers what that means and what it costs in full, including the exact state a fact sits in when nothing claims it. The short version, and the only piece that matters here: grounding is what makes a fact checkable instead of merely well-formed, and a request built on an ungrounded fact is syntactically fine and means nothing the system can use.

A grounded, three-layer structure lets the payer do things a pile of retrieved text cannot:

• Detect a gap where a policy has no matching configuration.
• Catch a conflict where two documents disagree.
• Trace a decision back to the exact clause it came from, in the kind of trail a CMS or state regulator could actually follow.

That trail is only as strong as the source it was built from, which is the entire argument for keeping Layers 1 and 2 grounded in the first place.

Back to the semaglutide request one last time, because it makes the payoff concrete. The benefit configuration in the auth platform, config v3.7 (last updated 2026-06-15), is set to auto-approve semaglutide requests on file for this commercial-PPO line of business. Medical Policy MP-2201 was updated to v4.2 on 2026-09-01, adding the step-therapy criterion the request never documented, and the configuration was never updated to match. That is configuration drift: the written policy moved, the encoded rule didn't, and nobody catches it until something reads both documents at once. The grounded structure catches the conflict between config v3.7 and MP-2201 v4.2, surfaces the two clauses side by side, flags the exact criterion in dispute, and keeps both sources traceable. Nobody re-read every policy against every config line. The structure did.

Notice what had to be true for any of that to work:

• Someone grounded the drug correctly in the first place.
• Someone confirmed MP-2201 v4.2's step-therapy criterion actually applies to this commercial-PPO line of business, not just the inpatient one.
• Someone captured the medical director's ruling from the thread and fed it back into the policy layer.

The structure caught the drift because the structure had been kept true. Strip the human validation out and you get the same confident output with none of the trust, which is the precise failure that putting AI on prior authorization was supposed to end.

This is also the difference between a thin and a rich semantic layer, a term Vocabulary covers in full, plus a diagnostic checklist for spotting which one you're actually being sold. A thin semantic layer answers "what's our denial rate for this drug class this quarter?" by mapping "denial rate" to a column and handing back a number: 14%. Useful, and that's all it does. Ask it "was this specific denial defensible?" instead, and it has nothing: no policy version, no config version, no clause to point to. The grounded structure above is what a rich semantic layer actually gets you: not a bigger number, a clause it can hand back and defend.

What work can't a machine do when building an ontology?

What can a machine generate, and what can only a human validate?

Everything above splits along one line. A machine can generate all of it: select the code sets, mine the policies into a candidate taxonomy, pull triples from the conversation stream overnight. Generation is automatable and getting cheaper by the month. Validation still needs a person: someone has to read what the machine proposed and say yes, this matches the policy, or no, this "medically necessary" got encoded against the wrong line of business.

Is this the same as human-in-the-loop?

People will call this human-in-the-loop, but that term describes something else. Human-in-the-loop is a runtime idea, a reviewer glancing at an agent's live output and clicking approve, and at throughput speed that reviewer usually becomes a rubber stamp. What I am describing happens before anything ships. An expert reads a machine-proposed benefit structure and catches that "medically necessary" was encoded with the commercial definition where the Medicaid line needed its own. A clinician confirms a mined drug-diagnosis edge before it is trusted in a coded field. The machine proposes the edge. The clinician owns the yes. That is build-time knowledge curation, and it is skilled, specific work that no model on the roadmap replaces.

Do you need to hire an ontologist?

This work has a name and a field behind it. Ontologists and knowledge managers have done exactly this for decades: deciding what a concept means, how it relates to the rest, and whether an encoded rule is faithful to the source it came from. Knowledge management is the closest thing to a professional home for the validation-and-curation step, and the people who are good at it are very good.

Mike Dillinger draws the same line from the other side. Building a knowledge graph, he argues, is fundamentally a domain-modeling activity: the question is how your organization thinks about the domain it operates in, which entities and relations and events it treats as important. It stalls, in his experience, because it defaults to engineers, who are trained to model data, when it needs the domain experts who know what the concepts actually mean. That is why his team at LinkedIn was deliberately not all engineers, and it is the same reason the payer's answer is not to go hire a specialist.

Most enterprises will never hire an ontologist. They are rare, expensive, and awkward to place on an org chart, and a fast-growing payer is not about to open that req mid-build. You mostly do not have to. Your medical policy lead can tell you whether "medically necessary" is encoded right for the Medicaid line. Curating and validating the knowledge layer belongs to the domain experts you already employ: the machine proposes the structure, and they are the ones who can stand behind it. That judgment is not something you can buy off a shelf or generate overnight.

Why does ownership stall the build?

All of which turns the build into a question of ownership. The ontology cuts across roles that each hold a piece and none hold the whole. The policy team knows what the rules should say and is underwater. The analysts who configure the system own how it runs; whether it still matches the written policy is nobody's job. So the question that actually decides correctness, does the encoded rule still match the current policy, sits with no one, and the domain experts who could answer it are never given the structured time to. That unowned question, more than the modeling or the tooling, is where the timeline slips.

Often the better move is to bring in someone who has run this curation process before, someone who stands up the loop that routes your domain experts' judgment into the ontology rather than replacing them. The same unowned question comes back at run time when the configuration drifts, and again when you ask whether to build at all. One human problem, wearing three hats.

What's the step-by-step checklist for building an enterprise ontology?

If you take one thing back to your own team, take this. The sequence below is the build, layer by layer, with the validation gate each layer turns on. The gates carry the whole build. They are the difference between an ontology and a fast way to be wrong.

Everything above the gates, a machine can do and increasingly does. Every gate is a person. That is the shape of the whole build.

Why is human validation the hardest part of building an enterprise ontology?

The three-layer model is clean, and I think it is right, and it is also the easy half. Selecting a code set is a solved problem. Generating a candidate taxonomy from policy PDFs is close to solved, and capturing the conversation stream is an engineering problem with a clear shape, even the messy agent-transcript part of it. The hard part, unlikely to change no matter how good the models get, is the person who reads what all that machinery proposed and stands behind the yes.

So the domain ontology you select, the enterprise ontology you build, the transaction layer you capture: three layers, three methods. Each one is only ever as true as the human keeping it true. Build the layers and skip that, and what you have built is a very fast way to be wrong with a citation attached. That is the part worth remembering once the checklist above is done.