Glossary

The Scrydon documentation uses precise terminology. This page is the single reference for what each term means.

Tenancy

Organisation — the top-level tenant boundary. Every user, workspace, integration, audit event, and managed table lives inside exactly one organisation. There is no path that crosses organisations.

Workspace — a scoped collaboration unit inside an organisation. Workspaces hold workflows, automations, knowledge bases, and team grants. A user can be a member of one or more workspaces.

Team — a named collection of users, used for scaling access grants. SCIM-provisioned groups map to teams.

Work units

Workflow — a multi-block program on the canvas. Triggered manually, by chat, by API, by schedule, or by webhook. See Architecture → Agentic.

Automation — a single-agent job. Prompt + tools + trigger, that's it. The simpler sibling of a workflow. See Automations.

Process flow — a reusable, opinionated workflow with stages, tasks, and personas. Process flows are authored with the Process Flow SDK and distributed through the marketplace.

Run — a single execution of a workflow or automation. Identified by a runId; logged in the audit log; bound to an execution grant.

AI

Agent (block) — the canvas block that calls an LLM. Resolves its model through the integration registry. See Blocks → Agent.

Tool — an operation an Agent can call. Vendor products contribute tools (gmail.send, slack.post-message, scrydon.knowledge-rag-search). See Vendors.

Capability — a typed runtime interface (LLM, STT, TTS, embedding, image, video, OCR, webhook, discovery). Capabilities are how the integration registry resolves "an LLM" to a specific provider. See Integrations → Capabilities.

Cortex — the internal LLM gateway. Every LLM, embedding, or image call from inside the cluster goes through it. Workflows don't call it directly. See Architecture → Cortex.

Integration model

Vendor — a third-party (or first-party) system Scrydon talks to: Google, OpenAI, Salesforce, Mistral, the built-in scrydon. Owns products.

Product — a grouping unit owned by a vendor (google → gmail, microsoft → outlook). One product contributes one block, plus its tools, triggers, and capabilities. The unit of enable / disable.

Integration registry — the catalogue of installed vendors and the resolution order (per-call override → org policy → automatic pick → null). See Capabilities.

Pack (ontology) — a reusable ontology bundle: object types, link types, action types, and bindings, packaged together. See Ontology → Packs.

Data

Managed table — a Scrydon-owned, typed, governed table. Created by upload or by an agent. See Analytics → Managed tables.

Knowledge base — a workspace-scoped store of unstructured documents (markdown, PDF, …) used for retrieval-augmented generation. See Knowledge base clearance.

Object type — a typed entity in the ontology layer (Customer, Transaction). See Ontology → Object types.

Link type — a typed relationship between two object types (Customer → owns → Account). See Ontology → Link types.

Action type — a typed server-side mutation gated by the policy decision point (AssignAsset, FileSAR). See Ontology → Action types.

Binding — the rule that tells the ontology how to materialise a typed Object from a real source (a managed table, a knowledge-base page). See Ontology → Bindings.

Branch (ontology) — a versioning unit. main is the published baseline; edits go through proposal branches. See Branches & proposals.

Security

Permission model — the three-tier hierarchy (org role → direct workspace membership → team-based grants). See Permission model.

Clearance — NATO-style document classification on knowledge-base documents (UNCLASSIFIED, RESTRICTED, CONFIDENTIAL, SECRET, TOP SECRET). Tied to the user's org role. See Knowledge base clearance.

Classification — the data-sensitivity label on a managed table or column (public, internal, confidential, restricted). Distinct from clearance. See Classification & masking.

Execution grant — a short-lived server-issued token that authorises a workflow instance's actions. Bound to a single run; the runtime never trusts identity in the payload. See Authorization.

Policy decision point (PDP) — the single component that decides every authorisation question. Backed by Rego for data-plane reads. See Authorization.

DLP — Data Loss Prevention. The Guardrails block + secrets vault + network boundary + audit, together. See Security.

Deployment

Customer cluster — your Kubernetes cluster where Scrydon runs. The trust boundary.

Scrydon namespaces — the Kubernetes namespaces Scrydon creates (scrydon-platform, scrydon-agentic, scrydon-analytics). All customer data lives here.

License heartbeat — the daily POST to license.scrydon.com that validates your license. The only outbound traffic Scrydon requires. See Licensing.

Phone-home — synonym for license heartbeat. Sometimes used in the broader sense of "any outbound call" — in Scrydon's case, the only phone-home is the license heartbeat.

Air-gapped — a deployment mode with no outbound network. License is offline-only, Copilot is unavailable, integration registry is restricted to self-hosted providers. See Deployment → Air-gapped.

Related

• Concepts → Ontology — deeper dive into ontology terms.
• Architecture — how the system pieces fit together.
• Security — security terms in their operational context.