System · Authority & Capability Control

OSA Execution Force: authority before mutation

Execution Force controls the path from task to action. Policy, repository, scope, source provenance and the exact downstream payload are bound before a mutation-capable runtime can proceed.

CLAIM ≠ PROOF. No evidence = UNKNOWN.

Execution Force separates authority from the downstream engine. GODMODE V3 resolves the policy and card, binds the task to repository, scope, source SHA and payload, then authorizes the exact RuntimeV2 execution path.

TASK → GODMODE V3 → CARD / POLICY → bound repo + scope + source SHA + payload digest → RuntimeV2 → host action → evidence / verification

The documented P0 invariants deny a direct RuntimeV2 mutation path before V3 authorization, reject modified policy payloads, prevent scope widening and require an exact source commit SHA for provenance.

The committed registry contains 150 operational cards across 14 engineering domains. The catalog is a policy surface, not evidence by itself; the authority wiring is tested separately.

The repository publishes a dedicated authority workflow and launcher provenance proof for the project-scoped Claude Code path. It also states what is not claimed: P0 is not a universal enforcement proof across every host and does not establish production readiness.

  • A direct RuntimeV2 run before V3 authorization is denied.
  • RuntimeV2 state alone cannot authorize repository mutation.
  • V3 authorization is bound to the exact downstream RuntimeV2 payload.
  • A modified policy payload is denied.
  • Repository and file scope are bound and cannot be widened downstream.
  • A new V3 authorization invalidates the previously opened downstream action.
  • source_commit_sha must be an exact 40-character Git SHA; missing or UNKNOWN provenance fails closed.
  • Commit/push finalization still requires live V3 authority plus downstream verification.

The repository publishes an OSA V3 Authority Proof workflow. The checked launcher emitted V3_LAUNCHER_PROVENANCE_PASS, bound a concrete source commit SHA and policy payload, then ran the V3 hook authority suite with 11 passed.

The full backend, acceptance, migration, container and security gates remain separate. The dedicated P0 workflow proves the checked authority wiring; it does not replace every other validation gate.

The committed V3 registry contains 150 unique operational cards covering foundation, backend, data, frontend, mobile, cloud, AI/ML, security, engineering practice, SRE, gamedev, Web3, product and low-level systems. The committed registry under osa-execute/runtime/cards/ is treated as the live repository source of truth.

The canonical MCP authority operation is osagm_authorize. Successful authorization binds the selected card, policy, source commit SHA, repository, allowed scope, task digest and exact downstream RuntimeV2 payload plus its digest.

CLAIMED ↓ ARTIFACT_PRESENT ↓ MECHANICALLY_VERIFIED ↓ INDEPENDENTLY_VERIFIED

The repository explicitly does not claim universal production readiness or universal enforcement across every host and deployment topology. The P0 result is project-scoped and evidence-scoped.

Discuss a scoped pilot for capability gates, policy binding and evidence of authorized actions.

Discuss an AI agent pilot →