Beyond Ontology: The Operome
April 13, 2026
The brightest minds in AI and enterprise agree: there is a missing infrastructure layer. None of them have named it. None of them have defined it clearly. This paper changes that.
Robert Koller | SynapseLayer.ai | March 2026
Last week I published a paper arguing that ten independent voices had converged on the same missing layer in AI: the ontology. The structured representation of entities, relationships, and rules that governs how an organization operates.
The response confirmed the thesis but also exposed a limitation in the language. "Ontology" carries baggage. For some people it means philosophy. For others it means a taxonomy someone built in Protégé ten years ago and never maintained. For the knowledge graph community it means a schema of entities and relationships that describes a domain. And for a growing number of enterprise AI practitioners it means something much more specific that the word itself does not quite capture.
I want to name what it actually is. Because what enterprises need is not an ontology in any of the existing senses of that word. It is something that has not existed as a formal category until now.
I am calling it the operome.
Why Ontology Is Necessary but Insufficient
An ontology describes a domain. It defines entities, their attributes, and the relationships between them. If you are building a system that needs to understand bonds, an ontology tells you that a bond has an issuer, a maturity date, a coupon rate, a currency, and a governing law. It tells you that the issuer is a legal entity with a jurisdiction and a credit rating. It maps the relationships: this bond was issued under this programme, governed by this master trust deed, cleared through this system.
This is valuable. It is also static.
An ontology tells you what exists. It does not tell you what should happen when those entities interact under specific conditions. It does not encode the rule that says when a payment date falls on a holiday in Luxembourg but not in London, the payment rolls to the next business day in Luxembourg unless the bond documentation specifies modified following, in which case it rolls forward unless that would push it into the next calendar month, in which case it rolls backward. It does not encode the 400 other rules like that one which govern how a single financial instrument actually operates in production.
Knowledge graphs have the same limitation. They are representations of what is known. They are not representations of what is required. They describe the world. They do not prescribe how to operate within it.
This distinction is the one that an investor pushed me on yesterday. He said context graphs have existed for two years. He is right. They have. Foundation Capital wrote the thesis. Neo4j is building the storage layer. Practitioners in Berlin and San Francisco are converging on the architectural pattern. And every one of those context graphs was hand-built by humans who read documents and decided what to model. They describe a domain. They do not execute an operation. And they do not extract themselves from the source documentation that governs the operation.
The Progression
The history of enterprise data architecture is a progression toward increasingly complete representations of organizational reality.
It started with data. Raw records of transactions, events, and states. A database tells you what happened. It does not tell you why, or what should have happened, or whether what happened was correct.
Then came metadata. Data about the data. Schemas, catalogs, lineage, quality scores. Metadata tells you what the data means and where it came from. It does not tell you what to do with it.
Then came knowledge graphs. Structured representations of entities and their relationships, often enriched with semantic meaning. A knowledge graph tells you how things connect. It does not tell you what the rules of engagement are between those connected things.
Then came ontologies. Formal definitions of categories, properties, and relationships within a domain. An ontology tells you what exists and how it is classified. In the strongest implementations it includes constraints and axioms. But even a well-built ontology is typically a description of a domain, not an executable representation of how a specific organization operates within that domain.
Then came context graphs. Foundation Capital's Jaya Gupta and Ashu Garg named this category in their thesis on what they called "AI's trillion dollar opportunity": a knowledge graph enriched with decision traces, provenance, and temporal validity, containing all the information necessary to make decisions throughout an organization. The Neo4j community has been building toward this from Berlin to San Francisco, with practitioners on both sides of the Atlantic converging on the same architectural pattern. Context graphs added something ontologies lacked: operational context, the institutional knowledge of how decisions were made and why.
Garg doubled down on this thesis in late February, writing in his analysis of the software selloff that the nature of moats in enterprise software is changing fundamentally. His argument: SaaS lock-in was historically built on friction, the cost of migrating data and the habituation of teams building workflows around a specific interface. Agents weaken the second kind because users interact with the agent, not the underlying system. What replaces friction as the moat, in his framing, is context: the organizational decision histories and reasoning patterns that reflect how a specific company thinks and operates. He stated it plainly: incumbent systems of record were optimized for a human workforce, not an agentic one. They record outcomes, not the reasoning behind them. And his conclusion: "the startups that solve the context graph problem first will be very hard to displace."
He is right about the direction and incomplete about the destination. Context graphs capture how a company has operated. That is empirical knowledge, accumulated from observation. In regulated operations, the authority is not how the company operated. It is what the documents say it is required to do. Those are different things, and when a regulator asks why a transaction was processed a certain way, "because the context graph learned that pattern from historical behavior" is not a defensible answer. "Because clause 7.3(b) of the governing documentation specifies this behavior" is.
Gupta sharpened this further in March, arguing that every moat thesis in AI applications has been eaten by the next capability jump and that only two structural advantages survive: ontologies and decision traces. Her definition of ontology is precise: "the deep institutional answer to what a word means here, in this organization," something that "cannot be inferred from public data" and "has to be explicitly constructed." She is right that institutional meaning must be explicitly constructed. But her framing assumes that explicit construction requires a human to have been present and made an act of encoding. That is the assumption the operome challenges. The explicit act of encoding can be automated. The source documentation already contains the institutional definitions. Infrastructure that reads it, extracts the logic, and maintains provenance back to the source clause performs the act of encoding without the human bottleneck.
The context graph community has identified this limitation from the inside. At a recent meetup, Jessica Talisman stated the problem directly: building a context graph is not primarily an engineering problem. It is a knowledge management problem. The prescription from the community is to invest in human elicitation processes to capture institutional knowledge. Build the knowledge model before the persistence layer. Treat knowledge capture as the primary objective.
That prescription is correct about the problem and incomplete about the solution. Human elicitation does not scale. It is expensive, inconsistent, and bottlenecked by the same people whose institutional knowledge you are trying to capture. The moment those people change roles or leave the organization, the context graph begins to decay.
The most sophisticated response from within the context graph community is to let agents discover the ontology empirically. The argument: you cannot predefine organizational structure, so deploy agents that traverse systems, observe patterns, and learn the schema through problem-directed exploration. Agent trajectories become the event clock. Accumulated walks become a world model. Structure emerges from observation rather than specification.
This is elegant, and in certain domains it works. But it has a fundamental limitation in regulated operations. An empirically discovered world model tells you how an organization currently operates. It does not tell you how the contracts, regulations, and policies require it to operate. In an unregulated environment, current practice is the truth. In a regulated environment, current practice is often a deviation from the documented requirements, and the documented requirements are what the regulator enforces.
The approach that works for travel booking or IT incident resolution does not work for bond issuance, insurance claims adjudication, or pharmaceutical compliance. In those domains, you do not need agents that observe what people do. You need infrastructure that extracts what the documents say.
This is the distinction between an empirical approach and a normative approach. The context graph community is building the empirical layer: observe, learn, model. The operome is the normative layer: read the source documentation, extract the rules, make them executable, and verify every output against them.
Each step added something the previous one lacked. Data lacked structure. Metadata lacked semantics. Knowledge graphs lacked formalism. Ontologies lacked operational specificity. Context graphs lacked automated extraction from source documentation.
The operome adds what context graphs lack: automated extraction, executability, completeness, and provenance.
What the Operome Is
The operome is the complete set of machine-executable operational instructions of an organization, extracted from the source documentation that governs its operations.
The analogy is to the genome. The genome is not a description of an organism. It is the instruction set. It does not say "this organism has blue eyes." It encodes the sequence of molecular operations that produce blue eyes under specific conditions. The genome is both complete (it contains every instruction the organism needs to develop and function) and executable (the cellular machinery can read and act on it without interpretation).
The operome works the same way for an organization. It is not a description of what the organization does. It is the instruction set that governs what the organization is supposed to do, extracted from the contracts, policies, regulations, and procedures that define its operations, and encoded in a form that machines can execute and verify without human interpretation.
Four properties distinguish the operome from everything that came before it.
Automated extraction. The operome is not hand-built. It is extracted from the source documentation itself by dedicated infrastructure. This is the fundamental difference from context graphs, knowledge graphs, and every predecessor in the progression. Every context graph deployed in production today was constructed by humans who read documents and decided what to model. That is an interpretation. The operome reads the documents and extracts what they actually say. One scales with engineers. The other scales with infrastructure.
Executability. Every element of the operome is machine-executable. Not just "this bond has a coupon rate of 3.5%" (that is data). Not just "coupon rates are a property of bonds" (that is ontology). But "on each interest payment date, calculate the accrued interest by multiplying the outstanding principal by the coupon rate, dividing by the day count fraction specified in clause 4.2, and rounding to two decimal places using banker's rounding unless the pricing supplement specifies otherwise." That is an operational instruction. It can be executed by a machine without human interpretation.
Completeness. The operome aspires to contain every operational rule that governs a specific domain of activity within the organization. Not a representative sample. Not the rules someone decided were important enough to model. All of them. The genome analogy is precise here: a genome missing 10% of its genes does not produce an organism that is 90% correct. It produces an organism that does not function. The same is true for operational rule sets. A system that knows 90% of the rules governing a bond issuance will produce outputs that are wrong in ways that only become visible when the missing 10% is triggered, which in regulated operations is exactly when the consequences are most severe.
Provenance. Every element of the operome traces back to a specific clause, paragraph, or provision in a specific source document. The rule is not an engineer's interpretation. It is the documented requirement, made machine-readable. This provenance is what makes the operome auditable. When a regulator asks "why did your system do this?" the answer is not "because an engineer configured it that way three years ago." The answer is "because clause 7.3(b) of the offering circular specifies this behavior, and here is the extraction trail from the clause to the executable rule."
What This Means for the Observability Problem
In February, LangChain published an analysis of why production agent monitoring is fundamentally different from traditional software monitoring. Their argument: you cannot predict what an agent will do in production because inputs are infinite and LLMs are non-deterministic. Their proposed solutions are all post-hoc. Sample production traces. Route them to human reviewers through annotation queues. Use LLMs to evaluate other LLMs. Cluster failure patterns. Build dashboards that track when things go wrong.
Every one of these solutions is observing what went wrong after it happened.
The industry is investing billions in increasingly sophisticated tools to watch agents fail. Observability platforms, evaluation frameworks, safety classifiers, red-teaming infrastructure. All of it operates on the same assumption: the agent will produce unpredictable outputs, and the best we can do is catch the bad ones quickly.
The operome inverts this assumption. If the agent operates against an executable rule set extracted from the source documentation, the agent is structurally constrained to produce outputs that conform to the documented requirements. You do not need to sample 10-20% of traces and have humans review them. The constraint layer catches violations at execution time, not in a post-production review queue.
This is not a replacement for observability. You still want to know what your agents are doing. But it changes the nature of what you are observing. Without an operome, you are monitoring whether the agent produced a good output. With an operome, you are monitoring whether the agent followed the rules. The first requires human judgment at scale. The second is deterministic and verifiable.
The AI industry is building the rearview mirror. The operome is the road.
Why the Genome Analogy Matters
The genome analogy is not decorative. It is structurally precise in ways that matter for how the technology develops.
Before the Human Genome Project, biology operated on partial knowledge. Researchers understood specific genes, specific pathways, specific diseases. The relationships between them were mapped piecemeal over decades. The genome project changed the field by making the complete instruction set readable and navigable. It did not replace the work that came before. It provided the foundation that made everything that came after it, from personalized medicine to CRISPR, structurally possible.
Enterprise operations are in the pre-genomic era today. Organizations understand specific processes, specific regulations, specific workflows. The relationships between them are maintained piecemeal by consultants, legal teams, and operations professionals who hold the connections in their heads. When those people leave, the institutional knowledge leaves with them.
The operome project, if you want to think of it that way, is the enterprise equivalent of making the complete instruction set readable and navigable. Once it exists, everything built on top of it, from AI agents to compliance automation to operational analytics, has a verified foundation to work from.
The genome also provides the right intuition for how extraction works. You do not build a genome. You read it. The instructions were already there, encoded in the DNA. The Human Genome Project developed the infrastructure to read and represent what was already written.
The operome is the same. You do not build an organization's operational rules. You read them. The instructions are already there, written in contracts, regulations, policies, and procedures. The infrastructure extracts and represents what is already documented.
A note on the term itself: the operome already exists in molecular biology. It refers to the complete set of operons, the regulatory units that control which genes are expressed and how. The parallel is not accidental. The biological operome is the regulatory instruction set of an organism. The enterprise operome is the regulatory instruction set of an organization. The term carries the right meaning in both domains.
What This Means for the Jensen Slide
Last week at GTC, Jensen Huang put up a slide titled "Structured Data is the Ground Truth of AI" with a $120B market size. He is right that structured data is the foundation. But the slide shows the storage and acceleration layer: SQL engines, data frames, vector stores, storage platforms.
The operome sits upstream of everything on that slide. Before structured data can be the ground truth of AI, someone has to extract the operational rules from the source documentation and encode them as structured, executable data. That extraction and encoding layer is where the operome lives.
Jensen's $120B is the market for storing and accelerating structured data. The operome layer is the market for producing it, specifically the operational subset that governs how enterprises actually function.
What This Means for the Harness Conversation
In software engineering, the AI community has converged on the concept of the "harness": the complete designed environment inside which a language model operates, including the tools it can call, the constraints it must obey, and the feedback loops that catch its mistakes.
The operome is the enterprise equivalent of the harness. But instead of governing how AI writes code, it governs how AI executes business operations. The principles are identical: the agent's quality is bounded by the quality of the constraints it operates within. The difference is that in software engineering, the constraints are architectural (dependency rules, linting, test suites). In enterprise operations, the constraints are operational (contractual obligations, regulatory requirements, validation logic).
The harness engineering community has independently arrived at the same conclusion that my paper described: the model is not the bottleneck. The constraint layer is the bottleneck. The operome is what that constraint layer looks like when applied to business operations rather than code generation.
The Category
The operome defines a new infrastructure category. It is not a knowledge graph (those describe domains). It is not a context graph (those add decision traces but are still hand-built). It is not a rules engine (those execute rules someone configured). It is not a compliance tool (those check outputs against regulations). It is not a workflow platform (those orchestrate processes).
The operome is the infrastructure that automatically extracts, encodes, maintains, and serves the complete set of machine-executable operational instructions of an organization, with full provenance back to the source documentation.
The companies that build this infrastructure are not competing with SAP or ServiceNow. They are not competing with Palantir or Celonis. They are building the layer that sits underneath all of them, the layer that makes every other system in the stack trustworthy because it can verify its outputs against the documented rules that govern the operation.
Jensen said structured data is the foundation of trustworthy AI. The operome is where that structured data comes from when the domain is enterprise operations.
Sources
- Robert Koller, "The Brightest Minds Converge on the End of Hardcoded Software," SynapseLayer, March 2026.
- Jaya Gupta and Ashu Garg, "Context Graphs: AI's Trillion Dollar Opportunity," Foundation Capital. foundationcapital.com
- Ashu Garg, "Taking Stock of the SaaSpocalypse," Foundation Capital, February 28, 2026.
- Jaya Gupta, "VCs are terrified of the app layer now," Foundation Capital / LinkedIn, March 23, 2026.
- Zaid Zaim, Nyah Macklin, and Alexander Erdl, "Context Graphs and AI Memory Across the Globe," Neo4j Developer Blog, March 4, 2026. neo4j.com
- Jessica Talisman, remarks at the Context Graph Meetup, San Francisco, March 2026. Cited in [3].
- Animesh Koratana, "How to build a context graph," March 2026. x.com
- Jensen Huang , NVIDIA GTC 2026 Keynote, "Structured Data is the Ground Truth of AI," NVIDIA, March 17, 2026. youtube.com
- Emil Eifrem, remarks at the Context Graph Meetup, San Francisco, March 2026. Cited in [3].
- Yann Bilien (Rippletide) and Dave Bennett (Indykite), presentations at the Context Graph Meetup, San Francisco, March 2026. Cited in [3].
- LangChain, "You don't know what your agent will do until it's in production," LangChain Blog, February 25, 2026.
Robert Koller is the Founder and CEO of SynapseLayer, which builds operomic infrastructure for enterprise AI. The fDesk (powered by SynapseLayer.ai) deployment has processed over 600M EUR in regulated European debt capital markets with 99.98% accuracy across 100,000+ validations and zero compliance violations.