Platform Narrative: Governance Action Framework

The Separation of State and Action

In the early stages of CAS, governance state transitions (like approving an ADR) required manually editing the YAML frontmatter of the artifact file. While functionally correct, this approach conflated the artifact's State with the Action of changing it, leading to operational friction as governance volume grew.

The Governance Action Framework solves this by enforcing a strict architectural principle: Artifacts store state. Actions change state. The Engine governs transitions.

The Action Engine

The GovernanceActionEngine is the centralized authority for all governance state changes. It operates on a Transition Registry that defines valid state machines for each artifact type.

For example, a Promotion Decision can transition from pending to accepted, rejected, or deferred. An attempt to transition directly from deferred to accepted will be rejected by the engine.

This engine is exposed through the CAS CLI:

cas governance approve <artifact-id>
cas governance reject <artifact-id> --rationale "Missing evidence"

Immutable Audit Trails

Accountability requires traceability. Every successful state transition executed by the engine generates a formal GovernanceAction audit record.

These records are immutable YAML files stored in knowledge/global/governance/actions/. They capture: - The exact transition (e.g., pending -> accepted) - The target artifact - The executing user identity - The cryptographic timestamp - Any provided rationale

Future-Proofing

By routing all state changes through a single, registry-driven engine, CAS is prepared for future capabilities such as UI-based "one-click" approvals in the Governance Portal or autonomous AI-driven governance decisions. All interfaces will delegate to the Action Engine, guaranteeing consistent validation and auditing.