Packs

A pack is how Scrydon ships organisation defaults — a reusable, opinionated preset that an org installs once and everyone inherits. Today a pack contains 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-base pack wires uploaded pages and managed tables to typed Objects.
• Process flows — the process-flows pack 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

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:

1. Drag-drop your pack archive — .scrydon-pack.tar.gz / .tgz or .zip. Archives whose files sit inside a single top-level folder (as produced by "download as ZIP" or tar czf pack.tar.gz my-pack/) work as-is, and OS metadata files (.DS_Store, __MACOSX/, AppleDouble ._*) plus top-level docs files (README.md, LICENSE, …) are ignored.
2. Review the pack's ontology + data-source contributions.
3. 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 installs into an environment

The Analytics → Marketplace page is the single Stage-2 surface. It lists everything installable into the current workspace environment, one row per installable unit, with a content type column and filter (All / Data sources / Ontologies) plus free-text search. Each pack appears once, at its latest version, and rows are grouped by state — Updates available, Available to install, and Installed — so you can install or upgrade from one place:

• Data sources — one row per data-source entry in a catalogued pack. Click Install and the data source materializes in your env immediately (a first sync runs right away — you don't have to wait for the next scheduled poll) and then keeps ingesting on schedule. When a newer pack version is available the row shows Update to vX; clicking it reconciles the whole pack's data-source set to the new version: existing sources get the new manifest (and re-materialize their tables), sources the new version adds are installed, and installed sources the new version removed are pruned (their tables are kept — drop them from Analytics → Data Sources if no longer needed). Fresh installs stay per-source: clicking Install on one row never installs the pack's other sources. Operate sources from Analytics → Data Sources.
• Ontology packs — Scrydon-shipped packs and org-catalog packs that contribute ontology content. Click Install to enable the pack's object types, link types, and bindings in this environment. Rows show the pack's signature (Scrydon / Org-signed / Unsigned) and flag when a newer version than the installed one is available. (The Browse Marketplace button on the Ontology Designer links here — it used to open an in-page pack browser.)

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 Flows / Workflows pages and are not listed in the analytics marketplace.

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:

1. Open the Bindings tab.
2. Find a binding showing Not ready — table not registered.
3. 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.
• Package them with bindings, manifest, and assets.
• Build a .scrydon-pack.tar.gz that'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.