CAPPO

Nothing crosses into consequence without authority.

CAPPO is the machine-authority kernel: it evaluates whether a requested action fits the identity, capability, policy, budget, time and execution context that were actually granted before a real effect is allowed to proceed.

Current classification
Proof surface
PROOF

CAPPO has source, adversarial harnesses and runtime proof paths for authority monotonicity, offline closure, consequence dominance and evidence synchronization. Stronger claims remain scoped to the exact verified deployment profile and consequence paths.

Architectural role
Fail-closed consequence authorization
Owns
01The ALLOW / DENY decision for consequence-bearing execution paths.
02Capability lease and attenuation enforcement at the authority boundary.
03Fail-closed checks around identity, policy, budget, replay and expiry.
04The canonical governed execution path used by the live Activation journey.
Boundary

Power stays narrow on purpose.

BYOS owns tenant/workspace runtime and user session state.
LockerPhycer owns the host-sensitive security/execution boundary.
PGL/Gnomledger owns durable evidence; cAPI/VLink own connection surfaces rather than authority minting.
Interfaces

The surface should tell you where the truth comes from.

Veklom does not promote a configured URL or a code path into a runtime claim. Interfaces are shown so operators can verify the actual boundary themselves.

Governed execution
POST /v1/exec
Capability APIs
/api/v1/cappo/*
Evidence
Execution-linked PGL / EEE paths
Doctrine
No consequence beyond authority
Claim boundary

CAPPO is not a marketing policy dashboard. Its useful claim is narrower and harder: consequence paths that have been brought under the boundary must fail before effect when authority is missing, stale, widened, replayed or exhausted.