StackShip places deterministic controls between an OpenTofu plan and an apply. The governance surface has four implemented parts:
- immutable Rego policy publication and workspace attachment;
- policy evaluation against a sanitized plan derivative;
- an exact-evidence human approval or rejection; and
- organization-scoped audit evidence.
Cost analysis and scheduled drift detection are separate roadmap items and are not available today.
Policy
Each managed plan is followed by a policy evaluation. The evaluator receives a
sanitized derivative of tofu show -json, not raw state, variables,
credentials, configuration archives, or repository content. Published policy
versions are immutable and bound to a fixed OPA version, capabilities manifest,
entrypoint, and bundle digest.
An undefined decision, forbidden capability, timeout, malformed result, or secret-canary match fails closed and blocks apply. StackShip evaluates Rego; it does not execute Sentinel.
Approval
An approval is not a mutable flag on a run. It binds the reviewer decision to the current plan digest, dependency-bundle digest, predecessor-state identity and digest, policy-evaluation identity, and policy-result digest.
If any bound evidence changes, the old approval is stale and cannot authorize apply. Rejection binds to the same evidence and requires a reason in the dashboard.
State custody
Workspace state versions are immutable. A managed apply uses the current predecessor state in its approval and apply authorization, and only one fenced writer may publish the successor. State history and raw authenticated downloads remain available for migration.
Audit
Product mutations write organization-scoped audit records. The dashboard and v1 API return sanitized event metadata, never secret or artifact content.
Roadmap
The documentation keeps future governance work explicit: