Capability Model

Five capability layers

1) Perception layer

Perception defines what can be ingested: text, structured data, media, and live environment state. Policy controls allowed sources, path scope, and external data origins (per policy_and_capability_model.md §3.1).

2) Cognition layer

Cognition defines planning and reasoning behavior. Cognition is non-authoritative but affects downstream risk and therefore remains policy-constrained by routing and iteration limits (per policy_and_capability_model.md §3.2).

3) Action layer

Action defines side-effecting operations: tool use, code execution, filesystem mutation, UI automation, and communication. Policy controls allowlists, path scope, execution constraints, and approval requirements (per policy_and_capability_model.md §3.3).

4) Memory layer

Memory defines persistence and retrieval behavior: in-context memory, external retrieval, episodic memory, and working memory. Policy controls retention, retrieval, and redaction boundaries (per policy_and_capability_model.md §3.4).

5) Coordination layer

Coordination defines specialist delegation and workflow orchestration. Policy controls allowed specialists, delegation depth, fan-out limits, and workflow classes (per policy_and_capability_model.md §3.5).

Six side-effect classes

Side-effect classes are the atomic governance labels used by permits and policy rules:

Each governed operation maps to one or more side-effect classes (per GP-001, governed_execution_spec.md §3).

No implicit capabilities

Capabilities must be explicit. There are no implicit grants (per PC-002).

If an operation performs multiple side-effect classes, all must be declared and governed. Undeclared capability behavior is denied by default (per PC-003, INV-PC-001).

Provider policy model

Minimum provider classes (per policy_and_capability_model.md §4.2):

• local
• approved_hosted
• restricted_hosted
• blocked

Routing is policy-driven and capability-based. Egress and redaction constraints are part of policy, including what may leave the system and which provider classes may receive it (per policy_and_capability_model.md §4.4 and §4.5).

Capability declaration in specialists

Every specialist definition must declare enforceable boundaries (per autonomy_and_specialist_orchestration_spec.md §4):

• capability scope (tool allowlist, action authority tier, output contract)
• jurisdiction (domain and data boundaries, handoff conditions)
• identity and trust (stable versioned identity, trust tier, credential scope)

Invalid specialist definitions are prohibited (per autonomy_and_specialist_orchestration_spec.md §5):

• prompt-only definitions without enforceable boundaries
• capability declaration without jurisdiction
• undefined handoff conditions

All delegation and orchestration remains policy- and permit-governed. There is no delegation bypass path (per AS-005).