Concepts

The five-layer model — permissions, schema, bindings, actions, and the context engine.

The ontology layer is built on five distinct concerns, each with its own concept set. Understanding the split makes the rest of the section make sense.

Five layers

Layer	What it does
L1 — Permissions	Decides who can see what at the type and instance level. Backed by the platform authorization layer plus the document clearance model.
L2 — Schema	Defines object types, link types, action types, and identity rules. Versioned in branches.
L3 — Bindings	Declares how a typed Object instance is projected from a real source — a managed table, a knowledge-base page, a process-flow task.
L4 — Actions	Server-side mutations gated by the policy decision point (`AssignAsset`, `FileSAR`, etc.).
L5 — Context engine	The retrieval surface — semantic search over typed Objects with citations.

What's typed, what's not

Typed: object types, link types, action types, identity rules. These live in the ontology schema.

Not typed: the raw data underneath. Managed tables have their own schema; knowledge-base pages are unstructured markdown; process-flow tasks have their own model. The ontology gives them a typed view.

Identity rules

Every object type declares an identity rule — how to derive a stable instance ID from its source. Typical patterns:

A single column from a managed table (customer.id).
A composite key — multiple columns combined.
A page slug from a knowledge-base entry.
A custom expression involving multiple fields.

Identity rules matter because they're how the platform decides whether two records represent the same instance. Re-uploading a CSV doesn't create new IDs as long as the identity columns are stable.

Property types

Object-type properties are typed with a small set of primitives plus structured types:

Type	Notes
`string`	Free text
`number`	Integers + floats
`boolean`	true / false
`date`, `datetime`	ISO 8601
`enum`	Closed set of strings
`geo`	Coordinates
`currency`	Amount + currency code
`array<T>`	Lists of the above
`link<TargetType>`	Reference to another typed Object

Each property can be marked required, searchable (indexed for retrieval), or carry DLP / classification labels that flow through to the masking pipeline.

Link types vs. embedded references

A property can be a link<TargetType> for a 1-to-1 reference. For 1-to-many or many-to-many relationships, you declare a link type:

LinkType: "owns"
  from: Customer
  to: Account
  binding: customer.id matches account.owner_id in `customers_accounts` table

The link is projected at query time from the joining table.

Action types

Actions are server-side mutations. Unlike workflow tools (which are typed wrappers around a stateless operation), Action types carry state contracts:

ActionType: "AssignAsset"
  input: { assetId, userId }
  preconditions: asset is unassigned, user is in workspace
  postconditions: asset.owner = user
  side effects: audit event, downstream link creation

Actions are gated by the policy decision point — a caller without the right grant cannot dispatch them. Failed preconditions produce a typed error the workflow can branch on.

Branches

The schema is versioned. main is the published baseline; every edit happens on a proposal branch. Proposals are reviewed and either:

Published — replace main's baseline.
Archived — discarded.

This is essential for production: a typo in an object-type definition can break every workflow that uses it. Proposals make that change reviewable.

Object types — define the entities.
Link types — define the relationships.
Action types — define the mutations.
Bindings — project from real data.
Branches & proposals — version the schema.

Concepts

On this page