Glossary
Terms used across Cadence docs and the codebase.
Intended audience: Stakeholders, Business analysts, Solution architects, Developers, Testers
Learning outcomes by role
Stakeholders
- Look up terms quickly when reviewing decks or contracts referencing Cadence.
Business analysts
- Align vocabulary across requirements and support documentation.
Solution architects
- Disambiguate integration jargon when comparing to other platforms.
Developers
- Navigate to deep dives from glossary entries.
Testers
- Build a shared lexicon for test case titles and defects.
Alphabetical reference for jargon used in this documentation. For behavior detail, follow the links to Concepts and Features. When a page cites internal module paths, those refer to the Python API service tree under src/cadence/. Documentation audiences describes how docs are structured and how optional repository maps are versioned.
AI App
Section titled “AI App”One configured agent runtime for an org: framework, mode, plugins, and pool tier—identified by instance_id. In API paths and older code this is still named orchestrator (for example GET /api/orgs/{org_id}/orchestrators/{instance_id}). See AI Apps.
AI agent
Section titled “AI agent”User-facing name for a plugin ZIP attached to an AI App: uploaded to an org or system catalog, referenced via active_plugin_ids, and loaded into the pool at runtime. The implementation artifact is still a plugin in APIs and code (/api/.../plugins, BasePlugin). See AI Agent system.
API key (cdk_)
Section titled “API key (cdk_)”Long-lived automation secret stored hashed in PostgreSQL. Callers send it in X-API-KEY; effective access follows the key’s scopes and the owning user’s org memberships. See API keys.
Bootstrap
Section titled “Bootstrap”The first node in the grounded mode graph. Loads anchor context for a specific resource_id before the router classifies intent. See Engine internals.
Central point
Section titled “Central point”Platform abstraction for a stable routing entry (alias) to an AI App configuration, with optional public visibility—see Central Points.
Config hash
Section titled “Config hash”SHA-256 digest of an orchestrator’s effective configuration. Used by the pool to detect stale loaded instances and deduplicate reload events. See Orchestration backends.
Demand pool
Section titled “Demand pool”TTL-based cache for on-demand orchestrator instances. Instances are loaded from the database on first chat request and evicted after an idle timeout. See Hot-reload and AI App pool.
Error code
Section titled “Error code”Stable PREFIX-NNNN identifier in API and engine error payloads (code in JSON). See Error codes.
Event bus
Section titled “Event bus”RabbitMQ topic exchange (cadence.orchestrators) used for multi-node coordination of orchestrator lifecycle, settings changes, and plugin distribution. See Event system.
Graph state
Section titled “Graph state”TypedDict that carries data between LangGraph nodes during graph execution. Contains message history, agent hops, tool rounds, routing decisions, and error state. See Engine internals.
Hot and demand (pool tier)
Section titled “Hot and demand (pool tier)”Controls how eagerly an AI App stays in the process pool—hot instances load at startup; demand instances use the TTL-backed demand pool. See Hot-reload and AI App pool.
Hot pool
Section titled “Hot pool”Permanent resident orchestrator instances loaded at startup. Hot-tier instances have the lowest latency because they are always in memory. See Hot-reload and AI App pool.
JWT and jti
Section titled “JWT and jti”Access tokens for interactive users are JWTs. The claim jti (JWT ID) is the Redis key used to load the live session; revoking Redis invalidates the token even if the JWT string still verifies. See JWT sessions.
Node config
Section titled “Node config”Per-node LLM model override settings within mode_config. Allows using different models for different graph nodes (e.g., a cheap model for routing, a powerful model for synthesis). See Engine internals.
Org (tenant)
Section titled “Org (tenant)”An organization—the unit of isolation. Data and AI Apps are scoped by org_id. See Multi-tenancy.
Overridable
Section titled “Overridable”Settings cascade flag. When false on a global setting, orgs cannot override it. When false on an org setting, instance config cannot override it. See Settings cascade.
Plugin
Section titled “Plugin”Technical name for the ZIP package format: a BasePlugin subclass that supplies tools to the agent graph. In product documentation this is often called an AI agent; REST paths and code still use plugin (for example /api/orgs/{org_id}/plugins). See AI Agent system and AI Agent SDK.
Plugin bundle
Section titled “Plugin bundle”Loaded plugin package containing tools, agents, and settings. Bundles are cached and loaded by the SDKPluginManager at orchestrator build time. See Orchestrator load and plugin settings.
Role-based access control: roles carry permission strings (cadence:…) evaluated per org. See Role-based access control.
sys_admin
Section titled “sys_admin”Platform superuser flag on the session; bypasses normal org checks where implemented. See Security and access.
Settings cascade
Section titled “Settings cascade”Four-tier configuration resolution: system defaults (Tier 1) → global settings (Tier 2) → org settings (Tier 3) → instance config (Tier 4). See Settings cascade.
TokenSession
Section titled “TokenSession”Redis-backed view of the caller (interactive or API key): user id, permissions, org memberships, and related fields. See JWT sessions and Security and access.
Tool collector
Section titled “Tool collector”Gathers all plugin tools at orchestrator build time. Deduplicates tool names and appends a synthetic call_synthesizer tool for the planner. See Engine internals.
X-ORG-ID
Section titled “X-ORG-ID”HTTP header selecting which organization a request targets when the path does not embed {org_id}. See Multi-tenancy.