What is a business ontology, and what turns it into a context graph?
Your business already has a model. The concepts, the names, the rules and the relationships between them all exist today, scattered across documents, schemas, and the heads of people who have been there long enough. None of it sits in one place an agent can read, which is why every AI project starts by rediscovering the same things.
This page explains what a business ontology is, how a context graph differs from a glossary and from a knowledge graph, what the five asset types are, and why linking meaning to the fields underneath is the part that makes it useful.
governed by
owned by
used in
stored in
Five asset types. Every node keeps its source.
Key takeaways
- An ontology is the agreed structure of what your business means. A context graph is that structure populated with your own terms and linked to your data.
- A flat glossary loses the part that matters. Meaning lives in the relationships: which rule governs which field, which role owns which term, which process touches which system.
- Designing an ontology by committee ships a diagram. Starting from a predefined base ontology and populating it automatically from your own sources gets you a usable map instead.
- Metagem's graph carries five asset types, each with provenance and each linked down to the technical assets behind it, and it exports in open formats.
What a business ontology actually is
An ontology sets out what kinds of things exist in your business, what properties they have, and how they relate to one another. A glossary is a list of definitions; an ontology is the structure that list sits inside. The difference sounds academic until you try to answer a question that depends on more than one entry.
A context graph is that structure populated. Your own terms, your own rules, your own processes, roles and systems, each one filled in from what your business already wrote down, and each one linked down to the technical assets that carry it. Five asset types, one connected structure.
Calling it a graph rather than a list is not a technology preference. It is what lets you ask a question that traverses: which reports depend on this definition, what breaks if we change this rule, who signs off if we do. Those questions have no answer in a spreadsheet of definitions, because the answer is the relationships.
- A glossary lists definitions. An ontology says how they connect.
- A knowledge graph is the technology. A context graph is what you populate it with.
- Terms, rules, processes, roles and systems, not terms alone.
- Every node keeps its source, so the map can be audited rather than believed.
- Open formats and an MCP endpoint, so the map leaves with you if you leave.
Why ontology programmes stall
Take the word customer.
To sales it is an account with an open opportunity. To finance it is a legal entity that has been billed. To service it is anything with a live support contract. The German subsidiary has a fourth version that predates the last acquisition and is still the one their reports use.
The conventional fix is to convene the owners and agree a single definition. This produces one of two outcomes. Either the group agrees on something abstract enough to be acceptable to everyone, which by construction governs nothing and changes no report. Or it does not agree, and the term goes on a list of open items that outlives the programme.
The second failure arrives even when agreement happens. The definition lands in a document or a catalog entry, and it stops there. It says what a customer is. It does not say which of the eleven customer tables it applies to, which of them is authoritative, or which field carries the flag that distinguishes them. Nobody can act on it, and no agent can use it, because the meaning was never connected to the data.
The third is time. Whatever was agreed is a snapshot of the day the workshop ended. Systems get replaced, subsidiaries get acquired, definitions get revised in a spreadsheet nobody circulates, and the map quietly stops describing the business.
None of this is a failure of effort. It is what happens when meaning is treated as a document to be authored rather than a structure to be extracted, connected and maintained.
When a glossary is enough
Not every organisation needs a context graph, and it is worth saying where the simpler thing works. If one team owns the terms, the definitions rarely change, the reporting sits on a single system, and no agent is consuming the definitions programmatically, a maintained glossary in a wiki or a catalog will do the job at a fraction of the effort. The structure starts to earn its keep when two functions defend different definitions of the same term, when the answer changes depending on which system you ask, or when the map has to be read by something that cannot ask a follow-up question.
Apply. Populate. Link.
Step 1
Apply
You start from a predefined base ontology instead of a blank modelling canvas.
- Domains assigned rather than designed from scratch
- Adjusted to your business, not invented for it
Step 2
Populate
Agents extract the terms, rules, processes, roles and systems from what you already have.
- Documents and systems, structured and unstructured
- Your experts approve, reject or correct
Step 3
Link
Each concept is tied down to the columns and tables that hold it.
- Term to field, rule to column
- Provenance on every node and edge
Catalogs and MDM tools tend to cover one side, either the business meaning or the technical assets. Metagem links both in the same graph, so a concept carries its definition, the document it came from, and the fields that actually hold it. That is what makes it answerable for an agent.
What's different hereWhere it shows up
Five asset types, one structure
Terms, rules, processes, roles and systems in a single connected graph, so a question about a metric can reach the rule behind it and the role that owns it.
Provenance on every node
Each concept keeps the document or field it came from and the person who approved it, which is what separates a map you can audit from a map you have to trust.
A glossary that points at data
Definitions land on the fields that carry them, so the glossary stops being a reference document and starts being something systems can resolve against.
Business GlossaryOpen formats, portable out
The graph exports in open formats and is served over MCP. The context is yours, and it is not trapped in the tool that built it.
Frequently asked questions
Your business model exists. It is just not written down anywhere an agent can read.
Pick the domain where the arguments happen. We populate the graph from your own documents and systems, and show you the terms, rules and fields already connected.
Talk to our team