Skip to main content

Policy, Quota, and Entitlements Service implemented

This service family answers three different questions that are easy to blur:

  • are you allowed to do the thing;
  • do you still have quota for the thing;
  • is there physical/runtime capacity for the thing right now.

The platform keeps those separate so admission can fail for the right reason.

Scope Hierarchy​

global/platform
  -> plan
    -> organization
      -> department
        -> project
          -> principal or api key
            -> request

Lower scopes can specialize or narrow. They do not raise a parent ceiling unless that authority is explicitly delegated.

Service Boundary​

CapabilityOwned hereAdjacent service
Policy valueseffective limits and decision rulesIAM, Billing, Product facades
Entitlementswho can use which product/resource/actionIAM and product access flows
Quota compositionhierarchy-aware usage ceilingsBilling and product usage signals
Capacity reservationspre-allocated intent, not money movementschedulers, provider inventory, runtime pools

Decision Contract​

Every decision should be explainable from the same input shape:

  • actor type, id, roles, scopes;
  • organization, department, project;
  • product, resource type, action;
  • requested delta and usage unit;
  • current usage snapshot;
  • registry versions and correlation ID.

Output must name:

  • allow, deny, or warn;
  • reason code;
  • user-safe message;
  • effective ceiling and inherited scope;
  • matched rules and evidence version.

Why This Matters​

If the platform says “launch blocked,” the operator and the customer need to know whether that came from:

  • policy hard deny;
  • quota exhaustion;
  • missing entitlement;
  • stale snapshot;
  • no physical capacity.

This service owns that distinction.

Dimension Families​

Dimension familyExamples
Computeactive allocations, GPU count, vCPU, memory GiB
App runtimeinstance concurrency, runtime hours, route count
Token/requestRPM, TPM, endpoint concurrency
Storagebucket bytes, volume bytes, object count
Networkpublic endpoints, ingress rules, egress
Capacity reservationreserved GPU SKU, model concurrency, app pool slots

Decision Flow​

Design Constraints​

  1. Quota is not ledger.
  2. Capacity reservation is not billing.
  3. Usage units must be registry-backed.
  4. Overrides that raise limits are privileged mutations with audit.
  5. Missing or stale snapshots fail closed on launch-sensitive paths.

What Reviewers Should See​

PersonaRequired conclusion
Productcommercial packaging is not hardcoded into handlers
Securitydeny and override paths are reviewable and auditable
Architecturepolicy/quota logic is shared-platform, not duplicated per product
Developersnew products must register units/dimensions instead of inventing literals
Canonical sources