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 three-layer structure below 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.

Does building this structure make the AI understand prior authorization?

Before any architecture, one bound on what the next three layers can actually promise. Correct execution is what they're actually building toward: a structure explicit enough that acting on it correctly substitutes for understanding, for every case it covers, and fails visibly the moment a case arrives it doesn't. Machine-readable and machine-interpretable aren't the same claim either: the machine only ever applies what a person already declared. That's what the three layers below are for. Who gets to do the declaring, Layer 2's whole subject, is where the real weight sits.

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 "sparse versus dense" actually means: how many relation types describe a concept. A sparse graph is one starved of relation types, every node thinly defined, nothing to reason across. A dense graph describes its concepts through many informativerelations. Density pays off only when the added relations are informative. Quantity alone does nothing, 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 a policy PDF, say "step-therapy required before semaglutide is covered," 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. The system of record only holds the outcome, that a request was approved or denied. The reasoning behind that outcome, and the updated understanding that should change the next decision, lives 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.

Some prior-auth systems already record a reason code or a reviewer's note alongside the outcome; most of the reasoning behind it still happens somewhere the system never sees.

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 taxonomy 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 is set to auto-approve the request. The current medical policy requires step-therapy criteria the request never documented, because the policy was updated and the configuration was not. That is configuration drift, and nobody catches it until something reads both documents at once. The grounded structure catches the conflict between the encoded rule and the written policy, surfaces the two clauses side by side, 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 that this "medical necessity" resolved to the Medicaid definition for this request.
• 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.

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. The modeling discipline an ontologist brings is increasingly carried by the tooling. The judgment about what is actually true in this business, only the domain expert has, and that is the part you cannot 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.

The usual answer is "form a committee," and a team standing up AI on prior authorization will not convene one mid-build. 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 difference between a thin and a rich semantic layer?

You'll hear "semantic layer" from every vendor now; Vocabulary covers the thin-versus-rich split in full, plus a diagnostic checklist for spotting which one you're actually being sold. Here's what the difference looks like on our payer. Ask a thin semantic layer "what's our denial rate for this drug class this quarter?" and it maps "denial rate" to a column, runs the query, and hands you a number: 14%. Useful, and that's all it does. Ask a rich one "was this specific denial defensible?" and it has to reason across the medical policy and the state mandate together, then hand back the clause that justifies the answer, something a count alone can't do. Same vendor pitch, two different capabilities. The move is to point past the thin version, at the questions it cannot answer.

Building the ontology takes three methods; a knowledge graph is a set of facts

First, building the ontology takes three different methods: select, generate, capture. Each layer needs its own tool and its own owner. The opening question on most projects is "how do we build the ontology for prior authorization," and it smuggles in both assumptions at once. The standard advice that follows (start narrow, gather your subject-matter experts, write your competency questions) answers a real question, just a different one: it tells you how much to scope. It says almost nothing about how the thing gets made, or who has to stand behind it once it is, which is the whole question here.

Second, a knowledge graph and a graph database are two different things. Vocabulary covers the full market, labeled property graph versus RDF triplestore, and traces the collapse to its commercial cause. The short version: the graph is the set of facts. The database is where you happen to keep them. Hold those two apart and a lot of vendor conversations get shorter.

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, the part no future model solves either, 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 owning before you write a single triple.

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.