Your business already has a formal model. It is just written down inconsistently, in six places, by four teams.
Every enterprise has an agreed set of definitions — what a customer is, when an order is fulfilled, what counts as an exception, who may approve a credit. It exists in policy documents, system field names, spreadsheets, and the heads of a few experienced people. This practice turns that into a single governed specification that agents, analytics and systems can all reason from.
Five layers, not one
Entities, states, rules, decisions, accountability. Most glossary work stops at the first.
Executable, not descriptive
The output is not a document. It compiles into tool contracts, validation rules and evaluation dimensions.
Change is governed
A definition changes, and every consumer needs to know. We build the change path, not just the model.
Human and machine readers
The same specification is read by a domain expert and consumed by a runtime. Both readers are first-class.
Four things get confused. Only one of them can make an agent reliable.
When an agent disagrees with a human colleague, the cause is almost never a model failure. It is that the agent and the colleague were working from different definitions. These four artefacts are usually conflated, and each one is useful — but only the fourth carries the rules.
| Artefact | What it actually is | What it is good for | Why it cannot carry an agent |
|---|---|---|---|
| Business glossary | A controlled vocabulary with plain-language definitions and synonyms | Reducing naming disputes, search confusion and duplicated terms across a business | It defines words, not behaviour. A glossary can say what a "suspicious order" is and still leave two teams deriving the same threshold differently. |
| Data catalogue | A technical inventory of datasets, fields, owners, lineage and freshness | Discovering data, assessing trust, onboarding analysts, planning integration | It describes where data lives and what shape it is in. It does not encode what the data means in the business, or which combinations are valid. |
| Knowledge graph | A network of entities and their typed relationships, usually populated at scale | Multi-hop retrieval, entity resolution, network analysis, related-item discovery | It records what is connected but not which connections are permitted, required, or disqualifying. A graph can hold both a valid and an invalid arrangement of the same facts. |
| Enterprise ontology | A governed specification of entities, their states, the rules over them, the decisions taken about them and who is accountable | Making agent behaviour deterministic, auditable and consistent across systems and teams | — this is the row that carries the rules, which is why it is the one that has to exist before agents scale. |
What "exception" means in one process
A glossary says: exception — a case that does not follow the standard path. Useless to an agent, because it cannot classify anything. An ontology says: a case enters state exception_review when the settlement variance exceeds the tolerance for its product, the counterparty is on the enhanced-due-diligence list, or the case has been open longer than the ageing threshold. Those are three evaluable conditions, and they can be written as validation rules, tool contracts and evaluation dimensions.
Why agents drift at exactly this point
An agent asked to classify exceptions will infer thresholds from the examples it has seen. In a pilot that looks like competence. In production it is drift: the thresholds differ from the ones in the policy, they differ between agents, and nobody can prove which definition was applied on a given day. A modelled rule removes the inference step entirely — the agent applies the definition the business already agreed to.
Ontology in numbers
Only one of them can make an agent reliable
Skipping any one leaves a hole that shows up in production
Noun-and-verb workshops down to runtime
A single source of truth that the business actually maintains
Four things get confused. Only one of them can make an agent reliable.
Conflating these is the most common cause of an agent estate that demos beautifully and cannot explain its own answers in production.
| Term | What it actually is | Can it make an agent reliable? |
|---|---|---|
| Data catalogue | An inventory of what data exists, with ownership and location | No — it tells you where things are, not what they mean |
| Data model | The structure of systems: tables, fields, relationships | No — it describes storage, not meaning |
| Business glossary | A list of agreed definitions, usually in a document | Partly — it settles vocabulary but holds no rules |
| Enterprise ontology | The agreed meaning of entities, their relationships, and the rules that apply — held as an executable semantic layer | Yes — this is the one, because it is what an agent reasons over at runtime |
Five layers. Skipping any one of them leaves a hole that shows up in production.
Most ontology work in the wild is entity modelling — a very large list of nouns. Entity modelling is necessary and it is the least interesting layer. The behaviour of an agent is decided by the four above it.
Entities
The things the business acts on and the relationships between them: customer, account, order, contract, product, policy, claim, supplier, site, device, entitlement. Each entity carries identity rules, the attributes that define it, and the synonyms and legacy names it appears under in source systems.
Identity matters more than it appears. The same customer can exist in five systems under five identifiers, and an agent that treats them as five customers will do arithmetic that is confidently wrong.
States
The legal and meaningful positions an entity can occupy, and the permitted transitions between them: draft, submitted, validated, in review, approved, fulfilled, disputed, closed. A state machine per entity type, with the conditions on each transition written as predicates.
States are what turn a status field into something an agent can reason about. "Status = 4" is not a state. "Awaiting counterparty documentation, entered when the request was issued and not more than 15 business days ago" is.
Rules
The business logic that must hold: eligibility, thresholds, precedence, exclusions, calculation definitions. The part that is usually in people's heads and in one document nobody can find. Written as predicates with named parameters, so they can be tested and versioned.
Rules are also where the agent's authority is defined indirectly: a rule that says what must happen is what an agent is permitted to do inside its tier.
Decisions
The judgement points inside a process, expressed as a decision with an input set, permitted outcomes, the authority level required to make it, and what evidence must accompany the outcome. This is the layer an agent operates against, and the layer that connects directly to the authority tier model.
A decision definition is also the natural unit for evaluation: each decision becomes a testable dimension with a defined correct answer.
Accountability
Who owns the definition, who may change it, who consumes it, and what happens downstream when it changes. This layer is what turns a model into an organisational asset rather than a project deliverable that ages out in a repository.
Most models fail here, quietly. The definitions are correct on the day they are written and nobody is responsible for keeping them true.
Five layers. Skipping any one of them leaves a hole that shows up in production.
Built bottom-up, and each layer is separately arguable by the business. This is what makes an ontology maintainable rather than a document that rots.
Which ontology layers matter most, by industry
Financial services and the public sector lean hardest on business rules; industrial and technology organisations lean on relationships and process semantics. Where you invest first depends on which layer your agents will actually reason over.
| Vocabulary | Entity identity | Relationships | Process semantics | Business rules | |
|---|---|---|---|---|---|
| Financial Services | |||||
| Banking & Digital Banking | |||||
| Insurance & Insurtech | |||||
| Asset & Wealth Management | |||||
| Manufacturing & Smart Factory | |||||
| Automotive & Mobility | |||||
| Logistics, Supply Chain & Freight | |||||
| Retail & Consumer Goods | |||||
| Healthcare & Hospitals | |||||
| Pharmaceuticals & Life Sciences | |||||
| Telecoms & Technology | |||||
| Media, Entertainment & Publishing | |||||
| Energy & Utilities | |||||
| Water, Waste & Environmental Services | |||||
| Construction & Real Estate | |||||
| Public Sector & Government | |||||
| Education & Higher Education | |||||
| Professional Services & Legal | |||||
| Hospitality, Travel & Leisure | |||||
| Accounting, Audit & Advisory |
From noun-and-verb workshops to an executable semantic layer
The modelling is done with the people who do the work, in the words they use, and it is finished by turning the agreed definitions into something a runtime can enforce. The last step is the one most engagements skip, and it is the step that decides whether the model is used or filed.
Noun-and-verb elicitation
Workshops with operators and supervisors, not only architects. We record the nouns they act on and the verbs they perform, then trace where two teams use the same word for different things — which is where the real definitions live.
Resolution of contested terms
Where two teams disagree, the disagreement is escalated to the accountable owner with a recommendation. We do not split the difference and call it done; an unresolved definition is a defect in the model.
Layered drafting
Entities and states first, then rules, then decisions, then accountability. Each layer is reviewed by the people who will be accountable for it, in the order they will have to defend it.
Compilation into the executable layer
Definitions become tool contracts with typed parameters, validation rules enforced at write time, and evaluation dimensions with expected values. This is the point at which the model stops being a document.
Change governance
A change request path, an impact check against the consumer register, a deprecation window, and a versioned history so that any past decision can be explained by the definition that applied at the time.
One rule, compiled four ways
The point of a semantic layer is that one agreed rule serves several audiences without being re-interpreted by each of them.
Tool contract
The rule becomes a typed parameter on the operation an agent may call, with the permitted range declared and enforced.
Validation rule
The rule becomes a check at the point of write, so an invalid state cannot be committed to the system of record.
Evaluation dimension
The rule becomes a scored dimension with an expected value, so a regression run can detect a drift in behaviour.
Retrieval filter
The rule becomes a structured filter the context layer applies before ranking, rather than a phrase the model has to interpret.
The test we apply. If a change to a definition requires edits in a spreadsheet, a prompt, a system field and three people's heads, the model is not in control. A definition that cannot be changed in one place and propagate is documentation, and documentation does not govern an agent.
Five questions that tell you whether a domain is modelled
If the state of an entity can only be described as a status code plus tribal knowledge, it is not modelled. A state is a condition with an entry rule, an exit rule and an owner.
A threshold written as "as per policy" is not a rule. A rule whose parameters are named can be versioned, evaluated, tested and referenced by a tool contract.
Given a past decision, can you name the rule and the version that produced it? If not, the reasoning is not recorded anywhere, and no amount of logging the output will recover it.
A model read only by people is a glossary with a diagram. Readiness means a tool contract, a validation rule or an evaluation dimension already derives from it.
Name the owner, name the consumer register, and describe the impact check. A model with no change path will be accurate for a while and then quietly wrong.
From noun-and-verb workshops to an executable semantic layer
Twelve weeks to a semantic layer an agent can reason over, with a governance model that survives the consultants leaving. That last part is the deliverable that actually matters.
Noun-and-verb workshop
Business participants name the things that matter and the things that happen. Deliberately facilitated, and deliberately contentious.
Entity extraction
Nouns become candidate classes with identity rules. Identity is the hard part, and it is where most ontologies fail.
Relationship modelling
Verbs become relationships and state transitions, with the constraints that must hold between entities.
Rule formalisation
Prose policies become executable rules. Every ambiguity found here is an ambiguity the business must resolve — which is the real deliverable.
Semantic layer runtime
The ontology is exposed as a layer the agent reads at decision time, with version and lineage on every rule.
Governance handover
Ownership assigned to named business stewards, with a change process that is not a meeting.
How a semantic layer is actually read at runtime
A model that only humans read will drift from the systems that actually execute the work. The semantic layer is designed so that the same definition is enforced at the point of action, ranked into the context an agent sees, and scored in the evaluation run that gates its release.
At the tool boundary
Each operation exposed to an agent declares the entity it acts on, the parameters it accepts, their permitted ranges and the states in which the operation is legal. Calling a tool outside its envelope fails loudly instead of succeeding oddly.
During context assembly
Structured filters derived from rules are applied as retrieval constraints before semantic ranking happens, so the candidate set already respects the business definition rather than being filtered out by a prompt afterwards.
During evaluation
Each decision becomes a dimension with an expected value. A regression run tells you not only that the agent's answer changed, but which rule stopped holding — which is a diagnosis rather than an incident.
During audit
The definition version that applied at the moment of an action is attached to the execution record, so a past decision can be explained by the rule in force that day, not by today's rule.
Entity resolution and permission
An ontology is only useful if it is permission-aware, because the same entity is visible to different people for different reasons, and an agent inherits the authority of the person or service identity it acts under.
| Concern | How the model handles it |
|---|---|
| Identity across systems | Matching rules per entity type declare which attributes are decisive and which are only supporting, so a merge is a governed act with a recorded basis. |
| Visibility | Classification attaches to the entity, and the classification follows the agent's service identity into every query and every tool call. |
| Multi-hop questions | Typed relationships make traversal possible, and a path is only traversed through relationships the caller is permitted to follow. |
| Traceability | Every fact carries provenance to the source system and the definition version, so a claim in an answer can be checked by a human. |
How a semantic layer is actually read at runtime
The value is not elegance. It is that a rule can be tested, cited, versioned and argued about — which is precisely what an agent's answer has to survive.
- The agent retrieves text and reads it like a person
- Every rule must exist in prose, somewhere, correctly
- A contradiction between two policies is invisible until a case hits it
- Regional differences are discovered per incident
- Nothing can be tested, because nothing is executable
- The answer cannot cite a rule — only a document
- The agent resolves entities through the ontology before acting
- Rules are executable, versioned and owned by a named steward
- Contradictions surface as a governance item, not a customer complaint
- Regional differences are modelled and testable
- Rules are unit-testable against historical cases
- The answer cites a rule, with its version and effective date
Single source of truth is not free, and pretending otherwise is how programmes fail
Every organisation that has tried this has made the same discovery in the same way: the cost is not in modelling, it is in the transition. Someone has to give up a definition they have used for years, and someone has to fund the maintenance that nobody budgeted for.
We put those costs on the table at the start, because a model that is presented as free will be under-resourced and will quietly decay.
| Cost | What it really involves | How we keep it tractable |
|---|---|---|
| Deprecation | Retiring a definition means changing reports, dashboards, integration contracts and people's habits | Model the top definitions first, agree a deprecation window, and never claim full coverage |
| Maintenance ownership | Someone must own each definition's truth, with time budgeted for it | Accountability layer names the owner; the steering committee enforces it, not the consultants |
| Reconciliation cost | Source systems that disagree must be reconciled, and until then the model is aspirational | Publish confidence per definition and let consumers see which are settled |
| Data quality spillover | A clean definition over dirty data produces confidently wrong answers | Model the data contract alongside the definition and treat non-conformance as a tracked exception |
| Organisational friction | One team's definition becoming the enterprise's definition is a negotiation, not a modelling step | Escalate contested terms early, with the accountable owner, and record the decision |
One domain, end to end
We do not model the enterprise at once. We pick one domain that has a live agent or a live measurement requirement, and take it through all five layers until it is executable and consumed. A working slice of semantics that is actually used by a runtime teaches the organisation more than a comprehensive model that is read once.
Choose by consequence
The domain where a wrong definition costs money or creates a compliance problem, not the domain that is easiest to diagram.
Judge by consumption
A domain is done when a tool contract, a validation rule and an evaluation dimension all come from it — not when its model is complete.
What we do not claim. We do not deliver an ontology that is complete, permanent or self-maintaining. We deliver a governed slice that is executable, owned, measured, and structured so the next slice is cheaper than the first.
Single source of truth is not free, and pretending otherwise is how programmes fail
Single source of truth is not free. It costs governance meetings, steward time, a change process and the political capital to resolve ambiguity between departments. Budgets that pretend this is a data modelling exercise produce an ontology that is technically complete and operationally abandoned within a year.
What you own at the end
Five artefacts, each with a named owner, each reviewed by the people accountable for it. If a deliverable cannot be maintained by your team without us, it is not a deliverable — it is a dependency we have hidden in a document.
Terminology register
Every business term in scope, its agreed definition, the synonyms and legacy names in use, the systems that hold it, and the owner who may change it. Includes terms explicitly ruled out, so agents stop producing them.
The layered model
Entities with identity rules, state machines with transition guards, rules as named predicates, decisions with authority tiers, and the accountability layer — all in a form that can be diffed, versioned and reviewed.
Executable semantic layer
Tool contracts with typed parameters and declared envelopes, validation rules applied at write time, retrieval filters derived from the rules, and evaluation dimensions with expected values.
Data contracts
The agreement between the model and each source system: field-level definitions, non-conformance behaviour, refresh expectations and the exception route when a source drifts from the agreed definition.
Change governance process
A change request path with impact analysis against the consumer register, an approval rule by definition type, a deprecation window, and a versioned history that explains any past decision by the rule in force at the time.
A change nobody can make silently
The test of the engagement: after it ends, no definition in the modelled domain can be altered by one person without the affected consumers being identified and notified. That is what makes the model govern agents rather than merely describe them.
What you own at the end — and what you still have to keep owning
The last item is the one that matters. We hand over the open questions, because a semantic layer built by hiding them is a semantic layer that will be wrong somewhere.
- The semantic layer itself, versioned and deployed into your environment
- A rule catalogue where every rule has an owner, a version and an effective date
- Named business stewards, with the authority to change their own rules
- An evaluation set derived from historical cases, testing rules rather than prompts
- A change process with a review gate, not a mailing list
- A training curriculum so stewards can maintain it without us
- The uncomfortable list: every ambiguity we found that only the business can resolve
What an ontology is not
Enterprise ontology is powerful and frequently oversold. We are explicit about the four things it does not do, because a client who expects one of them will be disappointed at exactly the moment it matters.
- It is not a data warehouse. The model specifies meaning; it does not store or move data. Storage, integration and the physical layer remain the data team's work, and the data contract is where the two meet.
- It does not replace master data management. Master data management governs the creation and lifecycle of records. The ontology consumes master data as its entity substrate and adds the business meaning on top — it does not create golden records for you.
- It does not fix data quality. A precise definition of an order, applied to incomplete order records, produces precisely wrong answers. We model the non-conformance so it is visible and tracked, but the remediation work belongs to the data team.
- It does not replace the tool layer. A model without a runtime, a context pipeline and an evaluation harness is documentation. The semantic layer only pays off when something consumes it, which is why the infrastructure work runs alongside it.
The model, and the things that read it
Context and runtime
Where the model is compiled into retrieval filters, tool contracts and validation rules.
Governance and evidence
Where the accountability layer becomes auditable controls and a management system.
Capability
Where domain experts and builders are trained to maintain the model together.
Operating model
Where decisions and their authority tiers are connected to the way work is delegated.
What an ontology is not
If your organisation already has a data catalogue and believes that solves it, the gap between the two is exactly where your agent's answers will become indefensible.
- It is not a data catalogue.
- It is not a database schema.
- It is not a glossary in a slide deck.
- It is not something a technology team builds alone — the ambiguities are organisational, not technical.
- It is not permanent. Business change invalidates it, so governance is not optional.
- It is not required before every agent. A well-scoped, low-materiality agent can operate without one — and knowing which is which is the judgement.
What this page answers
Every topic below is covered in the sections above, and each links to the page that goes deeper on it.
Bring us the term your teams define three different ways
A 45-minute working session with a domain lead. Pick one contested definition from your business and we will walk it from the words people use to the rule an agent could execute. You will know within the session whether this work is worth starting.