# Conformance Results — Milestone-2 Wire Format Vectors

This file records how conformance against the milestone-2 test vectors is
established, what "passing" means, and where the authoritative results live.

## What is tested

The vectors under `conformance/vectors/` are the frozen milestone-2 fixtures:

- **`canonicalization.json`** — input JSON documents paired with their
  required canonical byte encodings (as hex) and content hashes. A conforming
  implementation must reproduce the canonical bytes exactly: key ordering,
  integer/float formatting, string escaping, and UTF-8 normalization are all
  covered, including the adversarial cases (duplicate-key rejection, non-ASCII
  keys, nested empty containers, large integers).
- **`signing.json`** — fixed Ed25519 seed keys, canonical payloads, and the
  required signatures and operation IDs. A conforming implementation must
  produce byte-identical signatures (Ed25519 is deterministic) and must
  *reject* the included negative cases (bad signature, mutated payload,
  truncated key).
- **`op_scenarios.json`** — multi-operation scenarios: hash-linked author
  chains, evidence→claim derivation references, refutation/cascade ordering,
  grant and revoke operations. Each scenario specifies the required end-state
  a verifying node must reach (accepted ops, rejected ops with reason codes,
  resulting claim statuses).

## How results are produced

Results are **generated, never hand-recorded**, to prevent stale or
fabricated claims of conformance:

```sh
python conformance/run_conformance.py
```

The runner loads every vector file, executes each case against the reference
implementation, prints a per-case PASS/FAIL table with the vector ID and
failure detail, and exits non-zero if any case fails. The runner itself is
exercised by `tests/test_conformance_runner.py`, which asserts that the
reference implementation passes **all** vectors and that deliberately
corrupted vectors are reported as failures (i.e., the runner cannot
trivially "pass" by doing nothing).

## Authoritative record

The authoritative, reproducible record of conformance is the CI run on the
default branch (see `.github/workflows/ci.yml`), which executes the full test
suite and the conformance runner on every push, across the supported Python
versions. A green CI run on a given commit *is* the conformance result for
that commit; we deliberately do not check in a static results snapshot,
because a snapshot can silently diverge from the code it claims to describe.

## Conformance for second implementations

A second implementation claims milestone-2 conformance by running these same
vectors through its own runner (the vector format is documented in
`conformance/README.md` and `INTEROP.md`) and passing every case, including
the negative cases. Partial conformance — e.g., canonicalization without the
op-scenario end-states — is not sufficient for sync interop, because sync
correctness depends on identical accept/reject decisions on both sides.