What Real Problem Does Ontology Solve in Enterprise Knowledge Bases?

Document retrieval succeeds but facts are not established

When building an enterprise knowledge base, a simple supplier‑payment case reveals that retrieving two contradictory contract excerpts (one naming a "payee entity" and the other a "signing entity") is not enough; the system cannot decide which relationship is authoritative without a semantic contract.

Ontology does not aim to retrieve more snippets; it ensures that the objects, relations, and states returned to the system are interpreted consistently by everyone.

Document retrieval succeeds but facts are not established

Enterprise knowledge bases often bundle several problem types into one box: locating policy text, checking order status, determining object relationships, and triggering business actions. Each requires a different capability.

Problem: Where was this mentioned?

Best capability: Full‑text search, RAG, LLM‑based wiki.

Main output: Original text, summary, citation.

Still missing: Conflict resolution, factual state.

Problem: What does the current system record?

Best capability: SQL, business API.

Main output: Real‑time fields, business status.

Still missing: Cross‑system semantics, access control.

Problem: What relationships exist between objects?

Best capability: Knowledge graph, relationship tables.

Main output: Entities, edges, paths.

Still missing: Definition of relationships, temporal validity, authority.

Problem: How should these relationships be interpreted?

Best capability: Ontology, relationship dictionary, domain rules.

Main output: Types, constraints, inference rules.

Still missing: Source authenticity, action authorization.

Thus RAG, knowledge graphs, ontologies, and agents occupy distinct responsibilities; conflating them into a single “knowledge‑base accuracy” metric hides real risks.

Ontology is not just a more complex relationship graph

In this context, ontology is a machine‑readable, verifiable semantic contract—not a philosophical discussion.

Key points from the supplier example:

Stable identifiers: "Brand A" may appear as brand_1024; the name can change but the ID must not.

Distinct relations: signing_entity, paying_entity, and billing_entity are three different predicates; collapsing them into a generic related_to loses the basis for payment, invoicing, and contract verification.

Temporal and status information: Business relationships often have effective dates, versions, and states (candidate, confirmed, revoked). Without these, “latest write” can be mistaken for “currently valid”.

Missing or conflicting data: Absence of a paying entity does not mean it does not exist; conflicts must be expressed explicitly (unknown, conflict, pending, withdrawn).

Ontology therefore provides a shared contract for queries, validation, and actions.

Why ontology is being discussed again

Since 2025, the speed of document extraction, relationship mining, and tool orchestration has increased dramatically. Karpathy’s LLM Wiki adds a continuously maintained Markdown layer ( index.md, log.md) between raw sources and final answers, helping to navigate and record changes.

Microsoft’s GraphRAG extracts entities, relations, and optional claims during indexing, then generates summaries and community reports, making cross‑document relationships easier to retrieve. However, extracted triples remain candidates; they still need human confirmation for validity, timing, and authority.

Palantir’s Ontology product places objects, attributes, actions, security, and write‑back mechanisms into a broader platform, but it is not a direct implementation of W3C OWL and is not required for every company.

The renewed interest stems from faster document processing exposing semantic disagreements that now need systematic handling.

Putting the knowledge base back into a complete chain

When a knowledge base moves from reading assistance to driving agents and business actions, responsibilities are split into four layers:

Evidence layer → Fact layer → Semantic control plane → Action layer

Evidence layer stores contracts, policies, web pages, API responses together with source, timestamp, and version, preserving the original for audit.

Fact layer records claims extracted from evidence, each with a stable ID, source, validity period, status, schema version, and owner. Candidates ( candidate) become validated or published after disambiguation and human review; erroneous sources move to retracted.

Semantic control plane consists of the ontology, relationship dictionary, and domain rules that define object types, predicate meanings, constraints, permissible inferences, and required conflict exposure.

Action layer handles permissions, approvals, idempotency, rollback, and audit. Agents can query, flag conflicts, or request confirmation, but any actual business operation must still be performed by external systems.

OWL 2 can express categories, relations, and some logical inference; SHACL checks graph shapes and field constraints but does not guarantee source reliability. Authorization is delegated to policy and permission systems.

When ontology is not needed

If the goal is merely to let employees find policy text, full‑text search or RAG is sufficient. For real‑time order or inventory queries, direct SQL or business APIs are more appropriate. For a small, stable rule set, a simple relational table with a few validators may be cheaper than a full semantic stack.

Ontology becomes worthwhile only when the same objects and relations are reused across multiple systems and processes, semantic disagreements cause real errors, and an organization is willing to maintain versions, conflict resolution, and ownership over time.

References

Karpathy: LLM Knowledge Bases (original post)

Karpathy: LLM Wiki (original Gist)

Palantir: Ontology Overview

Palantir: Ontology System

Microsoft: GraphRAG Methods

W3C: RDF 1.2 Concepts

W3C: OWL 2 Primer

W3C: SHACL