# Govern Resource usage

> Return typed Resource controls and hard admission limits from executable Policy packages.

## Before you begin {#before-you-begin}

Governance narrows an invokable Resource's immutable baseline. It does not change Resource configuration, provider selection, pricing, credentials, or wallet balance. Identify the target Resource's governance contract and decide which controls or admission limits the Policy must narrow. Unknown controls, meters, contracts, or unenforceable combinations deny before dispatch.

## Steps {#steps}

1. Use the contract's typed helpers from executable `policy()` code. This example applies sandbox controls and a customer-scoped concurrency limit:

   ```ts
   import { policy, sandboxControls, sandboxLimit } from "@constal/sdk";

   export default policy({
     id: "customer-sandbox-boundary",
     version: "1.0.0",
     evaluate(input) {
       const allowed = input.action === "resource:invoke"
         && input.context["resource.operation"] === "exec";
       return allowed
         ? {
             kind: "constrain" as const,
             constraints: [
               sandboxControls({
                 cpu: 2,
                 memory_gib: 4,
                 command_timeout_ms: 120_000,
                 network_mode: "domain-allow",
                 network_domains: ["api.example.com"],
               }),
               sandboxLimit({
                 id: "customer-concurrent-commands",
                 meter: "commands",
                 scope: "customer",
                 window: { kind: "concurrency" },
                 maximum: 3,
                 continuity: "target",
               }),
             ],
           }
         : { kind: "deny" as const, code: "operation-denied", reason: "operation denied" };
     },
   });
   ```

   `sandboxControls()` and `sandboxLimit()` pin the exact built-in sandbox governance contract. `modelControls()` and `modelLimit()` do the same for Models. A custom Resource package publishes its contract and typed helpers together.
2. Choose a trusted scope for each admission limit: `run`, `session`, `subject`, `customer`, `tenant`, `binding`, or `resource`. The platform derives the identity from authenticated authority and the accepted Run snapshot; Policy code and Agent arguments cannot supply it.
3. Choose a concurrency window for simultaneous work, a fixed window for bounded rates, or a lifetime window for a durable total. `continuity: "target"` preserves the limit authority across ordinary Policy and Resource revisions. Use `target-version` only when a Resource revision intentionally needs a separate counter.
4. Unit test an allowed invocation and failures for an unknown contract, control, meter, or unenforceable combination.

## Verify {#verify}

Invoke the selected Resource and confirm the invocation records its effective governance hash and admission receipts. Confirm the provider receives only effective controls for the exact contract and returns enforcement evidence. The platform must reserve admission limits and billing leases before the external effect; provider-specific compute, network, filesystem, token, or connection enforcement stays inside the provider integration.

## Next steps {#next-steps}

Continue with [Author a Policy](/docs/policies/author.md) for the package and target-selector workflow, or [Operate Policies](/docs/policies/operate.md) to inspect selected Resources. Governance uses the existing selector, Policy, Resource invocation, and provider path; it does not introduce a second limit service or Resource-specific admission endpoint.