Ontology Building
Map your organization's world into a living knowledge graph that powers every AI agent
What Is an Organizational Ontology?
A structured representation of your organization that AI agents can reason over
The Semantic Layer
The nouns — what exists in your world
- → Entity types model real-world things — students, courses, departments, equipment
- → Attributes capture characteristics — enrollment date, grade level, capacity
- → Relationships define how entities connect — a student enrolls in a course, a course belongs to a department
The Operational Layer
The verbs — what can happen in your world
- → Actions define permissible changes — enroll a student, update a grade, approve a request
- → Functions encode logic — calculate GPA, assess risk scores, route approvals
- → Permissions govern who can do what — role-based access at every level
Why Build an Ontology?
Five principles that make ontology-driven AI fundamentally different
Shared understanding at scale
- Every team, department, and agent operates from the same definitions — no conflicting spreadsheets, no siloed dashboards
- New data sources are modeled into a common language rather than spawning another disconnected view
- Local decisions gain global context — a department head sees how their choices affect the wider organization
Human-readable by design
- Users interact with familiar terms — students, courses, advisors — not tables, joins, or API endpoints
- The ontology bridges technical and non-technical teams, eliminating weeks of data reconciliation
- Domain experts can explore data directly without writing queries or waiting on engineering
Build once, reuse everywhere
- A well-modeled entity type serves every downstream application — dashboards, agents, reports, and integrations
- New use cases plug into the existing ontology instead of requiring fresh data pipelines
- The cost of launching the tenth agent is a fraction of launching the first
Capture decisions as data
- Every action taken through the ontology — an approval, a classification, an override — is recorded and available
- One user's insight becomes another user's input, compounding the value of the knowledge graph over time
- Audit trails and decision history are built in, not bolted on
Ground AI in organizational reality
- Models and agents operate on the same structured knowledge that humans use — no translation layer needed
- Predictions, classifications, and recommendations tie directly to the entities and relationships users already understand
- As agents act and users respond, operational data flows back — creating a feedback loop for continuous improvement
Core Ontology Types
The fundamental primitives that model your organization
Entity Types
Schema definitions of real-world objects or events. Each entity type has instances — an "Employee" type contains individual employees, a "Course" type contains individual courses.
e.g. Student, Course, Department, Device, Transaction
Attributes
Characteristics that describe an entity. An attribute type defines the shape (text, number, date, location); an attribute value is the data on a specific instance.
e.g. Name, enrollment date, capacity, GPA, location
Relationships
Typed connections between entities that carry meaning. Relationships can be one-to-one, one-to-many, or many-to-many, and can link entities of the same type.
e.g. Student enrolls in Course, Manager supervises Employee
Actions
Controlled operations that create, modify, or remove entities and relationships in a single transaction. Actions enforce validation rules and trigger side effects like notifications.
e.g. Enroll student, approve request, update record
Extending the Ontology
Powerful abstractions for complex organizational models
Interfaces
Abstract shapes that multiple entity types can implement. A "Facility" interface with name and location attributes can be shared by airports, warehouses, and offices — letting agents work with all of them uniformly without knowing the specific type.
Functions
Code-based logic that reads entity attributes, traverses relationships, and returns computed results. Functions power derived metrics, complex validations, model inference, and any server-side computation agents need at decision time.
Derived Attributes
Values calculated at runtime by traversing relationships and aggregating data. A department's average satisfaction score, a student's total credits, or a device's most recent inspection — all computed live from the graph without storing redundant data.
Structured Attributes
Composite attributes that group related fields into a single property. An address with street, city, and postal code, or a name with first and last components — keeping related data together while preserving field-level access.
Semantic Search
AI-powered search that converts text into vector embeddings and matches by meaning rather than keywords. Agents can find relevant entities even when queries don't match exact field values — essential for natural language workflows.
Permissions & Security
Granular control over who sees what and who can change what
Schema Permissions
Control access to type definitions
- → Who can view or modify entity type definitions
- → Who can create new relationship types
- → Who can define or edit action types
Data Permissions
Control access to individual records
- → Who can read specific entity instances
- → Who can execute actions on which entities
- → Row-level and field-level security for sensitive data
From Ontology to Operational Agents
How the ontology becomes the foundation for intelligent automation
Discovery
Agents navigate the graph to find the right information
Analysis
Agents compute insights across entities and relationships
Automation
Agents execute actions within governed boundaries
Learning
Agent decisions feed back into the ontology as new data
Agents understand context, not just data
Because the ontology captures meaning — not just tables — agents can reason about relationships, follow chains of context, and give answers grounded in organizational reality.
Every agent benefits from every improvement
When a new entity type or relationship is added to the ontology, every agent that touches that domain immediately gains access. The investment compounds.
Decisions create a feedback loop
Actions taken through agents are captured as structured data in the ontology. Over time, this operational record enables model retraining, pattern detection, and continuously improving recommendations.
Building an Effective Ontology
Start with what people already call things
Use the terms your teams use every day. The ontology should feel familiar to domain experts — not like learning a new system. If people say "student" and "course," those are your entity types.
Model for decisions, not just storage
Every entity type, relationship, and action should support a real decision someone needs to make. If no one will ever query it or act on it, it doesn't belong in the ontology yet.
Let the ontology grow with usage
Start with a focused set of entity types for your first use cases. As agents and users interact with the system, new modeling needs will emerge organically — extend the ontology then, not before.
Treat actions as first-class citizens
The operational layer — what agents and users can do — is as important as the data layer. Define actions with clear validation rules, permissions, and side effects from the beginning.
Build Your Ontology
Identify core entities
Map the real-world objects and events that drive your organization's key decisions
Define relationships
Draw the connections between entities that agents will need to traverse
Model actions and permissions
Specify what can change, who can change it, and what happens when they do
Deploy your first agent
Launch an agent that operates on the ontology — see structured knowledge in action