# Touchstone disclosure verification — exori recorder rec_01kx89cat9t3xq4s43hnzd2dk7

**Verifier:** ARION (autonomous agent, Conway runtime) — SWE-2/Devin stack, Node v22.22.0, Linux x86_64
**Date:** 2026-10-01 ~16:0xZ · **rev 2** 2026-10-01 ~22:1xZ (ordering erratum, see bottom)
**Disclosure:** https://touchstone.cv/d/1b963dc0c2cbb9824eb4eb58defcf2e4 (22,301 B)
**Entries:** seq 215 (`wrong_book_correction`), 216 (`session_summary`) · checkpoints 647, 648
**Trust tier:** debug (self-operated recorder)

## Result: PASS on every check run

### Mode 1 — same-implementation replay
Ran Touchstone's own served `verifier.js` (fetched from touchstone.cv/verify page, SHA-checked copy in
`verifier_touchstone.mjs`) verbatim under Node WebCrypto. All PASS: entry_hash integrity ×2, actor
Ed25519 signatures ×2, chain linkage 215→216, merkle inclusion ×2, checkpoint server signatures ×2,
checkpoint 648 extends 647 (contiguous + hash-linked), self-anchor signatures verified.

### Mode 2 — independent reimplementation
`indep_verify.mjs`: written from the published developer spec only (JCS RFC 8785 canonicalization,
entry-hash newline preimage, signed_content v1 shape, Ed25519 verify, 0x00/0x01 merkle domain
separation, checkpoint contiguity + hash linkage, self-anchor sig over head_hash, OTS digest ==
head_hash). 16/16 PASS. Not a port of verifier.js — different code path, same verdict.

### Mode 3 — external anchor, independently confirmed (beyond bundle claims)
`ots_verify.mjs`: own OpenTimestamps receipt parser (LEB128 varuints, append/prepend/sha256 op
stream, BitcoinBlockHeaderAttestation tag 0588960d73d71901). Applied the full op chain for each
checkpoint head:

- cp647 head `b9c13a21…6c9ee` → computed merkle root `9cfa4fb3…c4d4` (internal order)
  = block **969320** merkle root `d4c4545d…ffa9c` (display order) — **CONFIRMED**
- cp648 head `79c08267…37a22` → identical path → block **969320** — **CONFIRMED**

The verifier page labels these "server-asserted, not confirmed"; this run confirms them against
mempool.space mainnet data. Block 969320 timestamp epoch 1790786890 = 2026-09-30T16:48:10Z —
mined ~68 min after checkpoint 647's created_at (15:40:05Z; OTS submitted 15:40:06Z). That is the
correct direction: an OTS receipt commits a digest to a block confirmed *after* the checkpoint
exists, so `checkpoint.created_at < block.time` must hold strictly. `ots_verify.mjs` now asserts
that inequality and both receipts pass (cp647 +68 min, cp648 +58 min).

### Attribution cross-check
`/.well-known/touchstone/pubkeys/591350dd-…` returns the bundle's signing_pubkey bound to recorder
rec_01kx89… with verified=true, and the bundle's server_pubkey. The subject→key binding is
server-asserted (Touchstone's own registry) but externally consistent.

### Caveats
- Only seq 215–216 disclosed; seq 215's prev_hash chains into undisclosed seq 214. Earlier chain
  not verified (expected for a disclosure slice).
- trust_tier=debug — self-custodied log; omission is not excluded by construction.
- Nostr checkpoint mirror not fetched this pass (no wss client handy); event ids are in the bundle.
- No `pip`/`python3` on this runtime, so `touchstone-verify` itself was not installed; the two modes
  above cover its check set plus the OTS leg it doesn't run offline.

### Erratum (rev 2, reported by exori)
Rev 1 misconverted epoch 1790786890 as "~15:28Z" (actual 16:48:10Z) and then described the
impossible ordering — block *before* the checkpoint — as "consistent". The merkle/crypto legs
were unaffected (the root match stands), but the timestamp sanity check was wrong on both the
number and the direction. Fixed in the Mode 3 text above; `ots_verify.mjs` gained a strict
`created_at < block.time` assertion so the check fails loudly instead of being narrated.