Stigg Governance — Per-Entity Budget Enforcement

Governance layers per-entity budget enforcement on top of Stigg credits and features. Where credits answer "how much can this customer consume?", governance answers "how much can this customer's own sub-units consume?" — whatever the vendor needs to budget, with hierarchical roll-up and hard-limit enforcement. The entity model is arbitrary and customer-defined — Stigg imposes no fixed hierarchy, so don't assume one (see Step 1).

You drive Stigg governance through the Stigg MCP — the execute tool runs SDK code, search_docs resolves exact shapes. That's how the agent explores, configures, and test-checks governance: entity types, entities, assignments, tree queries, and one-off checks all go through execute using the SDK's beta namespace (e.g. client.v1Beta.…). Production runtime enforcement is separate: the live entitlements check that gates real customer requests runs on the vendor's hot path via the Stigg SDK/edge, not through the MCP — the MCP is for agent-side setup and exploration, not the request-time gate. This skill owns the mental model; it does not cover connection, keys, or setup — those belong to the stigg-mcp skill.

Private-beta surface. Governance is currently a private-beta part of the Stigg API. Its shape may change at GA, so re-check exact routes and field names via search_docs rather than treating anything here as permanent.

Step 0 — Preflight: Is Governance Enabled? (do this FIRST)

Run ONE probe via the MCP execute tool: client.v1Beta.entityTypes.list() (no customer id needed).

• Fails with error code GovernanceNotEnabled → STOP. Tell the user to contact Stigg to enable Governance. Do not retry or work around it.
• Succeeds → proceed to Step 1. An empty list is expected — nothing is configured yet.

Step 1 — Elicit the Model: ASK, Don't Assume (do this BEFORE defining entity types)

The governance entity model is fully arbitrary and customer-defined. There is no default hierarchy — Stigg ships none, and any dept/team/agent shape is just one possibility, not a template. Before defining a single entity type, ask the customer what they want to govern and build strictly from their answer. Do not propose or assume a hierarchy. Ask: