integrations: xChk registry — approval-outcome crosswalk, fixtures and receipt verifier (from trace-spec#560; stacked on #338)

integrations/xchk-registry/NOTICE

@@ -4,3 +4,12 @@ examples/01-trust-record.json: a Trust Record minted and signed by the registry
 ENG-WNP3, run 3057 (18 October 2026), cut to one approval-outcome reference. examples/expected.json pins the
 registry's seal key, as published at https://in.xchk.io/.well-known/xchk-keys.json, so the test runs offline. The
 record carries the plate owner's identifiers; he chose to publish it.
+
+examples/approval-outcome/: eight Trust Records and seven receipt bundles minted and signed by the registry at
+https://in.xchk.io for plate ENG-WNP3, run 3057 (17 October 2026), with expected.json as the registry's own record
+of each case; the altered copies (02, 06, 08) were made by the registry's fixture generator. They carry the plate
+owner's identifiers; he chose to publish them.
+
+verify_receipt.py: the xChk registry's offline receipt verifier, copyright (c) 2026 Sean MacGuire, MIT License
+(the notice in the file's header), vendored for the fixtures' tests as the registry serves it at
+https://in.xchk.io/verify/verify_receipt.py. Not part of the agentrust-trace package.

integrations/xchk-registry/README.md

@@ -48,11 +48,33 @@ was made against, and `verified_at_overridden`, so a historical verdict is never
 reported it; this tool passes no revocation bundle or store, so it reports `no_check_performed`, which is not an
 affirming appraisal (section 3.2.3). A stale or tampered record is `invalid`, with the reason.
 
+## Approval-outcome references: the crosswalk and fixtures
+
+What an `approval-outcome` reference resolves to, and what a relying party may conclude from it, is in
+[`CROSSWALK.md`](CROSSWALK.md), with nine records and eight receipt bundles in
+[`examples/approval-outcome/`](examples/approval-outcome/) (one case per way the composition can fail, each
+recomputed from the committed bytes by `tests/test_approval_outcome_fixtures.py`) and the registry's offline receipt
+verifier vendored as [`verify_receipt.py`](verify_receipt.py) (MIT; standard library only). The verifier binds the
+passkey's signed ask to the ceremony the sealed record and the registry-signed binding commit to, and its
+`--require-approval` mode refuses to call an approval verified when the approval evidence is absent; its `--keys`
+mode (2 Nov 2026) checks the keys the bundle pins against the registry's key document, saved once from
+`/.well-known/xchk-keys.json`, without which every signature check proves only that the bundle is consistent under
+its own keys. All three are covered by `tests/test_verify_receipt_regressions.py`.
+
+What this integration does **not** ship: a relying-party verdict in code. The composition logic lives in the fixture
+test as the worked example; a packaged `assess()` with structured verifier results, identity taken only from the
+signed binding, and an authenticated amendment scope is under separate assessment and follows in this directory
+once settled. Until then `decision.amendment` is informational, as the crosswalk's boundary says.
+
+Adopters: xChk (in.xchk.io) mints the Trust Record per run and points at its sealed receipts as `approval-outcome`
+references; the registry is the only relying party so far (software-only, Level 0).
+
 ## Run it
 
 ```
 pip install -e "integrations/xchk-registry[test]" agentrust-trace-tests
-pytest integrations/xchk-registry/tests -q                          # offline; REGISTRY_LIVE=1 adds one live key fetch
+pytest integrations/xchk-registry/tests -q                          # offline; REGISTRY_LIVE=1 adds one live key fetch; dilithium-py (in [test]) is required
+python integrations/xchk-registry/verify_receipt.py integrations/xchk-registry/examples/approval-outcome/01-approval-confirmed.bundle.json --require-approval --keys integrations/xchk-registry/examples/approval-outcome/xchk-keys/in.xchk.io.2026-11-02.json
 trace-tests verify --record integrations/xchk-registry/examples/01-trust-record.json --level 0 --max-age 315360000
 ```
 

integrations/xchk-registry/examples/approval-outcome/01-approval-confirmed.json

@@ -0,0 +1,47 @@
+{
+  "eat_profile": "tag:agentrust-io.com,2026:trace-v0.2",
+  "iat": 1792252491,
+  "subject": "did:web:in.xchk.io:plate:ENG-WNP3",
+  "model": {
+    "provider": "anthropic",
+    "model_id": "claude-fable-5-1"
+  },
+  "runtime": {
+    "platform": "software-only",
+    "measurement": "sha256:c60a771a8f6e4fda60fbb2b745397c800c38da090f153f72e302147a1851746a"
+  },
+  "policy": {
+    "bundle_hash": "sha256:8e1e29b1e2b1470b57fba453991d3c9ef0d0ae19ba59927c014525177ee741ae",
+    "enforcement_mode": "enforce"
+  },
+  "data_class": "internal",
+  "tool_transcript": {
+    "hash": "sha256:54ea01281f1acf13dec96c509cb243c5ee87b826524044ac8c2700a63cd9f2bb",
+    "call_count": 101
+  },
+  "references": [
+    {
+      "rel": "approval-outcome",
+      "id": "aa2bfd5b1d9b6307ed22eb0daa4213383beecb57d7d31ec011060ac98f7fe0b5",
+      "resolver": "https://in.xchk.io",
+      "digest": "sha256:aa2bfd5b1d9b6307ed22eb0daa4213383beecb57d7d31ec011060ac98f7fe0b5"
+    }
+  ],
+  "build_provenance": {
+    "slsa_level": 0,
+    "digest": "sha256:c60a771a8f6e4fda60fbb2b745397c800c38da090f153f72e302147a1851746a"
+  },
+  "appraisal": {
+    "status": "none",
+    "verifier": "https://in.xchk.io"
+  },
+  "cnf": {
+    "jwk": {
+      "kty": "OKP",
+      "crv": "Ed25519",
+      "x": "mn02E1XyTkaVN6DEOemU5OADMUAUjPHw67oR5KKIM3k",
+      "kid": "5ecb3da505414c4f"
+    }
+  },
+  "signature": "Vjgt2d7DVF_KmYdb3UXuOaL4YxRO1k46Uj91QkI5vc0EC5NraQ7U7S58DuD35d8GMy70wW-I08OtkRiCKTfPAQ"
+}