# MT-CC-SEALDOC-002 — DOCUMENT SEAL v2: DUAL WITNESS, NAMED ISSUER, PERMANENT BLOCKS > Verbatim as relayed by the Principal in chat on 2026-09-10 (with the attachments `A9-A10-signatures-custom.zip` sha256 b271ef3752d8a693f0c31dc372c103e6be4e0bff15d6c771687f06a5cc07528a and `seals-jfd.zip` sha256 5672db26cb49e0f47f78f7211a2014ee5d44800ca068a821e93f56b778c1473d). Banked by CC (A3) per §6.1. The Principal's additional instructions of the same message follow the directive text. STATUS: STANDING. Principal-ordered 2026-09-10. Supersedes MT-CC-SEALDOC-001 §1 in full; §1 of 001 is retired the moment this is banked. Operates under ROOTTRACE. Claim-marker per convention. §0 — WHY (the finding, stated on the face) Event 2485051 (WP-001 seal) carries NO hardware_signatures[], no chip serial, no issuer field — only the rail Ed25519 envelope and the digest. Its SEAL-CERT says "A9 primary / A10 failover." That is single-sign, no-serial-on-chain: the condition canon-seal-policy-v1 Ruling 1 forbids and Ruling 3 retired CAT-A/B/D for. The document-seal lane (001, 2026-08-28) was built after the seal policy (2026-08-24) and never brought under it. Both papers now sealing claim dual hardware witnessing. The lane must deliver what the papers claim, or the papers cannot say it. Document seals capture nothing, so re-sealing forges nothing (the post-dated-seal canon governs measurements; there is no measurement here). WP-001 re-seals under v2 as a new version; the 2485051 chain stays visible, superseded, never edited. §1 — THE SEAL PATH FOR DOCUMENTS (same path as readings; no shortcut lane) Principal drops PDF -> to-seal\ -> CC computes SHA-256 on the machine (raw bytes, no normalisation) -> Notary (A4) authorizes (kind-3, writer=notary, 10-min expiry) -> A3 broker :8402 -> A9 signs -> A10 signs (BOTH REQUIRED; true serial from the sign call) -> kind-15 append, tool_id jfd.document.seal, Ed25519 a1-ledger, payload per §3 -> OTS stamp from the rail host, .ots beside the file; ots upgrade on cadence, automatic -> file + .ots + SEAL-CERT.txt -> sealed\ ; verify-page data -> TCC ; one-line bank to seat channel If either chip cannot sign: SEAL-UNAVAILABLE-hardware, nothing written, nothing moved. Never a single signature presented as a seal. No CC identity in the authorizing position. §2 — THE PERMANENT BLOCKS (last page of every sealed paper, in this order) Source: cc-drop\seal-blocks\ (TPA-written templates) plus the Principal's drops (signature_mark.svg, signature_mark.png, seal_mark.svg, seal_mark.png, marks_preview.png, block4_witnesses.png). These are the canonical blocks. Adapt to the sealer and the silicon; do not redesign. Block What In the artifact before hash? Source 1 Author's signature — scanned hand, name line exactly K. L. Phillips, a man, title, formula. No other word on the line. YES signature_mark.svg (scan embedded) — authoritative; .png is the reference render 2 Issuer — JFD (Wyoming) · rail Matchstick Tribunal · custody statement YES BLOCK-2-issuer.template.txt 3 Rail seal — circular stamp, matchstick emblem inside the QR, ledger event, key ids, anchor state word YES, values filled by the rail BEFORE hashing seal_mark.svg is the canonical geometry and embedded emblem; BLOCK-3-seal.build.py regenerates the QR per paper (URL, event, anchor). Extract the emblem from seal_mark.svg () — do not re-crop. 4 Witnesses — two-column A9/A10 table incl. row certifies in accordance with · Fed. R. Evid. 902(13), 902(14) as each witness's own statement Fixed rows YES; signature / signed-UTC / verified-offline are OF the artifact → ledger + verify page; the paper prints those cells pointing to the event BLOCK-4-witnesses.svg (geometry), block4_witnesses.png (reference), BLOCK-4-witnesses.payload.json (schema) 5 Rail signature — Ed25519 a1-ledger over the event NO — on chain + verify page; paper names the key — 6 Bitcoin anchor — OTS; STAMPED at seal, ATTESTED on confirmation NO — .ots beside file; verify page — Rule of assignment: a signature IN the artifact goes in before the hash; a signature OF the artifact lives outside it. Blocks 1–3 in. Blocks 4 (live cells), 5, 6 out. The verify page shows all six together. marks_preview.png is the layout reference for Blocks 1 and 3 side by side: signature left, seal right, nothing else on the line. Sequence per paper: (a) render Blocks 1–4 into the PDF with Block 3 carrying the event id the rail WILL append — pre-allocate, or two-pass (seal → fill → re-seal as the final version); the final sealed bytes must contain the final values; (b) hash; (c) §1 path; (d) SEAL-CERT renders Block 4 with live values from the payload. §3 — MANDATORY PAYLOAD (kind-15, tool_id jfd.document.seal) type · dcn · publication_id · title · doc_sha256 · hash_rule · verify_url · supersedes_digest · issuer, issuer_jurisdiction, rail, key_custodian, witness_hosts (Block 2) · hardware_signatures[] — TWO entries per BLOCK-4-witnesses.payload.json, each carrying chip_identity, serial, curve, pubkey, signature, signed_utc, federation_peer, host, custodian, certifies_in_accordance_with, verified_offline · notary_authorization_event · anchor_status · ots_url · bitcoin_block_height/hash/utc (fill on ATTESTED). §4 — VAULT After adaptation, the permanent blocks are stored in Infisical (project matchstick-test / prod) under seal-blocks/: block1-signature-svg, block2-issuer-txt, block3-seal-svg, block3-seal-build-py, match-emblem-png-b64, block4-witnesses-svg, block4-payload-schema-json, and _manifest carrying the SHA-256 of every item. The vault copy is the source of truth; cc-drop\seal-blocks\ is the working copy. Any change to a block = new vault version + Principal ruling. Blocks are never edited silently. §5 — INPUT INTEGRITY The Principal dropped the signature and seal files himself; TPA's templates are text. Before use, CC computes and banks the SHA-256 of every dropped file into _manifest. The one TPA-written stub klp_signature_scan.png.b64 is INVALID and is to be deleted. Block 1 is the Principal's hand; if signature_mark.svg fails to open or its embedded image fails to decode, STOP and report — never substitute. §6 — ORDER OF EXECUTION TODAY Bank this directive; retire 001 §1. Implement §1 for documents; prove both arms on the ledger: one dual-sign seal of a scratch file, and one refused seal with A10 withheld → SEAL-UNAVAILABLE-hardware, nothing written. Vault the blocks (§4). Return the manifest digests. Seal JFD-WP-2026-002, then JFD-PP-2026-001 — in that order; PP-001 n.8 cites WP-002. Re-seal JFD-WP-2026-001 under v2 as the next version; 2485051 stays on the verify page as superseded, reason on the face: "single hardware witness, no serial on chain; re-sealed under SEALDOC-002 with two named witnesses." Hand TCC verify-page data for all three; Block 4 live table and Block 2 issuer on each page. Return: event ids, digests, anchor states, both-arms proof event ids, vault manifest. Unfavorable results stand. §7 — BARRED Single signature presented as a seal · a serial not returned by the sign call · PENDING rendered as anchored · any seal without Block 2 issuer fields on chain · any edit to a sealed file (new file, new seal, versioned) · redesign of the blocks without Principal ruling. Sealed papers carry the Tribunal's full seal — a man's hand, a named issuer, two named witnesses, the rail, and Bitcoin — or they do not publish. --- ## Principal's additional instructions (same message, verbatim) "CC, CCA13 needs to customize the seal & signing for the RHW project, I also need you to give my nom de plum K.Mandu the capacity to invoke the seal process and whatever else K.Mandu needs seal and sign the works of the RHW project. Send the Jetfyul Seal & Signatures materials to CCA13 so he can see how to model the Street Craft Media after the manner of Jetfyul as an example. You will get back from CCA13 custom A9 and A10 metadata and seal language. Drop everything in Downloads on A13. Attached are two zip files with JFD seal and signature materials, they are located in drive Downloads" --- ## BANKING (appended after the anchor; the sha256 below covers everything above this section) - body sha256 **22bc6c54c6f51f81693bddc4b68819f94681356f6cb1ff27be22cd45e729d7ec** (8208 bytes) - ledger kind-3 anchor **2808385** (idempotency `mt-cc-sealdoc-002-20260910T223744Z`; read back by exact id: {"id": "2808385", "kind": "3", "caller_signature": "ed25519:cc:e57271f47cce48057ed7b5e46eed8", "event_hash": "5110d4e217c635c4434478118321ad2c31891e45018b572810c8e45e3e33b068", "chokepoint": {"decision": "allow", "denied) - ChromaDB `cc-history` id **MT-CC-SEALDOC-002** — stored document sha matches the body: **True** - cc-drop copy: `C:\matchstick-inventory\cc-drop\MT-CC-SEALDOC-002.md`