Packs
Reusable ontology bundles — object types, link types, action types, and bindings — distributed through the marketplace.
A pack is how Scrydon ships organisation defaults — a reusable, opinionated preset that an org installs once and everyone inherits. Today a pack bundles ontology (object types, link types, action types, identity rules, and bindings); the same mechanism increasingly carries the defaults for the surfaces those Objects bind to:
- Knowledge base — the
knowledge-basepack wires uploaded pages and managed tables to typed Objects. - Process flows — the
process-flowspack ships typed Objects for ISO 27001 / 42001 review and audit cycles. - Data sources (soon) — default bindings against the managed tables an org ingests.
Think of a pack as "the typed world an organisation starts from", distributed through the platform marketplace and installable in one click. First-party packs and customer-authored packs use the exact same artefact and install path.
What's in a pack
| Element | Purpose |
|---|---|
| Object types | The typed entities the pack defines. |
| Link types | The typed relationships between them. |
| Action types | The typed mutations the pack exposes. |
| Bindings | Default bindings (with logical source names that the installer maps to local tables). |
| Manifest | Pack metadata — id, version, description, dependencies, classification, license. |
When you install a pack, the platform creates everything on a fresh main branch in your organisation. Bindings that ship with logical source names need to be mapped to your workspace's managed tables on first use.
Built-in packs
Scrydon ships a small number of packs out of the box. Common ones:
knowledge-base— links knowledge-base pages and managed tables to typed Objects.process-flows— typed Objects for ISO 27001 / ISO 42001 process tasks (review cycles, audit cycles).
These are installed automatically the first time you open the workbench.
Domain packs
Domain packs are pre-built for specific verticals:
fraude-intelligence— financial-services AML/fraud-detection objects:Transaction,Customer,SuspiciousActivityReport,RegulatedEntity,Supervisor. Six pre-built bindings against typical silver tables.nato-maritime— maritime-defence objects:Vessel,AISContact,Incident,Region.iso-quarterly-review— quarterly compliance review tasks.iso-yearly-review— yearly compliance review tasks.
See Examples for end-to-end walkthroughs of these packs.
Installing a pack — two-stage model
Pack install splits in two: an org admin admits the pack to the org's catalog (Stage 1), and workspace users pick what to materialize in their environment (Stage 2). Ontology content is org-wide and lands at Stage 1; data sources are per-environment and land at Stage 2.
Stage 1 — Admin uploads the pack (org-wide)
From Settings → Packs:
- Drag-drop your
.bundle.tar.gz. - Review the bundled ontology + data-source contributions.
- Click Publish.
The platform admits the pack to the catalog. Any ontology
contributions are installed immediately org-wide (object types, link
types, bindings appear on main). Any data-source contributions
are catalogued but not yet materialized — no data_source row,
no ingest schedule, no Dapr tick.
Each catalog row summarizes what the pack contributes as colored badges — N ontologies, N workflows, N process flows, N data sources, N KB domains. Click a badge to see the detail behind the count (workflow names and block counts, data-source vendors and columns, KB domain slugs); click the row itself to open the full pack detail sheet.
Stage 2 — Workspace user instantiates a data source
From the Marketplace in apps/analytics, while in a workspace +
environment:
- Pick a data source from a catalogued pack.
- Click Install in this environment.
- The data source materializes in your env and starts ingesting on schedule. Operate it from Analytics → Data Sources.
Data-source-only packs (no ontology) are a no-op at Stage 1 beyond catalog admission — the upload completes silently and the data source appears in the marketplace for users to pick.
Packs with only workflow / process-flow content still install via the agentic Process Templates / Workflows pages.
Mapping bindings to your data
Most packs ship bindings with logical source names — e.g. "silver_table:regulated_entities". After install, you map each logical source to a real managed table in your workspace:
- Open the Bindings tab.
- Find a binding showing Not ready — table not registered.
- Click Pick table and choose the matching managed table.
The platform highlights exact-name matches so the picker is nearly one-click for the common case.
Authoring a pack
Packs are authored with the Ontology Authoring SDK. The SDK lets you:
- Define object / link / action types with TypeScript + Zod.
- Bundle them with bindings, manifest, and assets.
- Build a
.bundle.tar.gzthat's uploadable through the marketplace.
The same artefact ships first-party packs and customer-authored packs — there is no separate path.
Pack lifecycle
End-to-end, a pack travels from a TypeScript project to typed entries on main in your workspace. The platform validates at every hop; bindings that need workspace-specific table mappings remain pending until an admin completes them.
The split between Apply ontology, Apply bindings, and Apply workflows is real — each kind has its own applier inside the platform, so a pack can ship any subset (ontology-only, bindings-only, or a full vertical preset).
Related
- Branches & proposals — how pack installs and updates land on
main. - SDKs → Authoring → Ontologies — write your own.
- Examples — fully-walked-through pack examples.