On this page
Key takeaways
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.
- Meaning lives in the relationships. A flat glossary loses the part that matters: which rule governs which field, which role owns which term, which process touches which system.
- Starting from a predefined base ontology and populating it automatically from your own sources gets you a usable map instead. Designing an ontology by committee ships a diagram.
- Five asset types, each with provenance and each linked down to the technical assets behind it, exported 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.
Key point
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.
- 01
Apply. You start from a predefined base ontology instead of a blank modelling canvas.Domains assigned rather than designed from scratchAdjusted to your business, not invented for it
- 02
Populate. Agents extract the terms, rules, processes, roles and systems from what you already have.Documents and systems, structured and unstructuredYour experts approve, reject or correct
- 03
Link. Each concept is tied down to the columns and tables that hold it.Term to field, rule to columnProvenance on every node and edge
What's different here
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.
Where 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.
Open 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
- Do we have to design the ontology ourselves?
- No. Metagem applies a predefined base ontology rather than asking you to model one, then assigns your domains onto it and populates it from your own documents and systems. Your experts spend their time judging what the agents propose. That is work domain experts will actually do. Facing an empty modelling canvas is the version that stalls.
- What are the five asset types?
- Terms, rules, processes, roles, and systems or fields. A term carries its definition and its owner. A rule carries the fields it governs and the exceptions that apply. A process carries the systems it touches and the roles accountable at each step. Keeping all five in one structure is what lets a question traverse from a metric to the logic underneath it.
- How is this different from a knowledge graph project?
- A knowledge graph is the underlying technology, and running one yourself means modelling, populating, operating and querying it, usually in a graph query language. Metagem builds, populates, governs and maintains the graph for you and exposes it through a business interface, so the people who own the meaning can work with it without going through an engineer.
- Can we get our data out?
- Yes. The graph exports in open formats and is exposed through an MCP server, so the context is portable to whatever you standardise on later. This is worth checking in any tool you evaluate in this category, including this one: if the meaning you build can only be read by the system that produced it, the cost of changing your mind later is the whole programme.
How Metagem builds your context graph
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.
Last updated October 2026.