Domains overview

A market domain defines what a listing means, which agreement and provision terms accompany it, and how a storefront fulfills and settles the agreement. Discovery, Negotiation, Settlement, and Arbitration stay fixed; the domain supplies the vocabulary — resource schema, pinned terms, optional scalar amount, fulfillment method, result form — through a versioned contract such as api_credits.v1 or bare_metal.v1. Domains do not have to live in the SCM repository: they can be Registry-maintainer packages, private organization packages, or the in-tree reference implementations.

What changes with the domain

	Virtual machines	Bare metal	API credits	Custom domain
Listing vocabulary	Compute slice: gpu_model, gpu_count, vcpu_count, ram_gb, disk_gb, region, pool reference	Whole machine: machine class, physical_host_id, machine_id, exclusive allocation	Named service and quota: service_name, units, key disposition	Versioned resource kind the author defines
Agreement and provision terms	Lease duration intent and machine-access requirements	Lease duration and whole-host access requirements	Credit quantity and key disposition	Versioned provision terms; the domain declares which fields are pinned at round zero
Optional negotiable scalar	Payment amount only, when configured	Payment amount only, when configured	Payment amount only, when configured; quantity stays fixed	Domain-declared where implemented; current Compute examples vary payment amount only
Delivery	Capacity reservation, seller-owned VM lifecycle, SSH credentials via cloud-init	SSH key grant for a tenant account on the physical host	Seller-issued bearer credential with prepaid balance behind a gated API	Domain-defined fulfillment result
Post-delivery	Lease watchdog, auto-expiry, early reclaim	Reclaim policy: remove lease key, lock user, or delete user	Per-request credit consumption; 402 once balance is spent	Domain-defined evaluation and resolution
Physical capacity path	Site admission, resource pools, scheduler assignment, provider execution	Same site authority; whole-host accounting via physical_host_id	None — no compute provisioner in the path	As required by the domain
Guide	Virtual-machine domain guide	Bare-metal seller guide	Inference API credits	Custom-domain authoring

Two properties keep this table honest at the pinned revision:

• The core is schema-opaque. Registries store offer_resource as JSON and validate only what their operator's filter-spec enables; the shared role packages never interpret domain payloads. Evidence: domain authoring and the market-composition specification.
• Delivery machinery is not universal. The physical capacity path (sites, pools, scheduling, providers) exists for physical domains; API credits deliberately reuse negotiation and settlement without acquiring compute-provisioning dependencies. The bare-metal path carries a transitional packaging note at the pin, reproduced in its guide.

One storefront per domain

The operator model is one storefront per domain. To sell VM slices and whole-machine access on the same physical hosts, run a VM storefront and a bare-metal storefront against the same provisioning and site authority, and give rows for the same host one stable attribute.physical_host_id so the site ledger prevents cross-mode double selling. Both guides carry the exact configuration.

Model metadata

An API-credit listing describes a named service (for example vllm-chat). The model that service runs is seller service metadata. The pinned API-credit resource schema does not expose a canonical model field, so this documentation never presents model names as Registry discovery filters or SCM wire fields.

Extending the pattern

A new asset class reuses the market shape by substituting its own resource schemas, settlement choices, and execution modules — that is the domain-authoring contract. Start at Custom-domain authoring, and treat the in-tree domains/vms and domains/apicredits implementations as reference examples of the contract surfaces, not as a required hosting model.