Resource Governance

Operator reference. Org members read their own org's data through the org endpoints described below.

Resource Governance (biome id resource-governance) is a base biome that keeps an authoritative, substrate-neutral inventory of resources, records usage against them, tracks how fresh each source is, and records the cost inputs that feed cost attribution. Resource-owning services stay the lifecycle authority: this biome stores normalized observations and read projections, and does not create or delete resources.


How producers feed it

A service that owns resources registers as a producer: it declares a revision and an allow-list of resource definitions. It then submits versioned resource-accounting envelopes. The protocol is xema.dev/resource-governance revision v1, and its operations are:

OperationPurpose
definitions.syncSync resource definitions
producers.registerRegister a producer
inventory.observeReport inventory observations
inventory.snapshot-page, inventory.snapshot-completeReport a full snapshot in pages, then complete it
usage.ingestIngest usage batches
provider-cost.observeReport provider cost
admission.reserve, admission.transition, admission.queryReserve capacity, move a reservation, and query it
rolling.correctAppend a rolling-consumption correction

The rules the source states:

  • The verified service-token client id must match both the producer principal and the audience.
  • An incomplete snapshot never retires inventory. Only an explicit complete snapshot can prove that an item is gone.
  • Resource definitions arrive only through the shared owner-scoped contribution sync. A resource key is permanently claimed by the biome that contributes it, and a changed manifest creates a new immutable revision.
  • Usage and provider-cost facts are append-only. A correction is a new signed row, and database triggers reject in-place changes.
  • Provider cost is a platform-internal cost-to-serve input. It is never the customer price.

What an org member can read

For the active organization: an accounting summary, current and retired inventory, and the immutable usage rows and corrections. Resource definitions are listed too.

Limits and admission

Organizations' policies and limits are control-plane data, not environment variables. Operators create immutable policy bundle revisions, activate them against a target, and preview a policy. Activation uses a compare-and-set. An org can resolve its effective limit and list its reservations. A project, user or application limit can be delegated, and a delegated limit can only be lower.

A producer reserves capacity atomically under the effective policy. It then commits, releases or cancels the reservation, and each transition is idempotent. This page does not list what a reservation refuses, because the source summaries do not say.

Operators can also define cost-allocation policies.

Release plane and retention

The biome also hosts the release plane for authored resources: publishing revisions, resolving an exact dependency closure, and requesting, rolling back, retiring and resuming releases, with an impact preview and release history. Each governed release request first asks an authorization gate. The biome contributes that gate as the capability authored-resource:release.promote@1, of risk tier high. The verdict decides whether the promotion may proceed, and whether it must first carry an approved decision. It carries an explicit-only human baseline.

Operators manage retention policy bundles and activations, entitlement bounds and legal holds. The service also supports org data erasure (xema.org-data-erasure).

Declarations

  • Capability domains owned: legal-hold and resource.
  • Event namespace: resource-governance.
  • Subscribed events: decision.decision.closed and decision.decision.committed.

Previous: ← Topology