From b53a7560dbaca193f34e377d06b11458cdb3190c Mon Sep 17 00:00:00 2001 From: Greg Soucy Date: Wed, 20 May 2026 18:53:08 -0400 Subject: [PATCH] Rebuild protocol page as canonical architecture and trust model --- public/protocol.html | 187 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 187 insertions(+) create mode 100644 public/protocol.html diff --git a/public/protocol.html b/public/protocol.html new file mode 100644 index 0000000..47aaf90 --- /dev/null +++ b/public/protocol.html @@ -0,0 +1,187 @@ + + + + + +Protocol | CommandLayer + + + + + + + + + + + +
+
+
+

Protocol

+

The receipt layer for verifiable agent actions.

+

CommandLayer defines how agent actions are described, signed, transported, and verified — without making MCP, SDKs, or apps the trust root.

+
+ View production proof + Explore capabilities +
+
+
+ +
+

Architecture stack

+

Protocol layers and trust ownership.

+
+

CLAS

Defines action and receipt contracts.

+

runtime-core

Canonicalization, hashing, signing, verification. Canonical crypto truth for receipts.

+

runtime

Executes actions and signs canonical receipts in production.

+

MCP

Bridge for MCP clients. Does not sign. Does not hold keys.

+

VerifyAgent

Verifier that checks hash/signature/proof validity and returns VALID or INVALID.

+

agent-sdk

Developer wrapper for emitting receipts from agent actions.

+
+

commandlayer.org documents, demonstrates, and exposes verifier surfaces for this stack.

+
+ +
+

Canonical receipt model

+ 
{
+  "verb": "sign",
+  "class": "trust-verification",
+  "result": {
+    "payload": {
+      "message": "hello from MCP"
+    }
+  },
+  "metadata": {
+    "proof": {
+      "canonicalization": "json.sorted_keys.v1",
+      "hash": {
+        "alg": "SHA-256",
+        "value": "..."
+      },
+      "signature": {
+        "alg": "Ed25519",
+        "kid": "vC4WbcNoq2znSCiQ",
+        "value": "..."
+      },
+      "signer_id": "runtime.commandlayer.eth"
+    }
+  }
+}
+
+ +
+

Trust boundaries

+
+

Runtime signs.

Signing authority is runtime, not transport surfaces.

+

Verifier verifies.

Verification requires recomputed hash plus signature check.

+

MCP bridges.

MCP is integration plumbing and never the signer.

+

SDK wraps.

SDK helps developers emit receipts; it is not trust root.

+

Schemas describe.

Schema-valid does not mean verified.

+

Apps consume.

Apps consume verified results after proof checks pass.

+
+
    +
  • MCP is not the signer.
    • +
  • Schema-valid does not mean verified.
    • +
  • A receipt is only verified when hash and signature checks pass.
    • +
  • Tampering must produce INVALID.
    • +
+
+ +
+

Verification lifecycle

+
+ Action requested→ + Runtime executes/signs→ + Receipt emitted→ + Verifier recomputes hash→ + Verifier checks Ed25519 signature→ + VALID or INVALID +
+
+ +
+

Production proof summary

+
+

STEP 1 SIGNED

Runtime production is live and signs canonical Trust Verification receipts.

+

STEP 2 VERIFIED

hash_matches=true
signature_valid=true

+

STEP 3 TAMPERED INVALID

tampered hash_matches=false
tampered signature_error=hash_mismatch

+
+

MCP E2E against production runtime passes: STEP 1 SIGNED, STEP 2 VERIFIED, STEP 3 TAMPERED INVALID.

+
+ +
+

Capability families

+

Expandable groups on top of protocol receipts.

+
+

Trust Verification v1

verify, sign, attest, authorize, approve, reject, permit, grant, authenticate, endorse

+

AI / Utility Actions

summarize, classify, clean, parse, explain, analyze, format, convert, describe, fetch

+

Future families

commerce, identity, governance, data, messaging, payments, policy, compliance

+
+
+ +
+
+

Build on the protocol.

+

Use canonical metadata.proof receipts with json.sorted_keys.v1 + SHA-256 + Ed25519 under signer runtime.commandlayer.eth.

+
+ View proof + Explore capabilities + Install SDK +
+
+
+
+ + + +