Schema and conformance

For anyone building their own WCM implementation, or checking one. The schema is a machine-readable description of a valid manifest, and the conformance suite is a set of test cases that shows whether an implementation behaves as the specification says.

These two machine-readable files sit alongside the specification text, so an independent implementation has something to build and check against rather than prose to interpret.

The manifest JSON Schema

schema/wcm-manifest-v1.schema.json is the normative machine-readable form of SPEC.md §3.1. JSON Schema 2020-12, identified by https://wcm.agentrust-io.com/schema/manifest/v1.json.

It is frozen at v1 and additive-only: new things can be added, nothing existing changes. Fields and permitted enum values may be added; nothing is removed, renamed, made required, narrowed, or repurposed. A breaking change would publish .../manifest/v2.json alongside rather than edit v1. The specification itself is still pre-1.0, so this is a deliberate trade: implementers get a stable target now, and whatever the spec grows into arrives as an addition.

From Python:

from wcm.schema import manifest_schema
schema = manifest_schema()

One constraint is not expressible in JSON Schema: derived_from must not equal weights_hash. Standard JSON Schema cannot compare the values at two instance locations, so this stays a verifier-side check. It matters, because a self-derived manifest makes the lineage walk in §3.4 non-terminating. An implementation that delegates all structural validation to the schema will fail the corresponding conformance vector. See schema/README.md.

The conformance suite

conformance/ holds language-neutral JSON vectors and a scoring contract. Four levels are defined, matching the four protocol layers:

Level	Title	Vectors	Shape
L1	Manifest and joint signature	38	documents
L2	Attestation-gated release	43	scenarios and vendor evidence
L3	Runtime custody	12	scenarios
L4	Derivative lineage	10	documents

103 vectors. All four levels are vectored and every reportable error code is exercised by at least one vector, which a test enforces. L1 and L4 ask a question about a document. Most L2 vectors and every L3 vector ask what a system does over time, so they are ordered scenarios with an injected clock and named nonces; L2 also carries vendor evidence.

Two limits remain, and wcm conformance prints both on every full run rather than leaving a green result to be over-read:

• The vendor corpus covers AMD SEV-SNP, but not Intel TDX. The AMD vector verifies a genuine Azure report against the staged AMD Milan root and applies the mandatory refusal matrix. Intel remains covered by SDK fixtures, not a language-neutral vendor vector.
• GPU-side cryptographic verification is not vectored. The quote vectors cover the CPU quote; the NVIDIA device chain is covered by the SDK's H100 fixture.

Running it (the first command tests this SDK itself; the last one scores another implementation's results):

pip install weight-custody-manifest

wcm conformance                              # self-test this SDK
wcm conformance --level L4
wcm conformance --list-vectors
wcm conformance --list-codes

wcm conformance --results my-results.json    # score another implementation

An implementation in any language reads the vectors, emits a results file naming each vector's verdict and, for a rejection, its WCM-* code, and gets scored. Three rules make a pass mean something: every valid input must be accepted, every invalid one must be rejected for the declared reason, and a vector with no reported result counts as a failure. So neither "reject everything" nor a partial submission can claim a level.

The error codes are listed in conformance/codes.md, and the full contract, including two interop details that trip implementations (defaults must be materialized before the signing pre-image is computed, and the self-derivation check has to live outside the schema), is in conformance/README.md.