# CAIN-42 Evolution 14 — Capability Governance
## Trust model, authority model, capability model, verification, reproduction, performance, limitations

**CAPABILITY IS POWER. POWER MUST BE BOUNDED. BOUNDED POWER MUST BE AUTHORIZED. AUTHORIZED POWER MUST BE VERIFIED
AT EXECUTION. UNVERIFIED POWER MUST NOT EXECUTE.**

### 1. The four distinctions (implemented, not just stated)

| Stage | Produced by | Grants execution? |
|---|---|---|
| **Discovery** | `fabric.discover`, `MCPProtocolAdapter.discover` | No. State `DISCOVERED`; grant refused (`C3`). |
| **Trust** | `fabric.admit` → `CapabilityPassport` | No. An admitted tool/skill/plugin with no lease is refused at the gate (`C4`–`C6`). |
| **Authority** | `CapabilityGrant` (⊆ issuer authority) | No. A grant is a ceiling, not an action. |
| **Authorization** | `CapabilityLease` + E13 decision + E8 token at `CapabilityAwareCommitBoundary` | Only here, for one canonical action, once. |

A capability can be valid and still forbidden; a trusted tool can still be unauthorized; an authorized tool
becomes unauthorized when its artifact, version, dependencies, provenance, scope, agent, trajectory, risk,
policy, environment, credentials, data boundary or delegation chain changes — each of those is either in the
manifest digest, the lease, the decision binding or the E8 token, and each has a test.

### 2. Authority model
* `effective_capability = INTERSECTION(identity, delegated, policy, trust, trajectory, environment, risk, budget)`.
  A missing envelope is empty. Never a sum. Agreement between agents adds nothing (`C22`).
* A grant cannot exceed its issuer's authority (`C7`) or the capability's declared permissions.
* A subagent's grant is a subset of its parent's, with shorter TTL, smaller budget, lower-or-equal risk ceiling,
  and depth ≤ 3 (`C8`, `C21`).
* Models, tools, skills, plugins, memory, collectives, subagents and credentials never mint authority
  (`C20`, `C22`–`C25`); what they produce is a `CapabilityProposal` with `authority: NONE`.

### 3. The commit boundary (Part 19)
`CapabilityAwareCommitBoundary.execute` runs 18 named checks — agent identity, decision, intent, policy,
authority, capability, capability version, artifact digest, lease, sandbox profile, credential binding, risk,
consequence (E7), trajectory, revocation status, expiration, nonce/replay, canonical action — and then the E8
`ActionCommitBoundary.execute`, whose TOCTOU re-check compares the token's capability digests with the **live**
digests (`fabric.live_bindings`). Any failure: DENY, recorded, and the effect does not run. A governance
evaluation that raises is a denial (`C30`).

On the hypervisor path, `AgentHypervisor(capability_gate=CapabilityGateAdapter(fabric))` re-checks the lease
before the E7/E8 hooks and the MCPGate interceptor. When the call is the execution of a commit, the lease is
"in flight" (already consumed by that commit); used directly, the hook consumes the lease itself, so it is
single-use on both paths.

### 4. Verification & reproduction
* Tests: `python3 -m pytest tests/test_cain42_e14_capability.py tests/test_cain42_e14_adversarial.py tests/test_cain42_e14_end_to_end.py -q`
* CLI: `bin/cain-agent capability audit|bench|schema|capability|passport|revoke|verify|diff|example`,
  `bin/cain-agent skill|tool|plugin|model|grant|lease|composition|dependencies|drift|sandbox|supply-chain`,
  `bin/cain-l5 e14-audit|e14-bundle|e14-verify|e14-simulate|e14-compose|e14-drift|e14-revoke|e14-supply-chain|e14-adversarial|e14-replay`.
  (`audit`, `passport`, `revoke`, `diff` already exist as Evolution 9 commands, so the E14 versions live under
  `cain-agent capability …`.)
* Bundle: `python3 scripts/cain45/build_evolution14_bundle.py` → `clawx-site/evidence/e14-capability-governance-2026-09-28/`
  mirrored byte-identically into `platform-gateway/frontend/proof/bundle/`.
* Clean-room: `python3 verify_e14.py <bundle>` — no CAIN imports; recomputes every digest and signature.
* Signing key: **EPHEMERAL** per build. Not a production trust root.

### 5. Performance
See `PERFORMANCE.json` in the bundle: p50/p95/p99 per operation with CPU model, logical CPUs, RAM, OS, Python,
process model, concurrency, warm/cold state, dataset and graph size, plus one single-host multi-process run.
These are single-host in-process numbers, not production-scale benchmarks. `MULTI_HOST_SCALE = UNVERIFIED`.

### 6. Limitations (classified: ELIMINATED / REDUCED / INSTRUMENTED / INTERFACE READY / STILL UNKNOWN)
The full register with evidence and tests is `LIMITATIONS.md` / `LIMITATIONS.json` in the bundle. In short:
* ELIMINATED: two E13 bench scenarios that were forced true; an E13 test vector that was a constant.
* REDUCED: framework adapters (MCP reference adapter; others NOT_IMPLEMENTED); lenient token bindings (E14 fields
  strict; E9–E13 fields unchanged).
* INTERFACE READY: hosted service (hypervisor hook wired; `HOSTED_SERVICE = NOT_IMPLEMENTED`); hardware attestation
  (`HARDWARE_ATTESTATION = UNKNOWN`).
* INSTRUMENTED: third-party reproduction (tools exist; no independent party has done it); sandbox enforcement.
* STILL UNKNOWN: multi-host scale; semantic truth; vulnerability intelligence; E13 trace over-inclusion; E13's
  own policy/counterfactual/private-reasoning limits.

The correct public claim is: **CAIN-42 governs capabilities and tool power surfaces that enter its trusted
governance and enforcement boundary. Systems outside that boundary remain UNCONTROLLED / UNVERIFIED / UNKNOWN.**