Ontologyisunderstanding.
NeuroCluster resolves identity once and builds a live operational model — assets, topology, state, events, work and risk — so every application and operational agent understands through the same meaning.
- Engineer—ASSIGNED_TO→Work order
- Maintenance agent—AUTHORIZED_FOR→Work order
- Work order—RELATES_TO→Transformer
- Transformer—LOCATED_AT→Substation
- Inspection—INSPECTS→Transformer
- Inspection—PRODUCES→Evidence
- Grid incident—AFFECTS→Transformer
Definition
An enterprise ontology is a shared, machine-readable model of what an organisation is: the types of object it deals with, the relationships between them, the events that can occur, the actions that may be taken, the rules that constrain them, and the metrics that measure them.
Thegapanontologycloses
A language model is extraordinarily good at language and knows nothing about your organisation. It has never seen your asset register, does not know that a transformer belongs to a substation which belongs to a region under a specific regulatory regime, and cannot tell that the word "customer" means one thing in your billing system and something narrower in your contract database.
Retrieval helps with facts. It does not supply structure. If you ask a well-instrumented retrieval system which assets are affected by a constraint, it will find documents that mention constraints and assets. It cannot traverse from a constraint to the assets behind it, to the work orders scheduled against them, to the crews qualified to do the work, because nothing in the index knows those relationships exist.
An ontology supplies exactly that structure — and, in doing so, makes two other things possible. Permissions become expressible in the organisation's own terms, because there are typed objects to grant access to. And actions become declarable, with owners and preconditions, rather than improvised by whatever the model decides to call.
Whereitsits
Between the systems of record and everything that reasons over them. Fields become typed attributes; joins become named relationships.
Enterprise ontology
Theobjectsanenterpriseactuallyhas
An ontology is not an abstract exercise. These are the object types that recur across the environments NeuroCluster is built for.
Assets
Physical and logical things with a location, a condition, an owner and a maintenance history.
Customers
Counterparties with contracts, obligations, entitlements and a service history.
Contracts
Agreements with terms, dates, obligations and consequences for breach.
Systems
The applications and control systems that hold the truth about everything else.
Work orders
Planned interventions with a scope, a window, a crew and a dependency on asset state.
Incidents
Deviations with a severity, a timeline, a cause and a set of affected objects.
Locations
Sites, regions and network topology — including which jurisdiction applies.
Risks
Assessed exposures linked to the assets, contracts and processes they threaten.
Policies
Rules that constrain what may be done, by whom, under which conditions.
Decisions
Choices made, by whom, on what basis, with what evidence attached.
Events
Things that happened, typed and timestamped against the objects they affected.
Actions
Operations that may be performed, with preconditions, owners and consequences.
The distinction that matters most
Knowledge is what the organisation knows. An ontology is what the organisation is, how its parts relate, and what may happen next. Retrieval gets you the first. Only a semantic model gets you the second.
Ontologyvsknowledgegraph
The terms are often used interchangeably. The useful distinction is between the schema and the instances, and between description and enforcement.
| Concern | Knowledge graph | Enterprise ontology |
|---|---|---|
| What it holds | Instances and their links — the populated graph | The schema: types, relationships, rules and permitted actions |
| Primary use | Discovery, search, traversal, analytics | Grounding reasoning, expressing policy, declaring actions |
| Contains behaviour | Rarely — mostly facts | Yes — actions with preconditions and owners |
| Enforcement role | None inherently | Referenced directly by permissions and policy |
| Relationship | The graph is what an ontology governs | The ontology is the contract the graph conforms to |
OntologyvsRAG
These are complements, not alternatives. Almost every serious deployment uses both, for different questions.
| Question type | RAG handles it | Ontology handles it |
|---|---|---|
| "What does the maintenance standard say about this?" | Yes — retrieve the passage and cite it | No — it is a document question |
| "Which assets are affected by this constraint?" | Poorly — finds mentions, not the set | Yes — traverse the relationships |
| "Is this action allowed for this operator?" | No — retrieval cannot enforce | Yes — policy against typed objects |
| "Summarise the last five incidents on this asset" | Partly — if the reports are indexed | Yes — the incidents are linked to the asset |
| "What changed since last quarter, and why does it matter?" | No | Yes — events and metrics against objects |
Ontologyvsvectordatabase
A vector database is infrastructure. An ontology is a model. Comparing them directly is a category error worth naming, because the two are routinely presented as competing purchases.
| Concern | Vector database | Enterprise ontology |
|---|---|---|
| Kind of thing | Storage and retrieval infrastructure | Semantic model of the business |
| Finds things by | Embedding similarity | Type, relationship and rule |
| Precision of scope | Approximate — nearest neighbours | Exact — this object, these relations |
| Can express a permission | No | Yes |
| Survives rewording | Yes, that is its strength | Yes, because names are typed rather than matched |
| Used together? | Yes — vectors retrieve, the ontology structures | Yes — the ontology decides what retrieval is for |
Ontologyandagents
An agent without an ontology has to infer structure from whatever it is handed. It guesses which system holds the truth, guesses what an identifier refers to, and improvises tool calls. It will often be right, which is the dangerous part, because there is no way to tell a correct guess from a confident one after the fact.
An agent with an ontology is given a mandate expressed in the same vocabulary as the business: you may read these object types, within this scope, and you may propose these declared actions. Its plan is checkable, because the steps refer to real objects and real operations. Its evidence is attachable, because the decision belongs to something that exists in the model.
This is why the ontology page sits in the platform rather than in a data-catalogue section. It is not documentation. It is the substrate that makes governance and grounded reasoning possible at the same time.
Howanontologygetsbuilt
Never all at once, and never as a modelling project detached from a workload.
Questions
- Is this a data catalogue?
- No. A catalogue documents what data exists so people can find it. An ontology defines what things are so systems can reason and policy can be enforced. They coexist well: a catalogue is often the best starting inventory for ontology work.
- How much do we have to model before it is useful?
- Far less than teams expect — typically the handful of object types one decision depends on. Enterprise-wide modelling before a first workload is the most reliable way to produce an ontology nobody uses.
- Do we need a graph database?
- Not necessarily. The ontology is a model; how it is stored and queried is an implementation choice that depends on your existing infrastructure and access patterns.
- What happens when the business changes?
- The model is versioned. New object types, new relationships and changed rules are ordinary changes with authors, dates and review. Evidence records reference the version of the model in force when a decision was made, so old decisions stay interpretable.
Continue
- What is an enterprise ontology for AI?The long-form explainer with worked examples across three industries.
- Knowledge and retrievalRAG, vectors, memory, citations and lineage — and where the boundary sits.
- Governed agentsWhat an agent can do once it has typed objects to reason about.
- IntegrationsHow systems of record feed the semantic model.
- Energy & utilitiesThe same pipeline with SCADA, GIS and an asset ontology.
- Control planeWhat becomes enforceable once objects are typed.
Bring us one operational problem.
You do not need a finished brief. Bring the problem — we will work out the next step together.
Or book a call with the team