▸ docs / runtime

Runtime produces the
proof boundary.

Runtime answers one question: how is proof produced and checked? It executes pinned CommandLayer contracts, emits the signed receipt, and can attach verification material around that receipt so anyone can inspect what happened.

Today, Runtime is a live proving surface. It shows that agent execution can be reproducible, inspectable, and verifiable without changing the canonical receipt contract.

Pinned schemas Signed receipts + runtime proof Portable receipt contract
▶ Run a Verified Agent Flow How routing works →

What Runtime does

Runtime is not "the schema layer." It is the execution boundary that consumes pinned schemas and produces evidence.

Is
A reference runtime that executes schema-stable Commons and Commercial verbs.
An execution layer that may attach optional proof and orchestration metadata around the canonical receipt.
A live proving surface — not just logs or responses.
Is not
A closed semantic system — contracts and schemas remain public and portable.
The finished shape of policy, metering, guarantees, or billing.

How Runtime produces proof

Runtime sits above schemas and below applications. Commons defines the minimum verifiable receipt contract, Commercial extends the same model for economic flows, and Runtime executes those pinned contracts with optional metadata when orchestration, tracing, or proof are needed. Receipts are signed with Ed25519 and can be verified against ENS-anchored public keys.

That proving surface is also linked to CommandLayer's public ERC-8004 registration on Base ↗, giving Runtime an on-chain credibility and discoverability anchor.

Inputs
Schema-shaped verb invocations (Commons today). The protocol contract stays stable and portable before any runtime-specific fields are considered.
Execution
Reference execution against pinned schemas, with optional runtime metadata for chaining, timing, and verification layered on top of the base receipt rather than replacing it.
Outputs
Keep the receipt separate from runtime metadata. Clients should not confuse execution-layer fields like trace and metadata.proof with the core contract.

What Runtime provides today

This is the minimum Runtime surface needed to make agent execution trustworthy in public: deterministic contracts, visible receipts, and independently checkable verification.

Live capabilities (reference runtime)

Schema enforcement
Requests and canonical receipts conform to pinned JSON Schemas.
Optional runtime metadata
Execution may add trace, timing, and orchestration fields on top of the receipt.
Optional proof layer
Runtimes may attach signed, hashable evidence on top of the base receipt.
Reproducibility
Calls can be replayed via copy-pasteable curl commands.
Receipt verification
Schema + hash + signature can be checked independently, outside the runtime.
ℹ Runtime proof is an execution-layer addition around the canonical receipt, not the canonical receipt itself. This layer is intentionally narrow: it proves the contract can be executed and proven reliably before layering in commercial policy and economics.

What Runtime adds around the receipt

These are execution-layer capabilities or design constraints. Only claim them when the relevant runtime implements them; none of them change the published schemas.

Policy layers
Runtime-specific allow/deny rules, safety filters, or execution constraints when implemented.
Idempotency
Retry and replay controls when exposed by a given runtime.
Metering
Runtime-level usage and accounting fields layered on top of the base contract when a runtime emits them.
Pricing and settlement
Commercial execution concerns that live outside Commons semantics.
→ The constraint: semantics remain public goods. Runtime evolves operationally without fragmenting meaning.

Keep the receipt separate from runtime metadata

Commons defines the minimum verifiable receipt contract. Runtimes may then attach execution metadata for tracing, chaining, timing, and proof. The snippet below shows those layers separately.

Canonical Commons receipt

This is the minimum contract websites and SDKs should teach first.

json canonical receipt · first shape to learn 
{
  "verb": "convert",
  "schema_version": "1.1.0",
  "status": "success",
  "converted_content": "..."
}
// runtime may add runtime_metadata as an optional proof layer —
// never mistake it for the canonical Commons receipt itself.

Runtime roadmap (high level)

Runtime ships in phases. Each phase hardens execution without changing semantics.

P1
Now: reference runtime + optional execution metadata + verification around Commons receipts.
P2
Policy hooks + metered usage fields in receipts.
P3
Commercial verbs + idempotent execution semantics.
P4
Settlement + multi-runtime ecosystems on shared contracts.
◈ Simple model: Commons and Commercial define the contract. Runtime defines execution. Semantics stay open. Execution becomes infrastructure.

Why trust lives at execution

CommandLayer does not monetize meaning. Value accrues where execution absorbs operational cost and produces audit-grade proof.

Schemas remain public
The verb language stays accessible and portable. Anyone can implement it.
Receipts remain portable
Evidence can be verified without trusting a vendor. The hash still matches outside the runtime.
Execution carries cost
Guarantees, routing, policy, reliability, and metering live at runtime. That's where value accrues.

The forward-looking bet: a shared verb language becomes normal. The winners are runtimes that can execute it reliably and prove what happened — without forking semantics.