Developer docs

Integrate the factory without inheriting its complexity.

CommandLayer exposes stable machine contracts while keeping provider routing, settlement adapters, execution state, retries, and receipt production behind the service boundary.

API referenceOpen verifier
Start here

Choose the layer you are integrating.

R

Runtime

Reference execution behavior, versioned endpoints, health, signing, and verification boundaries.

M

MCP bridge

Tool exposure for compatible agent clients. Treat MCP as an adapter, not a second catalog.

S

Schemas

CLAS contracts and receipt structures used where they cleanly match a service's acceptance model.

Factory contract

The public surface is intentionally smaller than the implementation.

Buyer-visible

Service identity and version, request schema, result schema, execution mode, quote semantics, payment options, acceptance conditions, evidence contract, and stable endpoints.

Factory-internal

Primitive graph, provider selection, retries, budget enforcement, content fees, model costs, storage, payment/facilitator cost, and execution ledger internals.

Contract rule: an adapter may translate the service into OpenAPI, MCP, ENS, x402, ERC-8004, or another ecosystem. The adapter does not get to redefine the service.
Existing technical surfaces

Proof and reference tooling stays available.

Manual verifier

Paste a receipt and inspect canonicalization, hash, signature, signer, and verification state.

SDK records

Current SDK-oriented documentation and receipt wrapping surfaces.

Integrations

Reference integrations and demonstrations preserved while the commercial factory evolves.

API reference

Public API and verification endpoints.

Playground

Experiment with current public examples without treating demos as commercial product claims.

Webhook auto-verify demo

Preserved reference flow showing automatic receipt verification without making it a top-level product page.

Protocol background

Receipt, trust, and adapter architecture that sits underneath the factory.

Trust boundary

Verification is precise by design.

A valid receipt can prove canonical integrity, signature validity, signer/provenance information, and declared execution evidence. It does not prove that a statement is factually true merely because it was signed.

Conceptual receipt boundary
// payment evidence and execution evidence remain distinct
{
  "execution": {
    "input_hash": "sha256:...",
    "output_hash": "sha256:...",
    "acceptance": "passed"
  },
  "proof": "signed execution scope"
}