Governance Overview

Governance in Stackmint is not a single feature — it is a set of interlocking controls that operate at different points in the execution lifecycle. The goal is controlled autonomy: AI workflows that can run without constant human supervision while remaining bounded by organizational policy.

Governance philosophy

Stackmint is built on the premise that the right response to AI risk is not to slow everything down, but to define precise boundaries and enforce them automatically. A workflow that operates within its governance envelope should run without friction. A workflow that approaches a boundary should trigger an escalation. A workflow that violates a boundary should be stopped.

This means governance must be:

• Declarative — Policies are defined in Manifests and configuration, not embedded in code
• Enforceable at the platform level — Governance cannot be bypassed by the Capability author or the end-user
• Auditable — Every governance decision (approval, rejection, budget deduction, model switch) is logged immutably
• Proportional — Low-risk workflows run autonomously; high-risk operations require explicit human approval

Governance layers

Model layer — The model allow list defines which AI models can be called within the Workspace. This operates as a hard allowlist: any Bud attempting to call an unlisted model is rejected before the API call is made, with zero cost incurred. Model routing rules can further restrict which Capabilities or teams can access which approved models.

Budget layer — Credit budgets are allocated at the Workspace, team, Capability, and Branch levels. These are hard ceilings — executions that would exceed their budget ceiling are terminated before any model calls are made. Budget deductions are atomic and immediate upon execution completion.

Access layer — Role-based access control determines who can trigger which Capabilities. Capability Manifests declare allowed roles; the platform enforces these at the Surface level. Users cannot trigger Capabilities they are not authorized for, regardless of how they attempt to access them.

Approval layer — Human-in-the-Loop checkpoints pause execution before sensitive Buds run and route approval requests to designated approvers. Execution resumes only after an explicit approval decision. Rejections terminate the execution with an audit trail.

Audit layer — Every execution produces an immutable, cryptographically sealed audit trace. The trace records inputs, model calls, Bud outputs, budget deductions, approval decisions, and execution timing. Audit logs cannot be modified or deleted.

Kill switch

When a governance boundary is crossed in a way that cannot be handled by normal policy enforcement (e.g. audit seal tampering, unexpected high-privilege Bud behavior), the kill switch terminates the execution immediately and marks it as kill_switch_tampered. This state is terminal — the execution cannot be resumed. See Kill Switch.

Governance by Capability

Governance configuration is applied at the Capability level via the Manifest. This means different Capabilities installed in the same Workspace can have different governance profiles — a low-risk reporting Capability might run fully autonomously, while a high-risk CRM-writing Capability requires HITL approval for every sensitive Bud call.