Packs

A pack is declarative domain knowledge: markdown + YAML/TOML assets described by a pack.toml manifest, plus a thin __init__.py entry-point shim that registers the pack with the engine. Domain logic lives in templates and operations; executable code lives in operators, never in domain packs.

The manifest (pack.toml)

• [pack] — name, version, description, tags, plus classification: kind (domain / operator / service_provider / knowledge), publisher, trust_level (builtin / official / community / private / local).
• [assets] — relative paths to templates, prompts, skills, policies, schemas, triggers, evals, rag, memory, examples, data.
• [requires.*] — what the pack needs from the platform: required_capabilities, required_mcp, required_memory, required_artifacts, required_rag, optional_capabilities.
• [provides] — what it contributes: templates, capabilities, policies, triggers.
• [operator."<pack>/<name>"] — for operator packs, one table per operator: schemas, runtime flags, risk, executors, requires_approval.
• [demo.*] / [eval.*] — tiered runnable demo payloads (easy / medium / complex) and eval recipes, so a pack is try-able and scorable out of the box.

Templates — three flow types

A template is a markdown file with YAML frontmatter that compiles to a graph:

flow.type	Shape
prompt	one LLM call with structured output
agent_loop	a ReAct-style tool-using agent
state_machine	a behavior tree of deterministic steps and gates, compiled to LangGraph — the flow type every flagship workflow uses

Templates are referenced by namespaced ref: <pack>/<template>, e.g. training/finetune.

Skills — binding triggers to templates

A skill binds trigger conditions to a template: its frontmatter carries triggers (match patterns, manual: true/false, schedules, subscribed bus topics), the template ref it fires, and optional action_candidates and memory settings. One trigger source can fan out to many skills.

Packs can also ship per-source trigger specs (triggers/*.yaml) that declare webhook ingress — payload verification, normalization, match rules, input mapping. See Triggers & scheduling.

Policies

Packs ship default policy YAML (e.g. “all high-risk actions require human approval”, “production rollbacks need a senior approver”). Policies gate actions, not templates — see Governance.

Domain packs that ship today

Pack	Templates	What it does
training	finetune, finetune-remote, train (+ smoke/e2e variants)	Governed fine-tuning: dataset gate → train (local CPU/MPS or remote GPU) → model-eval gate → durable HITL promote → cited report
dataset-readiness	check, prep	Dataset go/no-go gate (format, dedup, decontamination, PII, profile, provenance) and a governed prep pipeline (scrub → split → verify → gate → optional HITL review)
compress	quantize	Baseline → quantize → re-eval → delta gate vs a regression budget → HITL promote
serving	serve	Deploy base + LoRA behind a vLLM endpoint on an SSH GPU box, then load-test it
incident	incident-rca, orchestrated-incident, post-incident-postmortem	Deterministic-evidence incident RCA, orchestration, and blameless postmortem drafting
security-triage	triage-alert	Grounded alert triage over the security knowledge role
security-kb	— (knowledge pack)	Ships a governed RAG corpus (condensed ATT&CK notes) providing the security role

Scaffolding and validation

cairn init pack my_pack          # new pack skeleton
cairn init template my-flow      # add a template stub
cairn validate ./my_pack         # offline: no LLM, no backend
cairn test ./my_pack             # the pack's pytest suite
cairn ls my_pack                 # what it contributes once installed

Packs install as wheels; cairn.lock pins the shipped pack closure by content hash (cairn lock --check is the CI gate).