Your business data is the moat.
An Ontology LLM is how you use it.
Every competitor can buy the same models, the same cloud, and the same tools. None of them can buy how your business defines a customer, prices a trade, releases a batch, or restores a feeder. This page is a practical guide to encoding that meaning once, in a governed semantic layer you own, so agents work from it instead of guessing.
Why is everyone talking about ontology now?
Because agents broke the old shortcut. A human analyst could look at a badly named column and guess. An agent cannot. When you put a model in front of your warehouse, every undocumented assumption in your business becomes a wrong answer delivered with confidence.
Context beats model choice
A paired benchmark in April 2026 ran 100 business questions against one retail warehouse using three frontier models, with and without a 4 KB semantic document. Accuracy moved from 45 to 50 percent up to 68 percent. The models were statistically indistinguishable from each other. The semantic document explained almost all of the variance. One dataset and one hand-written document, so treat it as promising evidence rather than a general enterprise result. [1]
The semantic layer moved to the critical path
Forrester's June 2026 research argues that shared metrics, definitions, calculations, and access policies are the missing layer in most AI architectures. Per vendor summaries of Gartner research, Gartner expects most enterprise agent systems to use graph-based context by 2028, and predicts that by 2030 half of organizations will use agents to interpret governance policy and enforce it as machine-verifiable contracts. Both are behind subscriptions, so read the originals before quoting them. [2] [3] [4]
The stack is converging on graphs
Through 2026 the platform vendors have been wiring graph reasoning directly into the warehouse and lakehouse, including zero-copy virtual graphs over Snowflake and GraphRAG patterns on Databricks. Palantir shipped an Ontology MCP interface in January 2026 so outside agents can read Foundry objects. The direction of travel is clear. [15] [9]
So what do we mean by "Ontology LLM"?
It is shorthand for a system, not for a new foundation model you train. Nobody needs to pre-train anything. The parts below are separate, they are owned by different people, and keeping them separate is what makes the whole thing safe to run.
| Part | What it does | Who owns it |
|---|---|---|
| Ontology | Defines classes, relationships, meanings, constraints, and allowed states | Knowledge engineer with domain owners |
| Knowledge graph | Fills that ontology with your actual entities and facts | Data platform team |
| Semantic and metrics layer | Defines calculations, dimensions, approved joins, and analytical behavior | Analytics engineering |
| Policy and action layer | Decides who or what may do something, under which conditions | Risk, security, and compliance |
| LLM | Reads the request, plans tool calls, synthesizes results, explains them | AI engineering. Replaceable by design |
| Agent runtime | Executes governed queries and actions, and records what happened | Platform engineering |
The definition worth keeping
An ontology-grounded agent platform is an enterprise semantic system where the LLM interprets requests, but definitions, relationships, policies, evidence, and actions are retrieved from governed, versioned sources and enforced outside the model.
That distinction matters commercially. Models will keep changing every few months. The governed semantic system is the asset that holds its value, so build it to outlive whichever model you are using today.
We already bought a data catalog. Why is that not enough?
A catalog answers "what tables exist." An agent needs to know "what is true about this business and what am I allowed to do." Those are different problems, and the second one was never in scope for traditional metadata tooling.
Modern catalogs do more than schemas. Many carry glossaries, lineage, quality scores, policy tags, and usage analytics. The gap is a different one. A catalog describes the estate. It does not give you an executable model of the business, and that is what an agent has to work from.
What is usually missing:
- Semantics. What a "policy in force" means, and which of the seven versions is authoritative.
- Relationships. That a claim links to a policy, an adjuster, a reserve, and a reinsurance treaty.
- Behavior. Which job writes this table, on what schedule, and what breaks downstream when it fails.
- Actions. What an agent is allowed to change, under whose approval, with what audit trail.
- Constraints. The rules that make an answer legal, not just plausible.
Because they depend on volunteer curation. If humans have to tag columns by hand, coverage decays within months, and once users stop trusting the entries they stop coming back. Research on failed governance programs points to the same three causes over and over: weak sponsorship, a compliance-only framing, and stale content with no named owner at go-live. [7]
The fix is to make metadata a by-product of the systems that already change. Parse the code, read the orchestration graph, watch the query logs. Then send humans only to the places where machines are uncertain.
It counts, and it is the best starting asset most organizations have. Two limits though. BI semantic models usually cover only the reporting subset of the estate, and they describe measurement rather than operations. They can tell an agent how revenue is computed. They cannot tell it that this counterparty is on a restricted list, or that this batch is on hold pending a deviation.
The practical move is to lift the BI semantic model up into the ontology as one contributing source, then extend it with entities, relationships, and permitted actions.
That shortcut is the most common cause of failed deployments. Without ownership, a definition has no tie-breaker, and the ontology inherits every unresolved argument in the business. [7]
You do not need enterprise-wide governance before you start. You need an owner per domain, a decision path when two owners disagree, and a rule that undocumented terms cannot be promoted into the production ontology.
- Rework. Every AI use case rebuilds the same joins, filters, and definitions from scratch.
- Slow onboarding. New engineers spend their first quarter learning tribal rules that nobody wrote down.
- Failed pilots. Assistants demo well on three curated tables and fall over on the fourth.
- Audit exposure. No traceable path from a reported number back to source and rule.
- Metric drift. Two dashboards, two answers, one executive losing confidence in both. [8]
The short version
Traditional metadata describes where data sits. An ontology describes how the business works. Agents need the second one, and no vendor can extract it from your systems without your people.
Do we need to buy a platform for this?
Two years ago Palantir was close to the only vendor selling an operational ontology, which is why it defined the category. That is no longer the picture. Through 2026 the hyperscalers, the knowledge graph vendors, and the warehouse platforms have all shipped something in this space. They are not equivalent, so the useful question is which category matches what you are trying to do.
Operational ontology platforms
Palantir Foundry. In industrial settings, Cognite Data Fusion plays a similar role.
Objects, links, actions, functions, security, and operational write-back in one product. The distinguishing feature is that decisions are executed inside the platform, not handed to a separate application tier. [26]
Best fit: agents and users who have to act on the answer, in environments where the workflow and the data need to sit together.
Hyperscaler semantic layers
Microsoft Fabric IQ Ontology, currently in preview. Google announced Knowledge Catalog and an Enterprise Knowledge Graph at Cloud Next '26.
Fabric IQ defines entity types, properties, and relationships, binds them to OneLake data, builds a queryable instance graph with source lineage, and adds natural language querying over the ontology so Fabric agents share one business vocabulary. [32]
Best fit: organizations already standardized on one cloud, who want the semantic layer next to the data they have.
Knowledge graph and ontology platforms
Stardog, Graphwise (Ontotext), Neo4j, Timbr, TopQuadrant.
The deepest modeling capability, built on open standards such as RDF, OWL, and SHACL, with virtual graphs, reasoning, and inference. Portability is the strength here, since the model is expressed in formats no single vendor controls. [33] [34]
Best fit: complex domains and regulated industries. You build the application and action layer yourself.
Warehouse-native semantic layers
Snowflake Semantic Views, Databricks Metric Views, dbt, Cube, AtScale.
These govern calculations well and reached general availability during 2026, which makes them the fastest starting point most organizations already own. They model measurement rather than entities, relationships, and permitted actions, so they cover part of the ground. [35] [36]
Best fit: a first domain, and a genuine foundation to build the graph on top of later.
| Category | What you get | What you still build | Portability |
|---|---|---|---|
| Operational ontology platform | Objects, links, actions, write-back, security, applications | Domain modeling and the business definitions | Lower. Logic lives inside the product |
| Hyperscaler semantic layer | Entity types, bindings, instance graph, agent grounding | Actions, approvals, and anything outside that cloud | Medium. Tied to the cloud, not to a separate vendor |
| Knowledge graph platform | Standards-based modeling, reasoning, validation, federation | Applications, actions, and the serving layer | Higher. Open formats you can move |
| Warehouse-native semantic layer | Governed metrics, dimensions, approved joins | Entities, relationships, policy, and actions | Medium to high, depending on the tool |
| Assemble your own | Exactly what you choose | All of it, including the operational work | Highest, and the slowest to first value |
What should we ask before we commit?
These apply to every option on this page, including assembling your own. None of them are gotchas. They are the questions that decide what the next five years cost.
1. What does year three look like?
Ask for the cost curve, not the first-year number. Consumption grows with adoption, and the platforms that work get used more. Model the success case, not the pilot.
2. Can we export the model?
Ask specifically: can the entity definitions, mappings, and metric logic come out in a documented open format? If the answer needs a services engagement, price that as part of the deal.
3. Who can staff this?
Platform-specific skills are thinner and cost more than general data modeling skills. Check what your team can learn, what you must hire, and what stays dependent on the vendor.
4. What happens when the model is wrong?
Early modeling decisions compound. Identifier choices in particular are the most commonly cited reason an ontology gets rebuilt. Ask what changing one costs once the model is live. [9]
5. Does it play with other agents?
Most estates will run agents from several vendors. Check how the ontology is exposed, what an outside client can read or execute, and where authorization is enforced. [27] [30]
6. What is it not for?
Every platform in this category has a job it does poorly. Using an ontology layer as a general data engineering environment, for example, is expensive and awkward. Get the vendor to name the boundary. [9]
| Question | Buy a platform | Build your own Ontology LLM |
|---|---|---|
| First operational use case | 8 to 16 weeks with vendor engineers on site | 10 to 14 weeks for a scoped domain with a small internal team |
| Year-one cost shape | Large platform license plus embedded delivery services | Mostly people plus modest infrastructure and model spend |
| Who owns the semantics | Encoded in the vendor object model | Yours, in RDF/OWL, SHACL, dbt, or open graph formats |
| Exit cost | Higher. Business logic is embedded in the platform | Low to moderate. Definitions and graph are portable |
| Skills needed | Platform-specific, scarcer, premium priced | Data modeling, knowledge engineering, LLM engineering |
| Best fit | Compressed timelines, complex operational write-back, heavy classification requirements | Durable capability, multi-vendor agent strategy, cost control at scale |
Ranges reflect commonly reported implementation patterns rather than published vendor pricing. Validate against your own scope, data readiness, and negotiated terms.
What has to be in the knowledgebase?
More than a data dictionary. An agent that can only see tables will write plausible SQL against the wrong system. Nine governed domains cover it. The first four are what most teams expect. The last five are where programs usually come up short, and they are the ones agentic AI depends on most.
Business semantics
- Glossary terms, synonyms, acronyms, local labels
- Metrics, dimensions, calculations, approved variants
- Products, services, capabilities, customer journeys
- Business rules, decision tables, thresholds, exceptions
- Processes, controls, handoffs, SLAs
- Decision rights, ownership, escalation paths
Enterprise information
- Structured, semi-structured, and streaming data
- Contracts, policies, SOPs, manuals, research
- Tickets, case notes, CRM notes, meeting decisions
- Images, diagrams, recordings where they carry meaning
- External data, public ontologies, regulations, standards
Identity and reference
- Master and reference data, code sets, crosswalks
- Identifiers, aliases, match confidence, merge history
- Org units, people, roles, skills, delegated authority
- Product, geography, legal entity, account hierarchies
- Locations, geospatial topology, calendars, units of measure
Systems and events
- Applications, SaaS objects, services, API contracts
- Event schemas, topics, producers, consumers, ordering
- Data products with owners, consumers, SLOs, deprecation
- Environments, deployments, dependencies, versions
- Network zones, residency, and latency boundaries
Logic and AI assets
- Transformation logic, rule code, orchestration, config
- Analytical and ML models, features, training datasets
- Prompts, agent instructions, tool definitions, evaluations
- Model cards, risk tier, intended use, limitations, approvals
Actions
- Preconditions, postconditions, input and output schemas
- Side effects and which systems they touch
- Authorization and approval requirements
- Idempotency and transaction boundaries
- Rollback or compensation behavior
- Rate limits, cost limits, separation of duties, audit events
Governance and legal
- Classification, entitlements, row, object, and field limits
- Consent, purpose limitation, residency, retention, legal holds
- Regulatory obligations and jurisdiction
- Conflicts, information barriers, ethical constraints
- Policy precedence and exception handling
Provenance and time
- Source, extraction method, owner, approver
- Confidence and validation status
- Effective from and to, plus recorded-at timestamps
- Version and change history
- Freshness, completeness, accuracy, quality rules
- Lineage, usage, incidents, corrections, user feedback
Runtime telemetry and assurance
- Correlated traces for answers and, separately, for actions
- Evaluation runs, gold sets, and scores over time
- Policy decisions, approvals, and overrides
- Incidents, corrections, and user feedback
- Cost, latency, freshness, and availability
- Business outcomes attributed back to the decision
Two rules that save you later
Never put secrets in the ontology. Store a reference to the approved secret mechanism, plus ownership, classification, and the access procedure. Nothing else.
Make domain H a property of everything else. Provenance, effective dates, and confidence belong on every assertion that matters. Enterprise truth is rarely timeless, and it is rarely agreed by everyone at once. If your model cannot express "this was true as of March, according to finance, with medium confidence," it will mislead an agent eventually.
Planning assumption, not a finding
We plan these programs on the assumption that most of the technical inventory can be harvested automatically and the smaller remainder needs people. Measure the split in your own first domain rather than taking a number from a slide. Whatever the ratio turns out to be, the hand-modeled part is the business meaning, and that is the part competitors cannot copy. Spend your scarce human hours there.
What is an "Ontology LLM," in plain terms?
It is a language model that has been given your ontology as its working knowledge and is constrained to answer through it. Three things make it different from a generic assistant pointed at your warehouse: it knows your entities, it retrieves through the graph rather than guessing, and it is built to detect when required evidence is missing, then refuse or escalate instead of filling the gap.
Grounding, not just prompting
The ontology is retrieved at query time through graph traversal, so the model sees the exact entities, relationships, and metric definitions in play. That is the GraphRAG pattern, and it supplies context. Traceability is a separate job: capture the query plan, the source row identifiers, the metric version, and a provenance record. W3C PROV-O is a good vocabulary to start from. [21] [28]
Constrained generation
Prefer compiling a governed query over letting the model write arbitrary SQL. The model picks entities and metrics, then a deterministic compiler produces the query, so invalid joins and unapproved metrics never reach the warehouse. SHACL validates RDF graphs, so use it for model integrity and use separate checks for queries, answers, and actions. [20] [29]
Adaptation where it pays
Start with retrieval. Add lightweight fine-tuning only for the parts that repetition cannot fix: your naming conventions, your query dialect, your document formats. Most teams never need a full custom model, and the ones that do usually know why.
How do we build it, step by step?
Pick one decision, not one dataset
Choose a decision that a named executive already cares about and that crosses at least two systems. "Which suppliers put next quarter's launch at risk" beats "catalog the finance schema." Scope the ontology to what that decision needs.
Harvest everything machines can read
Point collectors at warehouses, repos, orchestrators, API gateways, event registries, and SaaS admin APIs. Parse SQL and transformation code to recover embedded business rules. Read query logs to find which joins people trust in practice.
Model the core concepts by hand
Take the 30 to 60 entities that carry the business and model them properly with domain owners. Reuse standards where they exist: FIBO in financial services, IDMP and OMOP in life sciences, CIM in utilities. Do not invent what a regulator already defined. [13] [18]
Wire the retrieval and the guardrails
Expose the ontology through a query service and a tool interface. Add graph traversal plus vector search over descriptions. Treat MCP as a connection standard, not your security layer: validate that tokens were issued for your server, never pass tokens through to downstream systems, and keep authorization in your own policy engine. Separate read tools from write tools, and make writes default deny, least privilege, and approval gated. Enforce policy at every point it can be checked, not only at the ontology layer. [30]
Instrument, evaluate, and assure the system
Build a gold set of 150 to 300 business questions with verified answers, and run it on every ontology change. Track accuracy, refusal rate on unanswerable questions, and citation validity. Pair that offline set with production monitoring, red teaming, incident handling, and rollback. The NIST Generative AI Profile is a useful frame for the lifecycle. [1] [12] [31]
Correlate the trace on day one. One request ID has to join the prompt, the concept mapping, the ontology version, the graph path, the retrieved evidence, the compiled query, the policy decision, the tool call, and the approval. Traces scattered across separate logging systems cannot be stitched together after an incident, and retrofitting correlation is far more expensive than designing it in.
Monitor the ontology itself, not just the answers. Coverage, unmapped fields, contradictory definitions, constraint violations, entity resolution confidence, and overdue owner reviews. This page argues the ontology keeps improving. Without these measures you cannot tell whether it is getting more complete or simply getting bigger. Section 06 lists what to capture.
Close the loop
Every corrected answer, resolved ambiguity, and new term becomes a proposed ontology change with an owner and a reviewer. The model gets better because the ontology gets better, and the ontology stays current because it is on the critical path of daily work.
One question, end to end
Take the question from Figure 1: "Who are our top five active customers by recognized revenue this quarter?" Here is what has to happen for that answer to be trustworthy. Nine steps, and only two of them involve the model.
"Active customer" is not a matter of opinion
It resolves to a governed definition with an owner, an effective date, and a version. If sales and finance hold different definitions, the ontology says which one applies here and why. The agent does not get a vote.
"Recognized revenue" maps to the approved calculation
Not gross bookings, not billed amount. The metric carries its accounting policy, its fiscal calendar, and the revision it was approved under.
One customer, three systems
The CRM account, the billing entity, and the legal entity are matched to one identifier, with match confidence and merge history attached. This is the step that quietly decides whether the whole answer is right.
Remove what this person may not see
Restricted regions, embargoed accounts, and barrier-protected relationships drop out before the query runs. The result set is shaped by policy, not filtered afterwards.
The semantic query becomes SQL deterministically
The model chose entities and a metric. A compiler turned that into the query. Nothing the model wrote goes to the warehouse unchecked. [20]
The result carries its own receipts
Source row identifiers, the query that ran, the metric version, the definition version, and the timestamps. This is where provenance vocabularies earn their place. [28]
The model writes the answer, and says what it excluded
Two accounts were ambiguous. One region was withheld by policy. One subsidiary was merged last week and the history is incomplete. Saying so is part of the answer.
"Create an account review for the top three" is a different request
That is a write. It needs an authorized action with preconditions, an approver, an idempotency key, a rollback path, and an audit event. Reading and acting are not the same permission.
A correction becomes a proposed ontology change
If finance says the definition was wrong, that goes into the ontology backlog with an owner and a reviewer. It does not become an undocumented note in a prompt that nobody can audit six months later.
What this shows
Grounding, enforcement, execution, and explanation are four different jobs. The model does interpretation and explanation. Everything that makes the answer defensible happens outside it. That is the reason this architecture survives a model upgrade.
How do we know it is working?
Two questions hide inside that one, and they need different evidence. "Is the answer right?" is an evaluation question. "Can you prove how we got it?" is an assurance question. Any system that changes enterprise state has to answer both, on demand, months later, to someone who was not in the room.
What observability means here
It is not logging the prompt and the response. It is being able to reconstruct which ontology version, which evidence, which graph path, which policy decision, which query, which tool call, which approval, and which source system change produced a given answer or action.
Agent and LLM
What the agent decided, and what it cost.
- Request and session ID
- Model, model version, prompt-template version
- The plan, and the tool-selection decisions behind it
- Tool inputs and outputs, with sensitive values redacted
- Token usage, latency, retries, failures, and cost
- The final answer, refusal, escalation, or action
- Human approval and override events
Retrieval and semantics
How meaning was resolved, and on what evidence.
- User terms mapped to ontology concepts
- Ambiguities found, and the alternative mappings considered
- Ontology and semantic model versions used
- Graph paths traversed
- Documents, facts, metrics, and policies retrieved
- Retrieval scores and coverage
- Missing or stale context
- The generated semantic query and the compiled SQL or SPARQL
- Source records supporting each material claim
This category is the whole argument. It is the difference between "the model cited a document" and "the system can prove how the answer was derived."
Policy and actions
For any agent that can change enterprise state.
- Identity of the person, the agent, and any delegated principal
- The requested action and the objects it affects
- The policy decision and the policy version applied
- Permissions and purpose of use evaluated
- The approval chain
- Preconditions and postconditions
- Idempotency key and transaction status
- Side effects in downstream systems
- Rollback or compensation result
Model the answer trace and the action audit trail separately. They have different readers, different retention periods, and different legal weight. Merging them means you either over-retain conversation logs or under-retain evidence a regulator will ask for.
Ontology health
The semantic foundation needs its own monitoring.
- Concept and source system coverage
- Unmapped fields and unresolved entities
- Contradictory definitions
- Orphaned nodes and invalid relationships
- SHACL or schema violations
- Stale definitions and overdue owner reviews
- Entity resolution precision and confidence
- Ontology changes, their downstream impact, and adoption
- Retrieval failures traced back to ontology gaps
Without these, "the ontology keeps improving" is a claim, not a fact. They are how you tell a foundation that is getting more complete from one that is just getting larger.
Outcome and quality
Answer accuracy alone will not tell you whether the system is safe or worth the money.
- Semantic resolution accuracy
- Retrieval recall and precision
- Query execution correctness
- Answer faithfulness and citation validity
- Unsupported claim rate
- Correct refusal and escalation rate
- Policy violation and unauthorized action rate
- Action success, rollback, and unintended side effect rate
- Latency, availability, freshness, and cost
- Human correction and override rate
- Business outcomes such as time saved or reconciliation avoided
Where teams get this wrong
They buy LLM observability, see prompts and responses in a dashboard, and call it done. That tooling covers category 1. The four categories that make an answer defensible sit in your own architecture, because only you know your ontology versions, your policy model, and your source systems.
Which path fits us? Three practical patterns.
The right choice depends on how much of your estate is already modeled, how regulated you are, and how much engineering capacity you can hold steady for two quarters. Pick a lane, then move up a lane when you have proof.
When to choose it
You have a modern warehouse or lakehouse, a decent dbt or BI semantic model, and one or two AI use cases waiting on definitions. You need a win this quarter.
Time to first value: 6 to 10 weeks.
Team: 3 to 5 people.
Tools
- Semantic modeling in dbt, Cube, Databricks Metric Views, or Snowflake semantic views
- Vector store already in your platform, no new database
- An MCP server exposing metrics and definitions to agents
- Evaluation harness in Python with a versioned gold question set
- Git for the model, CI for validation
Process and people
- Analytics engineer to formalize metrics and joins
- Domain SME two days a week, not one hour a month
- LLM engineer for retrieval, tools, and evaluation
- Product owner who owns the decision, not the dataset
- Weekly definition review. Disputes resolved in the room, in writing
Watch out for
Stopping here. A metrics layer answers measurement questions well and operational questions poorly. Plan the graph before the first request for "why did this happen" arrives.
When to choose it
Meaning is spread across many systems, several of which you will never migrate. You need cross-domain questions answered without a two-year consolidation program.
Time to first value: 10 to 16 weeks.
Team: 6 to 10 people.
Tools
- Graph store: Neo4j, Neptune, TigerGraph, or an RDF store such as GraphDB or Stardog
- Zero-copy or virtual graph over the warehouse where supported [15]
- Ontology authoring in Protege or a governed spreadsheet-to-OWL pipeline
- SHACL to validate the graph, plus entity resolution tooling
- GraphRAG orchestration and an MCP layer for agents
Process and people
- Knowledge engineer who can model and negotiate at the same time
- Data architect for source mapping and identity strategy
- MDM lead because entity resolution decides whether any of this works
- Domain councils per business area with a named tie-breaker
- Ontology change board meeting fortnightly with published decisions
Watch out for
Identity. If you cannot reliably say that customer 4471 in the CRM and party X9 in the risk system are the same entity, the graph will produce confident nonsense. Solve identity first.
When to choose it
Agents will take actions, not just answer questions. Regulators will ask how a decision was made. The ontology becomes a shared asset across many products.
Time to first value: 4 to 6 months.
Team: 12 to 25 people.
Tools
- Everything in option B, plus an action and workflow layer with write-back
- Policy engine for entitlements and purpose limitation, checked at source, query, tool, action, and output
- Model gateway with routing, caching, and cost controls
- Domain-adapted model where naming and dialect justify it
- Full observability: prompt, retrieval path, query, result, approval
Process and people
- Ontology product owner with a real backlog and budget
- Platform team of 5 to 8 running it as a product, not a project
- Risk and compliance embedded from week one, not consulted at the end
- Federated stewards in each domain with published SLAs
- Release train for ontology versions, with deprecation notices
Watch out for
Treating it as a platform build. If the ontology is not being used by a shipping product within 90 days, it will become documentation. Keep a live consumer attached at all times.
What does the team look like?
| Role | What they own | A | B | C |
|---|---|---|---|---|
| Product owner | The decision being improved and its business case | 1 | 1 | 1 to 2 |
| Knowledge engineer | Ontology design, standards reuse, constraints | 0 to 1 | 2 | 3 to 4 |
| Analytics engineer | Metrics, joins, transformation lineage | 2 | 2 to 3 | 4 to 6 |
| LLM engineer | Retrieval, tools, evaluation, guardrails | 1 | 2 | 3 to 5 |
| Platform engineer | Graph, pipelines, observability, cost | 0 to 1 | 1 to 2 | 3 to 4 |
| Domain stewards | Definitions and tie-breaking in their area | 2 | 4 to 6 | 8 or more |
| Risk and compliance | Entitlements, auditability, model governance | Advisory | 0.5 | 1 to 2 |
Full-time equivalents for the first two quarters. Domain stewards are part-time by design and should stay in the business.
Where does this change the numbers?
The pattern repeats across industries. Somebody spends weeks assembling context that already exists in the estate, then makes a decision under time pressure with partial information. The ontology removes the assembly step. The outcomes below are what these programs target. Treat them as hypotheses to prove in your own pilot, not as benchmarks.
Life sciences
R&D, clinical, manufacturing, safetyTrial data, assay results, regulatory submissions, batch records, and safety signals live in systems that were never designed to reference each other. A single question about a compound can take a scientist two weeks of email.
What the ontology addsCompounds, targets, indications, studies, sites, batches, and adverse events become linked objects, aligned to public vocabularies and standards already used in the industry so external evidence joins internal evidence. [16] [22]
What it unlocksTrial feasibility and site selection answered in hours instead of weeks. Drug repurposing candidates surfaced by traversal rather than literature review. Deviation investigations that trace a batch to raw material lot, equipment, operator, and environmental record in one query.
Financial services
Risk, compliance, servicingRisk data aggregation obligations demand that a bank explain, quickly, how an exposure number was produced. Most estates cannot answer that without a manual reconciliation exercise. [14]
What the ontology addsLegal entities, parties, products, positions, and controls modeled against an industry ontology such as FIBO, with mapping from legacy systems into a governed graph. Definitions become machine-readable, so lineage is a query rather than a project. [13] [23]
What it unlocksRegulatory reporting with traceable derivation. Faster onboarding and KYC through resolved party hierarchies. Financial crime detection that follows relationships across accounts, devices, and counterparties instead of scoring rows in isolation.
Investment banking
Coverage, deals, marketsDeal knowledge is trapped in pitch decks, CRM notes, research, and the heads of bankers who move firms. Every new mandate rebuilds context that the firm already paid for once.
What the ontology addsIssuers, sponsors, sectors, comparables, precedent transactions, coverage relationships, and restrictions modeled as linked objects, with information barriers enforced at the ontology layer rather than by convention.
What it unlocksPitch preparation with comparables and precedents assembled automatically, then checked by an analyst. Cross-sell signals from relationship traversal. Conflict and restriction checks that run before the meeting, not after. Research synthesis grounded in the firm's own positions and history.
Energy and utilities
Grid, assets, field operationsAsset registers, GIS, SCADA, outage management, work orders, and weather feeds all describe the same network in different dialects. During a storm, the cost of that translation is measured in customer minutes lost.
What the ontology addsA network model built on the industry Common Information Model, extended with your asset, crew, and customer objects, so connectivity, condition, and work all reference the same topology. [17] [18]
What it unlocksOutage restoration sequencing that accounts for connectivity, crew skills, and critical customers. Vegetation and asset risk scored against actual feeder topology. Interconnection studies and DER onboarding that reuse one model instead of rebuilding it per request.
Manufacturing and supply chain
Parts, suppliers, plants, and shipments linked to contracts and quality events. Disruption questions answered by traversal, so a tier-two supplier fire maps to affected SKUs and customers in minutes.
Insurance
Policies, claims, coverages, reserves, and treaties in one model. Claims triage and fraud detection that reason across relationships, and reserving explanations that hold up in an audit.
Public sector and health systems
Programs, entitlements, providers, and outcomes connected under strict purpose limitation, so eligibility and care coordination questions are answerable without pooling everything into one place.
What should we do in the next 90 days?
Not a strategy phase. One decision, one domain, one measurable answer set. Momentum comes from a working thing that a business owner defends in a steering meeting.
Prove the gap
- Write 150 real business questions your people ask
- Answer them with your current stack and score it honestly
- Harvest metadata from three source types
- Name one executive sponsor and one domain owner
Model the core
- Model 30 to 60 entities with the domain owner in the room
- Reuse an industry standard rather than inventing terms
- Resolve identity for the entities that matter most
- Stand up graph plus retrieval behind one API
Ship and measure
- Put the Ontology LLM in front of the sponsor's team
- Re-run the question set and publish the delta
- Route every correction into the ontology backlog
- Decide the next two domains based on evidence
Free consultation
If you are weighing build against buy, or a pilot has stalled at the definition layer, a short conversation usually saves a quarter. No pitch deck. We will look at your estate, your use case, and the shortest credible path to a working ontology.
- A 45 minute working session, not a sales call
- An honest read on whether you need a platform at all
- A one-page 90 day plan you can take to your sponsor
- contact@r2dw.com
Request your session
Tell us where you are stuck. We reply within two business days.
Or email contact@r2dw.com directly.
References
External material cited on this page or consulted while writing it. Analyst research behind paywalls is listed by title and publisher so you can retrieve it through your own subscription rather than relying on a secondary summary.