Ontology
The typed semantic layer over your managed tables and knowledge base — Object / Link / Action types, projection on read, and where the agentic runtime calls into it.
The ontology layer is Scrydon's typed semantic backbone. It takes raw silver-layer data (managed tables, knowledge-base pages, process-flow tasks) and gives the rest of the platform — agents, the graph view, the analyst — a stable, governed, typed view: Transaction, Customer, RegulatedEntity, affects, flaggedInSAR.
This page is the architectural overview. The product-level documentation is in Ontology, and the authoring SDK is documented at SDKs → Authoring → Ontologies.
Five layers
| Layer | What it does |
|---|---|
| L1 — Permissions | Per-document grants, NATO-style clearance, and Rego policies. Backed by the platform-wide authorization PDP. |
| L2 — Schema | Object types, link types, action types, identity rules. Versioned in branches. |
| L3 — Bindings | "How a typed Object instance is projected from a real source" — a managed table row, a knowledge-base page, a process-flow task, or a manually-authored entry. |
| L4 — Actions | Server-side mutations gated by the policy decision point (AssignAsset, FileSAR, …). |
| L5 — Context engine | The retrieval surface — semantic search over typed Objects with citations, used by the analyst and by agent retrieval-augmented tools. |
The workbench at /ontology has one tab per layer (Schema, Bindings, Actions, Proposals, Marketplace).
Projection on read, not on import
A binding does not copy rows into a new table. It declares how a typed Object instance is built from a source row at query time:
When a caller reads a RegulatedEntity — a Get Object block in a workflow, the graph view, the analyst, or the context engine — the binding's projection runs against the managed table and returns typed instances. No batch ETL job runs. Re-uploading the source CSV is reflected immediately on the next read.
Every projected instance carries provenance: which binding produced it, when it was materialised, which DLP labels it inherits from the source. Those DLP labels feed straight into the masking layer, so a low-clearance caller will never see a high-clearance column even though the typed Object exists.
Binding kinds
| Kind | Source store | Status |
|---|---|---|
silver_table | A managed table — your CSV / JSON uploads | shipped |
memex_page | A knowledge-base page | shipped |
process_flow_task | A process-flow task instance | shipped |
manual | SDK / workbench writes — no upstream | shipped |
process_flow_action, extraction, stream | Entity-link actions, extraction pipelines, pub/sub topics | preview |
A pack can ship bindings of any kind. Bindings can also be authored directly from the workbench's Bindings tab — pick a managed table, map columns, save — without touching the SDK.
How a tenant gets an ontology
Three paths, all coexisting:
- Auto-installed on first open of
/ontology. The platform ships a default ontology that's installed automatically on first use. - Marketplace install. Pick any pack your org is licensed for and install it. Creates object types, link types, action types, identity rules, and bindings on a fresh
mainbranch. - User-authored. Add object / link / action types directly through the Schema tab, then map them through Bindings.
Branches are first-class: main is read-only via the workbench, edits go through proposals, which are reviewed and either published (replacing main's base version) or archived.
How callers read the ontology
Three entrypoints, all wired against the same projection path:
- Get Object block (in a workflow) — type + instance id → fully typed payload + provenance + DLP labels.
- Graph view (
/graph) — pick an ontology + branch → renders the schema graph (object types as nodes, link types as edges). - Context engine — semantic search over typed Objects, used by retrieval-augmented agents. Returns ranked candidate instances with citations.
All three resolve column masking and DLP labels through the same code path, so governance is single-sourced.
Related
- Ontology — product-level overview, schema modelling, examples.
- SDKs → Authoring → Ontologies — author your own packs.
- Analytics — the managed-table layer ontologies bind to.
- Security → Authorization — how the platform PDP gates reads and actions.