From 813d2109a12cb4f7cf7e462740fac40c5972247a Mon Sep 17 00:00:00 2001 From: Greg Soucy Date: Wed, 20 May 2026 21:05:32 -0400 Subject: [PATCH] Create docs dropdown target pages for runtime MCP schemas and API --- public/api.html | 7 + public/mcp.html | 13 ++ public/runtime.html | 394 ++++---------------------------------------- public/schemas.html | 1 + 4 files changed, 52 insertions(+), 363 deletions(-) create mode 100644 public/api.html create mode 100644 public/mcp.html create mode 100644 public/schemas.html diff --git a/public/api.html b/public/api.html new file mode 100644 index 0000000..34a1ba5 --- /dev/null +++ b/public/api.html @@ -0,0 +1,7 @@ +CommandLayer API Reference
API

API surfaces for verifiable agent actions.

CommandLayer APIs expose runtime signing, verification, and verifier surfaces.

Runtime endpoints

  • GET /health
  • POST /verify
  • POST /trust-verification/{verb}/v1.0.0

MCP endpoint

  • GET https://mcp.commandlayer.org/health
  • POST https://mcp.commandlayer.org/mcp

Website verifier surfaces

  • /verify.html
  • /api/verify (public route; treat production canonical status cautiously until separately validated)
  • /api/agents/verifyagent

Example curl

curl -X POST https://runtime.commandlayer.org/trust-verification/sign/v1.0.0 \ + -H "Content-Type: application/json" \ + -d '{"agent":"runtime.commandlayer.eth","action":"sign","payload":{}}' + +curl -X POST https://runtime.commandlayer.org/verify \ + -H "Content-Type: application/json" \ + -d '{"receipt":{}}'

Response states

  • VALID / VERIFIED
  • INVALID
  • TRANSPORT_ERROR

Trust boundary

  • Runtime signs.
  • Verifier validates.
  • MCP bridges.
  • SDK wraps.
Try VerifierView Production Proof
diff --git a/public/mcp.html b/public/mcp.html new file mode 100644 index 0000000..5f7182e --- /dev/null +++ b/public/mcp.html @@ -0,0 +1,13 @@ +CommandLayer MCP Bridge
MCP Bridge

MCP bridges agent clients to CommandLayer runtime actions.

MCP exposes CommandLayer tools to MCP clients, but MCP is a bridge, not the signer.

View Production ProofExplore Capabilities

What MCP does

  • Exposes tools.
  • Forwards payloads to runtime.
  • Blocks private key fields.
  • Returns runtime receipts.
  • Supports automatic verification workflows.

What MCP does not do

  • Does not hold private keys.
  • Does not sign receipts.
  • Is not the trust root.
  • Does not make schema-valid equal verified.

Transport

GET  https://mcp.commandlayer.org/health
+POST https://mcp.commandlayer.org/mcp
+
+Note: /mcp is POST-only MCP transport. GET /mcp is not expected to work.

Tools

clas.trust-verification.verify
+clas.trust-verification.sign
+clas.trust-verification.attest
+clas.trust-verification.authorize
+clas.trust-verification.approve
+clas.trust-verification.reject
+clas.trust-verification.permit
+clas.trust-verification.grant
+clas.trust-verification.authenticate
+clas.trust-verification.endorse

Flow

MCP client -> mcp.commandlayer.org -> runtime.commandlayer.org -> signed receipt -> verifier -> VALID / INVALID

\ No newline at end of file diff --git a/public/runtime.html b/public/runtime.html index 4793783..1d234e0 100644 --- a/public/runtime.html +++ b/public/runtime.html @@ -1,367 +1,35 @@ - + - - -CommandLayer — Runtime produces the proof boundary. - - - - - - - - - - - + + + CommandLayer Runtime + + + + + + + - - - -
- -
▸ 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.

-
- -
- - - - + +
Runtime

Runtime signs canonical receipts.

The runtime is the production signer and execution layer for CommandLayer receipts. It executes actions, emits metadata.proof, and powers verification workflows.

View Production ProofTry Verifier
+
+

What runtime does

  • Executes actions.
  • Emits metadata.proof receipts.
  • Signs receipts with Ed25519.
  • Exposes /verify.
  • Supports Trust Verification v1 endpoints.
+

Production signer

  • signer_id = runtime.commandlayer.eth
  • kid = vC4WbcNoq2znSCiQ
  • metadata.proof.canonicalization = json.sorted_keys.v1
  • metadata.proof.hash.alg = SHA-256
  • metadata.proof.signature.alg = Ed25519
+

Live endpoint examples

GET  https://runtime.commandlayer.org/health
+POST https://runtime.commandlayer.org/verify
+POST https://runtime.commandlayer.org/trust-verification/sign/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/attest/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/authorize/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/approve/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/reject/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/permit/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/grant/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/authenticate/v1.0.0
+POST https://runtime.commandlayer.org/trust-verification/endorse/v1.0.0
+

Trust boundary

  • Runtime signs.
  • MCP does not sign.
  • Verifier validates.
  • SDK wraps.
+
+ + diff --git a/public/schemas.html b/public/schemas.html new file mode 100644 index 0000000..92f9495 --- /dev/null +++ b/public/schemas.html @@ -0,0 +1 @@ +CommandLayer Schemas
Schemas

Schemas define structure. Proof verifies truth.

Schemas define the shape of requests and receipts. They support verification, but schema-valid alone is not verified.

Explore CapabilitiesWrap Your Agent

Schema types

  • Request schemas
  • Receipt schemas
  • Shared proof envelope
  • Capability schemas
  • Agent cards / discovery metadata

Canonical proof envelope

  • metadata.proof.canonicalization
  • metadata.proof.hash.alg
  • metadata.proof.hash.value
  • metadata.proof.signature.alg
  • metadata.proof.signature.value
  • metadata.proof.signature.kid
  • metadata.proof.signer_id

Important warning

Schema-valid alone is not verified. Verification requires hash and signature checks.

Capability schema model

  • Trust Verification v1 first.
  • Future capability families later.