---
title: "The Ontology over Your Systems"
slug: "chapter-12-the-ontology-over-your-systems"
kind: "chapter"
order: 13
label: "Chapter 12"
chapter: 12
part: "The Data Layer"
partLabel: "Part III"
partNumber: 3
epigraph: "An ontology that stores nothing is the only one you never have to migrate."
summary: "Connectors reach systems. The broker governs the reach. One problem remains: each system calls things by its own names, and an agent that has to know that a \"person\" in the directory is a \"student\"…"
words: 1108
topics:
  - "The vocabulary problem"
  - "A pass-through, not a warehouse"
  - "How identity and authorization flow through it"
  - "What belongs in the ontology and what does not"
  - "Building it incrementally"
---

Connectors reach systems. The broker governs the reach. One problem remains: each system calls things by its own names, and an agent that has to know that a "person" in the directory is a "student" in one system, a "constituent" in another and an "account" in a third is an agent that will get it wrong. The traditional answer is a data warehouse with a unified schema, which is the migration from Chapter 9 under a grander name. The sovereign answer is an ontology that describes the institution's objects and where they live, and stores nothing itself.

## The vocabulary problem

Institutions are federations of systems, each built by a different vendor for a different purpose, each with its own model of the world. The registrar's system thinks in terms of enrolments and sections. The advancement CRM thinks in donors and campaigns. The HR system thinks in positions and appointments. The same human being appears in all three under different identifiers, with overlapping but inconsistent attributes.

A person asking an agent a question does not think in any of those terms. They ask about "Maria," "the biology department," "last term's cohort." For the agent to answer, something has to map those everyday concepts to the specific systems, identifiers and fields where the facts are. Without that mapping, every skill has to encode it from scratch, and every agent reinvents the institution's data model badly.

## A pass-through, not a warehouse

An ontology, in the sense I mean here, is a description of the institution's concepts, the relationships among them, and for each concept, the system of record and the connector tool that answers questions about it. A Student has a Program, Enrolments, Holds and an Advisor. Student attributes come from the SIS through this tool; the advising relationship comes from the advising platform through that tool; the directory supplies contact details.

The crucial property is that the ontology holds the map and not the territory. It stores no student records, no enrolments, no holds. When an agent asks about Maria's holds, the ontology resolves "Maria" to an identifier, resolves "holds" to the SIS connector's hold-lookup tool, and the broker makes the call under the asking user's identity. The answer comes from the SIS, now, with the SIS's permissions. Nothing was copied.

This is why I describe it as a pass-through. It is a layer of meaning over the systems, not a layer of data beside them. It can be versioned, reviewed and extended like any configuration. It is never stale, because it contains no facts that can go stale. And it never has to be migrated, because there is nothing in it to move.

## How identity and authorization flow through it

Because the ontology sits above the connectors and the broker, it inherits their guarantees rather than weakening them.

A query that arrives at the ontology carries the user's verified identity. The ontology's resolution of concepts to tools does not change that identity or add any authority to it. When the resolved call reaches the broker, the broker applies its deny-by-default policy for that user's role, agent and tool, exactly as if the agent had named the tool directly. And the source system applies its own permissions last.

What the ontology adds is consistency. Two agents asking about the same concept resolve to the same tool with the same scoping, because the mapping lives in one place. An administrator who changes which system is authoritative for a concept, say, moving advising relationships from a spreadsheet to a real platform, changes one mapping and every agent follows.

Some platforms also use the ontology to enforce authorization rules that no single source system can express, such as "an advisor may see enrolments only for students in their assigned caseload across both the SIS and the LMS." Those rules live beside the mapping, are evaluated at query time, and are logged like any other decision. They are policy over live data, not a filtered copy of it.

## What belongs in the ontology and what does not

The discipline that keeps an ontology from becoming a warehouse is a short list of what it may contain.

It may contain concept definitions, relationships, and the mapping from each concept to the system and tool that serves it. It may contain identity resolution rules: how a person in one system is matched to the same person in another. It may contain authorization rules that span systems. It may contain descriptive metadata that helps the agent choose: this field is the preferred name, that one is legal name; this date is in the local time zone.

It may not contain records. No cached results, no nightly snapshots, no "just this one table for performance." The moment it holds data, it has a freshness problem, a permissions problem and an exit problem, and it has become the thing it was built to avoid.

Where performance genuinely requires a copy, a search index over documents for instance, that copy is a separate, explicitly governed component with its own classification and its own refresh policy, reached through a connector like any other system. The ontology points at it; it does not become it.

## Building it incrementally

Institutions sometimes hear "ontology" and imagine a two-year enterprise modelling exercise. The sovereign approach is the opposite. The ontology starts with the concepts the first agent needs, three or four, mapped to one or two connectors, and grows with each agent that follows. Because it stores nothing, there is no backfill, no migration and no cutover. Adding a concept is adding a definition and a mapping.

In practice the growth follows the connectors. Connect the SIS and the ontology learns about students, courses and enrolments. Connect the CRM and it learns about prospects and donors, and about the identity rules that link them to students and alumni. Connect the ticketing system and it learns about cases and the people who file them. Each step makes every existing agent a little more capable, because the vocabulary they share has grown.

Appendix E lays out a starting catalogue of concepts and connectors for the sectors this book addresses. The point of the catalogue is not completeness. It is to show how small the first step is, and how much of the institution an agent can reach, live and governed, once the data layer is built this way instead of by copying.

Part IV turns to the clients: how the agents built on this data layer reach people on the web, in the browser, on the desktop and on the phone, through one identity system that never hands an application a secret.