Technical Foundations
Ontologies for Context Graphs
The entity modeling problem is largely solved by existing standards. The real unsolved work is temporal validity, decision traces, and fact resolution. Adopt foundations, then learn what's novel.
What is an Ontology?
To understand ontologies, it helps to differentiate four related but distinct concepts:
Vocabularies
Human-readable definitions of words
Taxonomies
Human-readable hierarchies and definitions for domain-specific terms
Schemas
Machine-readable representations of data for storage and retrieval
Ontologies
Machine-readable definitions of terms, hierarchies of those terms, and their relationships
Put simply, a context graph is a triples-representation of data optimized for usage with AI. The triple format is: Subject → Predicate → Object
Example triple:
Alice → isMotherOf → Bob
Existing Ontology Standards
Before discussing learned ontologies, it's worth acknowledging how much of this work already exists in production systems. There's twenty years of ontology work that often goes unacknowledged.
Schema.org
A collaborative vocabulary for structured data on the web, founded in 2011 by Google, Microsoft, Yahoo, and Yandex. It defines canonical types for the entities that matter: Person, Organization, Place, Event, Product, CreativeWork, and hundreds of others.
In production across billions of web pages. When you see rich snippets in Google search results, that's Schema.org markup.
Microsoft Common Data Model (CDM)
The schema that powers Dynamics 365, Power Platform, and much of Microsoft's enterprise stack. Defines entities like Account, Contact, Lead, Opportunity, Case, Product, Campaign.
Originally licensed from WAND, who has been building enterprise taxonomies for decades.
Industry-Specific Standards
- • Healthcare: FHIR (clinical data), SNOMED (medical terminology)
- • Finance: FIBO (financial instruments and business entities)
- • Manufacturing: ISA-95 (enterprise-control integration)
RDF and the Semantic Web Stack
RDF (Resource Description Framework) adds structure to the triple concept. RDFS (RDF Schema) adds types and properties. OWL (Web Ontology Language) adds rich ontology capabilities.
Common serialization formats: RDF/XML, N-Triples, JSON-LD, Turtle
The Prescribed vs Learned Debate
The current conversation around context graphs has crystallized around a dichotomy:
Prescribed Ontologies
Define the schema upfront, map messy enterprise data into it, deploy forward engineers to customize for each customer.
Example: Palantir's approach—works, but expensive and slow.
Learned Ontologies
Structure emerges from how work actually happens rather than how someone designed it. Agent trajectories as training data.
The ontology isn't declared—it's discovered.
“The next $50B company will be built on learned ontologies. Structure that emerges from how work actually happens, not how you designed it to happen.”
This framing is intellectually elegant, but it ignores twenty years of ontology work that already exists. There's a third option hiding in plain sight:
The Missing Third Option
Adopt what exists. Extend where needed. Focus learning on what's genuinely novel.
The Practical Approach
The learned ontology vision conflates two very different problems:
Entity Modeling
What types of things exist and how do they relate?
Solved—or at least solvable with existing standards
Organizational Intelligence
How does this specific organization actually work? What patterns govern decisions?
Genuinely novel, genuinely requires learning
The entities themselves—Person, Organization, Account, Contact, Event—don't need to be learned. We know what these are. The types are stable. Waiting for agent trajectories to “discover” that Account and Contact are important entities is like waiting for a search engine to discover that nouns exist.
Where Learning Actually Helps
- ✓Which contacts at an account actually matter for this deal?
- ✓What's the real decision-making process (vs. the org chart)?
- ✓Which exceptions get approved and which don't?
- ✓What precedents actually govern how decisions are made?
This is tacit knowledge. It's not in any ontology because it's specific to how this organization operates. This is where learning from trajectories makes sense—not “discover that Account is an entity” but “discover that Sarah Chen is the actual decision-maker even though the CRM says it's her boss.”
What's Actually Unsolved
If entity modeling is largely solved by existing standards, what's genuinely novel? Where should builders focus their innovation?
Temporal Validity
Facts that change over time. The ability to query historical state. Time as a first-class dimension.
Learn more about temporal context →Decision Traces
Being in the execution path where decisions are committed. Capturing not just what happened but why it was allowed to happen.
Learn more about decision traces →Fact Resolution
Using LLMs to determine what's canonical, what's superseded, how to synthesize timeline facts from scattered observations. Maintaining coherent beliefs as evidence accumulates.
Organizational Learning
Where trajectories genuinely help—but on top of a foundation, not instead of one. Learning patterns specific to how this organization operates.
Three Principles
- 1. Adopt foundations, don't reinvent them. The entity modeling problem is solved well enough.
- 2. Build the temporal layer. Facts with validity periods. Queryable history. Time as first-class.
- 3. Focus learning on what's genuinely novel. Organizational patterns. Decision dynamics. Tacit knowledge.
Start Building on Foundations
Join the Context Graph Marketplace to explore ontology infrastructure.
Join the WaitlistReferences
This article is based on insights from the following sources:
- •Kirk Marple (CEO, Graphlit) — “Context Graphs: What the Ontology Debate Gets Wrong” on X/Twitter
- •Daniel Davis (TrustGraph) — “The Context Graph Manifesto” on X/Twitter