CLAS
Defines action and receipt contracts.
+
+ 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.
+ +
+
Architecture stack
+Protocol layers and trust ownership.
+
+
+ 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.
+ +