Glossary
Definitions for every term in the Cordum platform — from core components and protocol concepts to policy patterns and workflow primitives.
Core Components
Safety Kernel
A gRPC service that evaluates every AI agent action against YAML-defined policies before execution. Returns one of six decisions: ALLOW, DENY, REQUIRE_APPROVAL, ALLOW_WITH_CONSTRAINTS, THROTTLE, or UNAVAILABLE. Every evaluation is logged as an immutable audit record.
Scheduler
The component that receives job submissions, calls the Safety Kernel for policy evaluation, routes jobs to workers using pool mapping and least-loaded strategy, and manages job state transitions in Redis.
Workflow Engine
Stores workflow definitions and manages run execution. Supports DAG-based step dependencies, parallel execution of independent steps, and an append-only timeline for every run.
Context Engine
A gRPC service for building LLM context windows and maintaining chat history and memory. Stores data in Redis under mem:<memory_id>:* keys.
API Gateway
HTTP/WebSocket/gRPC entry point for the control plane. Handles jobs, workflows, runs, approvals, policy, DLQ, schemas, locks, and artifacts. Enforces API key authentication with per-tenant scoping.
Protocol
CAP (Cordum Agent Protocol)
A language-agnostic wire protocol for AI agent communication and governance. Uses protobuf-defined BusPacket envelopes with typed payloads, context pointers, and trace IDs. Current version: CAP v2.
BusPacket
The standard envelope for all CAP traffic. Contains trace_id, sender_id, created_at, protocol_version, and exactly one typed payload (JobRequest, JobResult, Heartbeat, JobProgress, JobCancel, or SystemAlert).
Context Pointer
An opaque URI (e.g., redis://ctx/job-123) referencing the input payload stored in external memory. Large payloads stay off the message bus; only the pointer travels on the wire.
Result Pointer
An opaque URI (e.g., redis://res/job-123) referencing the output payload written by a worker after job execution. Immutable for the lifetime of the job.
Policy & Safety
Policy Snapshot
A versioned, SHA256-hashed copy of the active safety policy. Snapshots are immutable once created. Approvals are bound to a specific snapshot hash plus job hash, preventing policy bypass.
Decision Types
The six possible outcomes from a Safety Kernel evaluation: ALLOW (proceed immediately), DENY (reject with reason), REQUIRE_APPROVAL (pause for human gate), ALLOW_WITH_CONSTRAINTS (proceed with enforced limits), THROTTLE (retry after backoff delay for rate limiting), UNAVAILABLE (kernel unreachable, falls back to last-known-good policy).
Constraints
Limits enforced by the Safety Kernel on ALLOW_WITH_CONSTRAINTS decisions. Include max_runtime, max_retries, max_artifact_bytes, max_concurrent_runs, max_diff_size, and deny_path patterns.
Approval
A human-in-the-loop gate triggered when the Safety Kernel returns REQUIRE_APPROVAL. The approval is bound to the policy snapshot hash and job hash. Available at both the job level (via Safety Kernel) and workflow step level (approval step type).
Job Lifecycle
Job
The fundamental unit of work in Cordum. A job request includes a topic, priority, context pointer, capability labels, risk tags, and an optional idempotency key. Jobs flow through a defined state machine from PENDING to a terminal state.
Job States
Scheduler states: PENDING → APPROVAL_REQUIRED (if gated) → SCHEDULED → DISPATCHED → RUNNING → terminal (SUCCEEDED, FAILED, TIMEOUT, CANCELLED, DENIED). Note: FAILED_RETRYABLE and FAILED_FATAL are CAP protocol JobResult status codes used by workers, not scheduler states.
Worker
An external process that subscribes to job topics, fetches context from a context pointer, executes work, writes results to a result pointer, and publishes a JobResult BusPacket. Workers use the CAP runtime SDK.
DLQ (Dead Letter Queue)
A queue that captures failed jobs for inspection, retry, or deletion. Every non-success job result creates a DLQ entry with the full job context for debugging.
Reconciler
A background process that marks stale DISPATCHED or RUNNING jobs as TIMEOUT based on configured timeouts. Also includes a pending replayer that retries stuck PENDING jobs.
Workflows
Run
A single execution of a workflow definition. Each run has an append-only timeline recording inputs, outputs, status transitions, and policy decisions. Supports rerun-from-step and dry-run mode.
Step Types
The 16 types of workflow steps in 5 categories: Execution (llm, worker, http, container, script), Control Flow (condition, switch, parallel, loop), Gates (approval, input, delay), Data (transform, storage, notify), Composition (subworkflow). for_each is a field on any step enabling fan-out iteration, not a step type.
DAG (Directed Acyclic Graph)
The execution model for workflows. Steps declare dependencies via depends_on. Independent steps run in parallel. Steps wait for all dependencies to succeed before starting. Failed or cancelled dependencies block downstream steps.
Saga Rollback
Compensation-based rollback for failed workflows. Each JobRequest can include a compensation template (an inverse action). On FAILED_FATAL, the orchestrator dispatches compensations in LIFO order.
Extensibility & Patterns
Pack
An installable overlay that extends the platform without core code changes. Contains a pack.yaml manifest, workflow templates, JSON schemas, config overlays (JSON merge patch), and policy fragments. Installed via cordumctl pack install.
Policy-as-Code
The pattern of defining safety policies as versioned YAML configuration. Policies are hot-reloadable, support simulation and explain APIs for testing, and are persisted as immutable snapshots with SHA256 hash verification.
Human-in-the-Loop
A governance pattern where certain actions require explicit human approval before execution. In Cordum, this is implemented at both the job level (Safety Kernel REQUIRE_APPROVAL) and workflow level (approval step type).
Deterministic Execution
The guarantee that every agent action is evaluated, constrained, and recorded before reaching production infrastructure. The Safety Kernel evaluates policy, the scheduler enforces routing, and the timeline provides an immutable audit record.