Most enterprise ontology projects stall before production, not because the modeling is wrong but because the scope is. Teams try to model an entire domain end to end before proving value anywhere, a pattern Pfizer (“too much to bite” for an entire supply chain at once) and Cohere Health (“boiling the ocean”) both describe. Forrester’s Noel Yuhanna makes a parallel case for semantics before intelligence.
The working alternative: scope to 3 to 5 priority domains, start with competency questions instead of a blank whiteboard, and bootstrap the first draft from metadata you already have. Formal OWL and RDF modeling still matters for regulated domains; this guide covers the pragmatic path first.
This is the pattern behind what Atlan calls an Active Ontology: a domain-by-domain model that compounds from context you already govern.
| Field | Value |
|---|---|
| Time to first domain live | Weeks with a scoped, one-domain rollout; months when the build starts enterprise-wide |
| Difficulty | Intermediate to advanced (needs lineage, SQL, and BI-semantic access, plus domain-expert time) |
| Prerequisites | Reasonable glossary, ownership, and description coverage; a named domain owner; draft competency questions |
| Tools referenced | Protege, TypeDB, LinkML, OntoGPT (formal and practitioner tooling); Atlan’s Orion for a bootstrapped approach |
Why design an ontology for AI?
Permalink to “Why design an ontology for AI?”A knowledge graph without an ontology can connect “Customer” to a dozen tables, but cannot tell an agent whether “Customer” means a lead or a purchaser. That ambiguity causes agents to fabricate relationships, a failure mode practitioners describe in a widely-discussed r/AI_Agents thread.
An ontology resolves that ambiguity: it defines what the entities in your graph mean and what rules govern their relationships, giving agents an explainable reasoning structure instead of flat vector similarity. The New Stack describes the Context Layer as the unification of disparate schemas into a single, governed ontology.
This guide is for teams that already have, or are building, a knowledge graph, and hit errors from ambiguous terms. For the definition, see what is ontology in AI or the ontology 101 explainer; for how it differs from a semantic layer, a knowledge graph, or a context graph.
What do you need before designing an AI ontology?
Permalink to “What do you need before designing an AI ontology?”Ontology work succeeds fastest on domains with basic metadata hygiene already in place.
Organizational:
- A named domain owner with authority to sign off
- One priority domain selected, not the whole data estate
- Executive tolerance for a domain-by-domain rollout, not a big-bang launch
Technical:
- Reasonable glossary, ownership, and description coverage on the target domain
- Access to column-level lineage, SQL, and semantic layer logic
- A graph or relational store. A dedicated graph database helps but is not mandatory at first
Skipping this gate causes the noisiest drafts in Step 3: thin glossary and ownership coverage becomes ambiguous entity definitions, the same foundation-before-the-next-layer problem that shows up everywhere in enterprise AI.
The CIO's Guide to Context Graphs
A practical breakdown of how CIOs are scoping and sequencing context graph and ontology work in 2026, before it turns into a stalled, enterprise-wide project.
Get the CIO Guide
A 5-step ontology design control plane. Source: Atlan.
Step 1: Scope your ontology with competency questions
Permalink to “Step 1: Scope your ontology with competency questions”What you’ll accomplish: name 3 to 5 priority domains and the concrete questions the ontology must answer for the first one, before any modeling starts. Time: 1 to 2 weeks.
This step is the direct antidote to boiling the ocean. Verizon built an ontology agent “very specific to creating an ontology for the broken promise use case,” a separate agent per use case rather than one universal model.
How to do it:
- Pick one domain, not the enterprise. Resist the instinct to draw the whole data estate before naming a single entity.
- Write 5 to 10 competency questions for that domain, for example “which customers hold an active policy and filed a claim in the last 90 days,” borrowing Enterprise Knowledge’s method.
- Resist over-specializing. Natalya Noy, co-author of Stanford’s “Ontology Development 101”: “you do not need to specialize… more than you need for your application.”
Common mistake: starting with an enterprise-wide entity-relationship diagram instead of one domain’s competency questions.
Step 2: Choose your layered ontology model
Permalink to “Step 2: Choose your layered ontology model”What you’ll accomplish: pick the layered structure your ontology will use so every future domain slots into the same architecture. Time: a few days.
Without a shared layer structure, each new domain ontology is incompatible with the last, and you rebuild the wheel every time you add one. The ontology-first AI architecture view shows how this layered model fits the broader stack once more than one domain is live.
Define the five layers practitioners converge on, per HiveMQ and Getgalaxy’s semantic-backbone sequence:
| Layer | What it defines | Example |
|---|---|---|
| Foundational | Top-level categories | Entity, Event, Agent |
| Domain | Industry-specific concepts | Policy, Claim, Shipment |
| Task | What a query needs to resolve | “Does this claim reference an active policy?” |
| Constraint | Business rules | A Claim must reference an active Policy |
| Instance | The actual data records | Policy #48213, Claim #90142 |
Common mistake: conflating domain concepts with instance data instead of keeping layers distinct, so the model can scale to a second domain without a rewrite.
The 5-layer ontology stack. Source: Atlan.
Step 3: Bootstrap your first draft from existing metadata signals
Permalink to “Step 3: Bootstrap your first draft from existing metadata signals”What you’ll accomplish: generate a first-draft ontology from signals you already have, instead of a blank-page exercise. Time: 1 to 3 weeks.
This is the most-asked implementation question behind this page: what feeds the ontology, versus what a human still provides? Most competitor content assumes full manual modeling or a proprietary pipeline. Getgalaxy’s ingest, map, materialize, expose sequence is one of the few public accounts naming the actual inputs.
How to do it:
- Harvest from what you already govern: column-level lineage, SQL joins and filters, BI semantic-layer logic, and glossary terms.
- Treat entities and relationships as a compounding output: better lineage produces better descriptions, better metrics, and a better draft, pragmatic and additive, not architected upfront.
- Check the readiness gate first; thin glossary coverage produces noisier drafts.
Common mistake: assuming an ontology agent needs zero human input. Customer-owned conceptual models are legitimate to influence, not replace, the bootstrapped draft.
AI Agent Context Readiness Checklist
A working checklist for the metadata hygiene an ontology bootstrap actually needs: glossary coverage, ownership, lineage, and descriptions.
Get the ChecklistStep 4: Model core entities, relationships, and constraints
Permalink to “Step 4: Model core entities, relationships, and constraints”What you’ll accomplish: turn the bootstrapped draft into a reviewed entity-relationship model with explicit business rules. Time: 2 to 4 weeks, with review.
Reverse-engineering an ontology purely from database tables is a documented limitation: table structure misses the reasoning a domain expert applies, the same limitation that shows up when teams skip a proper knowledge graph build.
How to do it:
- For each competency question from Step 1, define the entities, relationships, and any constraint that governs them.
- Name three things every ontology needs to nail, per Hiflylabs’ framing: vocabulary, relationships, and immutable rules.
- Route the draft through the named domain owner for human-in-the-loop review, the same discipline a well-run AI agent harness applies to every agent output.
Common mistake: shipping the auto-bootstrapped draft unreviewed instead of treating it as editable, not final.
Step 5: Validate, get sign-off, and expand to the next domain
Permalink to “Step 5: Validate, get sign-off, and expand to the next domain”What you’ll accomplish: confirm the domain ontology works against real queries, get it signed off, then repeat for the next priority domain. Time: ongoing.
Enterprises across insurance, financial services, and healthcare independently describe the same pattern: prove value in one domain before expanding. As one customer put it, it is “super easy to try and boil the ocean,” so the team focuses on one business unit first.
How to do it:
- Re-run every competency question from Step 1 against production data.
- Get the domain owner’s sign-off.
- Log any constraint fix, then repeat Steps 1 through 4 for the next domain, letting domain #1’s real usage set its scope.
Common mistake: moving to enterprise-wide scale before one domain is proven.
What goes wrong when you design an AI ontology top-down?
Permalink to “What goes wrong when you design an AI ontology top-down?”Most ontology failures are scoping failures, not modeling failures.
Boiling the ocean: teams try to model an entire domain, or supply chain, before proving value anywhere. One life-sciences team put it plainly: the entire supply chain at once is too much to take on at the start. Avoid it by scoping to one domain and 5 to 10 competency questions first.
Starting from architecture, not a problem: teams draw the ontology diagram before naming the decision it needs to support. T-Systems’ framing is the antidote: ontology work should be use-case driven, not architected upfront.
Assuming table structure is enough: reverse-engineering entities purely from database schemas misses the reasoning a domain expert applies. Pair automated bootstrapping (Step 3) with human review (Step 4).
Skipping the readiness gate: teams start where the glossary is incomplete, and the ontology inherits that ambiguity. Check metadata hygiene before Step 1, the same gap that shows up when teams skip straight to agent deployment without an enterprise context layer underneath it.
An ontology that starts with one domain’s real questions ships in weeks; one that starts with a whole-enterprise diagram rarely ships at all.
What are the best practices for ontology design?
Permalink to “What are the best practices for ontology design?”Discipline about scope, inputs, and review separates ontology projects that ship, not modeling skill. The exception: reserve formal OWL and RDF modeling, per Protege and the W3C OWL 2 Primer, for regulated domains, for example biomedical ontologies built with OntoGPT.
Tools differ by philosophy more than feature list, and the knowledge graph layer these sit next to has its own comparison page.
| Tool | Modeling philosophy | Best for |
|---|---|---|
| TypeDB | Strongly-typed conceptual schema | Preventing agents from hallucinating relationships |
| Protege | OWL 2 formal editor | Regulated, compliance-heavy domains |
| OntoGPT | LLM-guided extraction (SPIRES) | Bootstrapping from unstructured text |
| LinkML | YAML-first, compiles to RDF and OWL | The practical middle ground |
None of these tools replace Step 1’s scoping discipline; they speed up Step 3 and Step 4 once a domain is properly scoped.
How does Atlan streamline ontology design?
Permalink to “How does Atlan streamline ontology design?”Ontology work today is usually a blank-page modeling sprint, disconnected from all the metadata already sitting in lineage systems, SQL, BI semantic layers, and glossaries. That disconnect is why it stalls.
Orion, Atlan’s Ontologist Context Agent, treats ontology as a third-order output of the context flywheel: lineage, SQL, human annotations, and runtime agent traces feed first-order outputs (descriptions, filters), which produce second-order metrics, which bootstrap third-order entities, relationships, and an Active Ontology, scoped domain by domain. The result is human-editable, not a black box, powered by Atlan’s Enterprise Data Graph.
Atlan is candid this capability is still maturing: its ontology model is pragmatic and query-portable, not W3C, OWL, or RDF-compliant. Teams with regulated needs should pair it with dedicated tooling like Protege or LinkML.
See how Orion and Atlan’s Context Agents work →
Real stories from real customers: Ontology and context in production
Permalink to “Real stories from real customers: Ontology and context in production”"We're excited to build the future of AI governance with Atlan. All of the work that we did to get to a shared language at Workday can be leveraged by AI via Atlan's MCP server, as part of Atlan's AI Labs, we're co-building the semantic layer that AI needs with new constructs, like context products."
Joe DosSantos, VP of Enterprise Data & Analytics, Workday
"Atlan is much more than a catalog of catalogs. It's more of a context operating system. Atlan enabled us to easily activate metadata for everything from discovery in the marketplace to AI governance to data quality to an MCP server delivering context to AI models."
Sridher Arumugham, Chief Data & Analytics Officer, DigiKey
Atlan in Action: Live Context Layer Demos
See how Atlan's Context Agents, including Orion, bootstrap and maintain an ontology domain by domain.
Watch the Live DemoWhy ontology is the layer every control-plane decision depends on
Permalink to “Why ontology is the layer every control-plane decision depends on”Workday’s and DigiKey’s stories point at the pattern this guide has built toward: the entities and relationships an ontology defines are not a data-team artifact, they are what everything above the context layer depends on. A guardrail cannot judge a term it does not understand. A model council cannot govern what it cannot see. Reranking cannot fix retrieval if the underlying graph never disambiguated meaning.
That is why this guide’s discipline, scope with competency questions, bootstrap from what you govern, review with a human, expand one domain at a time, matters beyond the ontology itself. As governed domains grow, ontology work intersects with the same governance questions a model council already asks about models: who approves changes, and what counts as done.
Measure success by whether competency questions resolve against production data, not by entity count. Once domain #1 is signed off, repeat for the next priority domain, letting real usage set the pace.
FAQs about ontology design for AI
Permalink to “FAQs about ontology design for AI”1. What is the difference between an ontology and a knowledge graph in AI?
Permalink to “1. What is the difference between an ontology and a knowledge graph in AI?”A knowledge graph stores entities and connections. An ontology defines what they mean and which rules govern them. The graph is the substrate; the ontology is the semantic contract on top, which lets an agent resolve ambiguity instead of just traversing connections.
2. What are the 5 layers of an ontology stack?
Permalink to “2. What are the 5 layers of an ontology stack?”Foundational (top-level categories like Entity, Event, Agent), domain (concepts like Policy or Claim), task (what a query needs to resolve), constraint (rules, like a Claim must reference an active Policy), and instance (the actual data records). Keeping these distinct lets the model scale without a rewrite.
3. How do you avoid “boiling the ocean” when designing an ontology?
Permalink to “3. How do you avoid “boiling the ocean” when designing an ontology?”Scope to 3 to 5 priority domains instead of the whole data estate, write 5 to 10 competency questions per domain first, and expand one domain at a time based on proven value.
4. What is a “competency question” in ontology design?
Permalink to “4. What is a “competency question” in ontology design?”A concrete question the ontology must answer, for example “which customers hold an active policy and filed a claim in the last 90 days,” written before naming a single entity.
5. Do I need a graph database to build an AI ontology?
Permalink to “5. Do I need a graph database to build an AI ontology?”It helps but is not mandatory for a first domain. A relational store can hold entities and relationships early on; a graph database becomes more valuable as relationship complexity grows.
6. What is the best tool for ontology modeling for LLMs?
Permalink to “6. What is the best tool for ontology modeling for LLMs?”It depends on philosophy. Protege and OWL suit formal, regulated modeling. LinkML is a lighter YAML-first middle ground. OntoGPT handles LLM-assisted extraction from unstructured text.
Sources
Permalink to “Sources”- Build Meaning Before Machines. Forrester Research, 2026. https://www.forrester.com/blogs/build-meaning-before-machines-why-semantics-ontologies-and-knowledge-graphs-matter-for-agentic-ai/
- Ontology Development 101. Stanford Center for Biomedical Informatics Research. https://protege.stanford.edu/publications/ontology_development/ontology101.pdf
- Keys to Successful Ontology Design. Enterprise Knowledge, 2026. https://enterprise-knowledge.com/keys-to-successful-ontology-design/
- Pragmatic Ontology for AI Agents. T-Systems, 2026. https://www.t-systems.com/de/en/insights/newsroom/expert-blogs/pragmatic-ontology-for-ai-agents-1163094
- Building Ontology-Driven Intelligence for Industrial AI Agents. HiveMQ, 2026. https://www.hivemq.com/resources/building-ontology-driven-intelligence-for-industrial-ai-agents/
- Enterprise Ontology for AI Agents. Getgalaxy, 2025. https://www.getgalaxy.io/articles/enterprise-ontology-ai-semantic-backbone
- Operationalizing AI Ontologies. Hiflylabs, 2025. https://hiflylabs.com/blog/2025/6/11/ai-ontologies-in-practice
- OWL 2 Web Ontology Language Primer. W3C. https://www.w3.org/TR/owl2-primer/
- What It Takes To Scale AI Agents in Production. The New Stack. https://thenewstack.io/what-it-takes-to-scale-ai-agents-in-production/
- Ontology Is the Missing Piece From Your Agents. r/AI_Agents. https://www.reddit.com/r/AI_Agents/comments/1sfrfwe/ontology_is_the_missing_piece_from_your_agents/
