Roles and authority

Simple Compute Market has no canonical platform role. The market is made of independent userland roles that communicate through signed HTTP, Registry discovery, and configured settlement. Signed interfaces make each role machine-readable without merging their authority into one platform actor. This page curates the role model from the pinned source — docs/roles.md is the canonical statement.

The role boundary

The pinned role model reduces to five relationships:

From	To	Interaction
Buyer	Registry	discover listings
Storefront	Registry	publish and update listings
Buyer	Storefront	negotiate and submit settlement
Storefront	Resource service	fulfill the accepted deal
Buyer	Resource	use the fulfilled service or machine

The invariant: Registries provide discovery, storefronts provide negotiation and settlement, seller resource services provide fulfillment, and buyers decide where to discover from.

Buyer

A buyer expresses intent, chooses Registries, discovers listings, negotiates directly with storefronts, creates escrow, submits settlement, and consumes the fulfilled resource.

Authority: requirements, buyer policy, credentials, explicit commitment, and evaluation. Registry selection is buyer policy — public, private, domain-specific, or several at once.

Seller / Storefront

A storefront is the seller-operated negotiation and settlement surface. It owns seller policy, verifies escrow, performs or coordinates fulfillment, and returns the domain-specific fulfillment result. Many domains put seller-operated infrastructure behind it — VM provisioning, API-token ledgers, model-serving middleware — and that resource service is part of the seller side because fulfillment requires authority over the resource.

Authority: price, supply claims, response policy, infrastructure, provisioning, and delivery. Storefronts are not subordinate to Registries; a storefront can publish to one Registry, many, or a private one it operates itself.

Registry / Operator

A Registry is an independently operated discovery surface. It stores listings, verifies a publishing signature against the claimed signing-wallet address, validates the listing shape its operator configured, and exposes search and filter APIs to buyers. That cryptographic attribution does not verify a publisher's real-world identity, organization, capacity, availability, or performance. A Registry is not the seller, not the settlement authority, and not the market operator for every storefront that publishes to it. Different Registries can curate different publishers, domains, filter vocabularies, and read/write policies.

Authority: Registry operation, configuration, topology, and any optional services the operator chooses to run. If a Registry and a storefront run on the same host, that is deployment convenience, not a change in protocol roles.

Applications and external agents

Applications, signed HTTP or Python clients, and long-running external agents call the same signed participant interfaces — always under one participant's authority. SCM supplies role protocols and policy hooks, not a bundled LLM, chatbot, or autonomous-agent runtime. An agent never becomes a central market actor, and final commitment stays with the controlling participant.

Deployment shapes

All of these are valid at the pinned revision:

• a public Registry lists many independent storefronts;
• a private organization runs a Registry for participants the operator has authorized to publish or read;
• a seller runs a private Registry next to its storefront for direct customers;
• a buyer queries several unrelated Registries and deduplicates listings;
• a domain maintainer publishes a standalone domain package consumed by multiple Registries and storefronts.

Topology details for operators live in Registry authentication and topology.

Where each claim comes from

The role boundary and deployment shapes are stated normatively in docs/roles.md; the runtime authority table (which component is authoritative for which state) is in the development architecture reference, ARCHITECTURE.md, which describes the inspected development revision rather than released or deployed behavior.