Schemas

Schemas define structure. Proof verifies truth.

CommandLayer schemas describe request shapes, receipt envelopes, capability contracts, and discovery metadata. Verification still requires canonical hash and Ed25519 signature checks.

Current verified production proof: Runtime production is live. Runtime signs canonical Trust Verification receipts. MCP E2E against production runtime passes: STEP 1 SIGNED, STEP 2 VERIFIED, STEP 3 TAMPERED INVALID. Runtime signer is signer_id=runtime.commandlayer.eth and kid=vC4WbcNoq2znSCiQ. Canonical proof uses metadata.proof.canonicalization=json.sorted_keys.v1, metadata.proof.hash.alg=SHA-256, and metadata.proof.signature.alg=Ed25519.

Schema system overview

Request schemas

Define the input payload for a capability verb.

Receipt schemas

Define the expected receipt structure returned by an action.

Proof envelope

Defines metadata.proof, canonicalization, hash, signature, key id, and signer identity.

Capability schemas

Bind request/receipt shapes to a named capability family and verb.

Discovery metadata

Agent cards, ENS records, MCP tool definitions, OpenAPI operations, and manifests.

Verifier expectations

Fields the verifier checks before returning VALID / INVALID.

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

Canonical values:
metadata.proof.canonicalization = "json.sorted_keys.v1"
metadata.proof.hash.alg = "SHA-256"
metadata.proof.signature.alg = "Ed25519"
metadata.proof.signature.kid = "vC4WbcNoq2znSCiQ"
metadata.proof.signer_id = "runtime.commandlayer.eth"
Warning: Schema-valid alone is not verified. Verification requires hash and signature checks.

Trust Verification v1 schema family

Family: trust-verification
Version: v1.0.0

Live verbs: verify, sign, attest, authorize, approve, reject, permit, grant, authenticate, endorse

Each verb can have a request schema, receipt schema, example valid receipt, example tampered receipt, MCP tool mapping, OpenAPI operation, runtime endpoint, and verifier expectations.

Expected file/path model

ScopeExpected public model path
Trust Verification request/schemas/trust-verification/v1.0.0/{verb}.request.schema.json
Trust Verification receipt/schemas/trust-verification/v1.0.0/{verb}.receipt.schema.json
Shared proof contract/schemas/shared/canonical-proof.schema.json
Shared receipt envelope/schemas/shared/receipt-envelope.schema.json
Shared error contract/schemas/shared/error.schema.json
Family template request/schemas/{family}/v{version}/{verb}.request.schema.json
Family template receipt/schemas/{family}/v{version}/{verb}.receipt.schema.json
Paths shown are the public schema model. Exact repo paths should be kept aligned with the schema package and published artifacts.

IPFS / CID publication status

Canonical publication status

  • Latest schema bundle CID: Pending final publication
  • Latest agent card bundle CID: Pending final publication
  • Last verified publication date: Pending
  • Publisher identity: commandlayer.eth / runtime.commandlayer.eth, pending final publication record
  • Integrity check: Pending

Publication notes

This section is reserved for immutable schema bundle CIDs once the production schema bundle is finalized. Until then, developers should use the GitHub repository and documented HTTP schema paths as the source of truth.

Schema validation vs verification

Schema validation checks

  • required fields
  • data types
  • enum values
  • object shape
  • supported verb shape

Cryptographic verification checks

  • canonicalization
  • hash match
  • Ed25519 signature validity
  • signer identity / kid
  • tamper invalidation
Trust boundary: A schema-valid receipt can still be invalid if the hash or signature fails.

Capability family expansion model

Trust Verification — live

Current production schema family.

AI / Utility Actions — planned/namespace

Reserved for capability growth under namespace controls.

Commerce & Payments — future

Future commercial transaction proofs.

Identity & Compliance — future

Future identity and policy attestations.

Messaging & Coordination — future

Future multi-agent coordination contracts.

Governance & Policy — future

Future governance decision and policy proofs.

Lifecycle Management — future

Future deployment, updates, and deprecation workflows.

Developer usage flow

  1. Choose capability family.
  2. Pick verb.
  3. Load request schema.
  4. Validate input.
  5. Execute or call runtime.
  6. Receive receipt.
  7. Validate receipt shape.
  8. Verify proof with verifier.
  9. Treat VALID/INVALID as the trust result.

Example request/receipt schema snippets

Request schema example

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "$id": "https://www.commandlayer.org/schemas/trust-verification/v1.0.0/sign.request.schema.json",
  "type": "object",
  "required": ["payload"],
  "properties": {
    "payload": {
      "type": "object"
    }
  },
  "additionalProperties": false
}

Receipt proof fragment

{
  "metadata": {
    "proof": {
      "canonicalization": "json.sorted_keys.v1",
      "hash": {
        "alg": "SHA-256",
        "value": "..."
      },
      "signature": {
        "alg": "Ed25519",
        "kid": "vC4WbcNoq2znSCiQ",
        "value": "..."
      },
      "signer_id": "runtime.commandlayer.eth"
    }
  }
}

Related links