Stigg Governance — Per-Entity Usage Limits

Governance layers per-entity limit 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 limit, 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, entity entitlements, tree queries, and one-off checks all go through execute using the SDK's v1 namespace (client.v1.…). 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.

Governance is GA on the v1 API. Use the client.v1.* calls. The client.v1Beta.* governance calls still work but are deprecated. One exception: the governance tree query has no v1 version and stays on client.v1Beta. For existing v1-beta code, see Moving from v1-beta below.

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:

• What units do you limit? (their own vocabulary — teams, projects, regions, tenants, sub-accounts, cost centers, agents, workspaces…)
• How do they nest / roll up? (which contains which, and how deep — the tree caps at 8 levels)
• Which levels actually carry limits? (only levels that hold a limit or need roll-up belong in the tree; fold the rest away)
• What identifies a unit on a usage event? (the dimension key(s) your events already emit — these become the attribution keys)

Model from their answer: "we limit by project, and projects belong to a client" → build client → project. Every worked example below and in the references is one possible model — it teaches the API's shape, never the model to adopt.