We Gave the Enterprise Brain a Vocabulary, Not Just More Memory

The Enterprise Brain could already retrieve cited knowledge. The ontology addition gives that knowledge typed meaning, immutable versions, governed publication, scoped graph traversal, and a rebuildable search projection.

The Enterprise Brain could already tell an agent which document contained a claim.

It could return the paragraph, the source path, the timestamp, and the content hash. That solved the first trust problem: where did this answer come from?

It did not solve the next one.

What is an incident? Can an incident affect an asset? Where did it occur? Which record shape backs that concept? Is “site” a place, a team, or a document label? A vector match can retrieve text containing those words. It cannot make their business meaning stable.

So we added an ontology layer to the Enterprise Brain.

Not a larger prompt. Not another pile of embeddings. A governed vocabulary with typed relationships, immutable versions, exact approval evidence, persona-scoped reads, and a search projection that can be deleted and rebuilt from the source of truth.

The change moved the Enterprise Brain from memory with receipts toward memory with structure.

The change from cited retrieval to ontology-backed reasoning. The Enterprise Brain already returned source chunks with provenance. The ontology addition introduces governed entities, typed relationships, and source bindings, allowing agents to ask structural questions without discarding the original evidence layer.

Provenance was necessary, but it was not semantics

I wrote earlier about the Enterprise Brain provenance contract: no citation, no claim. Documents enter the brain with source metadata attached, and agents reach them through a narrow, audited interface.

That remains the foundation.

But cited retrieval and ontology answer different questions.

Capability	Cited retrieval	Ontology
Find a relevant passage	Yes	Not its primary job
Show where a claim came from	Yes	Preserves concept provenance
Define a business concept once	Weak	Yes
Express a typed relationship	Implied in prose	Explicit
Ask for every connected item	Unreliable	Graph traversal
Distinguish “none exists” from “nothing was retrieved”	Difficult	Possible when the graph is complete
Route an agent to the system backing a concept	Heuristic	Explicit binding

RAG is good at similar. Ontology is for is, relates to, and is backed by.

An incident is not merely text near the word “asset.” It is an entity type. affects is not a phrase the model inferred from a paragraph. It is a directional relationship from Incident to Asset. IncidentRecord is not another document. It is a table contract backing the entity.

That difference matters when an agent must enumerate, traverse, validate, or abstain.

The public place to learn the shape

Microsoft’s open-source Ontology Playground on GitHub is the clearest public way to make this concrete.

It includes an interactive graph, a visual designer, RDF/OWL import and export, a catalogue of domain ontologies, and an ontology school. You can draw entities and relationships, inspect cardinality, export RDF/XML, and see how a question maps to a graph instead of treating “ontology” as an architecture-slide noun.

The live Playground is useful for learning and authoring. The Enterprise Brain solves a different part of the problem: how an ontology becomes a controlled runtime dependency for a fleet of agents.

Microsoft Ontology Playground	Enterprise Brain ontology runtime
Learn and explore ontologies	Serve an approved ontology to agents
Design visually	Author and review in source control
Import and export RDF/OWL	Ingest a constrained Open Knowledge Format profile
Share diagrams and catalogue entries	Publish immutable versions behind identity and policy
Validate authoring structure	Fence activation, reads, search projection, and rollback

The two fit together conceptually. One makes ontology understandable. The other makes it operational.

We chose Markdown as the authoring edge

The Enterprise Brain authoring format is Open Knowledge Format, or OKF: one Markdown file per concept, with YAML frontmatter.

The basic unit looks ordinary on purpose:

---
type: relationship
title: affects
description: An incident affects an operational asset.
tags: [operations]
eos:
  source: Incident
  target: Asset
---

# affects

Connects incident metadata to affected asset metadata.

The Enterprise Brain accepts three concept types:

entity — a governed business concept;
relationship — a directional typed edge with a source and target;
table — a source-binding contract that backs an entity.

We profile OKF with a small eos extension because the base format does not yet formalise everything the runtime needs. The extension carries typed relationship endpoints, identity metadata, properties, and table bindings.

Markdown gives us properties a visual editor alone cannot:

a normal pull-request diff;
stable paths for provenance;
deterministic serialization and hashing;
human review without a specialist graph tool;
a portable authoring layer that does not make one graph product the source of truth.

The parser fails closed. Unsupported frontmatter, duplicate identities, colliding paths, unknown relationship endpoints, and unresolved table bindings stop the bundle before it reaches the graph.

That is important. A graph with a missing endpoint is not “mostly valid.” It is a different claim about the business.

The path from draft to active ontology

An ontology becomes dangerous when editing and activation are the same action.

We separated them.

The Enterprise Brain ontology lifecycle. Authors create OKF Markdown concepts, deterministic validation compiles and hashes the bundle, immutable versions enter a Cosmos DB registry, exact-hash human approval moves the active manifest, and persona-scoped graph and search APIs serve only the sealed active version. Azure AI Search is a rebuildable projection, not the source of truth.

The path is:

Author entities, relationships, and tables as OKF Markdown.
Validate the entire bundle and compile it into Enterprise Brain graph threads.
Seal the canonical content, graph projection, and ordered concept index with SHA-256 hashes.
Register the version as immutable documents.
Approve the exact version hash.
Activate it by moving one manifest pointer under revision fencing.
Serve the active version through bounded MCP and REST operations.
Project the same sealed concepts into a dedicated search index.

The registry is Cosmos-native because the Enterprise Brain already uses Cosmos DB as its durable operational store. Fabric IQ and Foundry IQ remain optional outbound integrations; neither sits on the critical path or owns the ontology state.

That boundary is deliberate.

If a customer architecture uses Fabric ontology, the Enterprise Brain can export to it. If Foundry needs semantic retrieval, it can consume the Azure AI Search projection. But deleting either projection must not delete the approved vocabulary or its history.

The registry remains authoritative. Everything else is derived.

One partition holds one ontology’s history

All records for an ontology share its ontologyId partition:

Record	Job
Manifest	Points to the active and immediately previous versions
Version	Stores immutable metadata and aggregate hashes
Concept	Stores one immutable entity, relationship, or table
Validation	Binds a verdict to the exact version hash
Publication	Records approval, actor, source, target, and action
Event	Appends activation or rollback history

The concepts themselves are never edited in place.

Publishing version 2 does not rewrite version 1. It adds version 2, validates it, records approval evidence, then changes the manifest from activeVersion: 1 to activeVersion: 2.

Rollback does not attempt to reverse a set of graph mutations. It moves the manifest back to the immediately previous validated version and appends another event.

This is version control reduced to the operation the runtime actually needs: which sealed vocabulary is active now?

Approval belongs to the bytes being published

An approval such as “the ontology looked fine yesterday” is not sufficient evidence.

Promotion requires an approval hash equal to the immutable version’s canonical content hash. If one concept changes after review, the hash changes and the approval no longer applies.

The write gate also requires:

ontology publication explicitly enabled;
Entra authentication enabled;
an allowlisted aidm.persona.* publisher role;
an allowlisted token-derived principal;
a fixed deployment target;
the expected manifest revision;
a replay-safe operation ID.

This prevents four quiet failures:

approving one version and publishing another;
trusting a caller-supplied persona header instead of token identity;
overwriting a newer activation with a stale operator session;
repeating a publication after a lost response and creating a second state transition.

Publication is disabled by default. Read access is also deny-by-default on its own persona scope.

An ontology is a powerful compression of how an organisation sees itself. Treating it as ordinary content would be a category error.

The read path is bounded as aggressively as the write path

The ontology API exposes a small set of operations:

list accessible ontologies;
fetch a paged immutable bundle;
traverse a typed graph;
search active concepts;
read the sealed validation record;
inspect runtime status.

Every read is constrained.

The deployment has a finite ontology catalogue. Persona scope is checked before direct access. Bundle pages are capped at ten concepts. Full response envelopes stay below two megabytes. Graph traversal has concept, depth, and response ceilings. Search allows at most twenty results.

Those limits are not performance tuning. They are part of the security contract.

Without them, “read-only” can still become an extraction endpoint, an accidental denial-of-service surface, or a prompt-stuffing machine.

Search is a projection, not a second truth

Agents still need text search over titles, descriptions, bodies, tags, and source paths. We added a dedicated Azure AI Search index for that job.

Each projected document carries:

ontology ID;
version;
aggregate ontology content hash;
concept ID and concept content hash;
concept type;
source path;
searchable content.

Queries are filtered to the active manifest’s exact version and hash. A stale search document from an older version is not eligible merely because its text matches.

Projection sync is repeat-safe:

build the desired documents from the active sealed bundle;
remove stale or mismatched documents;
merge or upload the desired set;
query the index back;
verify exact document count and concept hashes.

If the index disappears, rebuild it. If the registry disappears, the ontology is gone.

That distinction keeps search useful without allowing it to become authoritative.

What changed for an agent

Before this addition, an agent could ask:

Find the incident-response guidance and cite the source.

Now it can also ask:

What entity types exist in the operations ontology?

Which relationships connect an Incident to an Asset and a Site?

Which logical record backs the Incident entity?

Show the typed neighbourhood around Incident, but only if my persona can read this ontology.

The answer still carries provenance. The difference is that the agent no longer has to infer the organisation’s vocabulary from whichever chunks happened to rank highest.

Search retrieves the explanation. The ontology constrains the meaning.

What we did not build

The boundary matters as much as the feature list.

We did not put operational instance data into the baseline. The canary contains metadata-only entities, relationships, and a logical table shape.

We did not make Azure AI Search the registry.

We did not allow autonomous publication. A model can help draft or validate an ontology; it cannot manufacture its own approval proof.

We did not make Fabric IQ or Foundry IQ mandatory runtime dependencies.

We did not claim that a valid ontology is a complete ontology. Structural validation can prove that every relationship endpoint exists. It cannot prove that the business vocabulary is correct, sufficient, or accepted by the people who own it.

That remains human work, supported by benchmarks and operational evidence.

The contract we tested

The focused ontology suite currently contains 62 tests:

..............................................................           [100%]
62 passed

They cover:

OKF parsing, round-trip writing, validation, and graph compilation;
immutable registration, content seals, bounded batches, and restart reload;
exact-hash publication, stale-revision rejection, replay safety, and rollback;
persona-scoped MCP and REST reads;
pagination, graph, and response-size ceilings;
active-hash search projection, stale-document cleanup, and exact sync verification;
repeat-safe baseline seeding.

That does not prove the ontology is semantically complete. It proves the runtime preserves the contracts it claims to enforce.

A brain needs both receipts and a vocabulary

The original Enterprise Brain contract was: show me the source.

The ontology addition adds four more:

show me the approved definition;
show me the typed relationship;
show me which version is active;
show me who was allowed to change it.

A brain that can cite a sentence is useful.

A brain that knows the sentence refers to an Incident that affects an Asset and occurredAt a Site can support more precise work.

But the graph is not the achievement by itself. The achievement is making that vocabulary inspectable, versioned, scoped, reversible, and subordinate to evidence.

If you want to understand the visual and authoring side first, start with Microsoft’s Ontology Playground repository. Then ask the harder production question:

What has to be true before this vocabulary is allowed to shape an agent’s decisions?