Satsignal conformance — disclosure-v1

This is the conformance surface for the selective-disclosure spec (docs/notary_spec/disclosure-v1.md). It is the canonical "is this verifier / SDK / adapter conformant with satsignal.disclosure.v1?" reference for third-party verifier authors, SDK implementers, adapter authors, and standards-adjacency reviewers.

disclosure-v1.md is normative; this document is a flat checklist of the normative requirements with cross-references back to the relevant sections, the triggering input vector for each MUST, and the required verifier behavior. Per-profile preimage / canonicalization / leaf-id rules are normatively defined in the per-profile specs under docs/notary_spec/profiles/; this document binds those rules into the disclosure verifier contract by cross-reference. A verifier conformant with disclosure-v1 is conformant only for the specific profile literals it actually implements — partial-profile conformance is explicitly contemplated in §D below.

Relationship to sibling conformance docs

The three conformance docs cover three independent (but layered) surfaces:

• CONFORMANCE.md covers satsignal.provenance.v1 — the canonical manifest schema, JCS-of-manifest, the rejection of unknown top-level keys inside the canonical doc, vendor / custom payloads in extensions.
• CONFORMANCE_bundle.md covers bundle-v1 — the .mbnt ZIP envelope, the JSON entries, the on-chain anchor binding, and the ordered verification procedure.
• This document covers disclosure-v1 — the manifest.disclosure block, the linked-anchor binding chain, the per-revealed-leaf recomputation, the claims-rendering contract, and the merkle-proof invariants over the original anchor's leaf-set.

Disclosure conformance is layered above bundle conformance: a verifier processing a disclosure bundle first satisfies the CONFORMANCE_bundle ordered checks against the disclosure .mbnt's own envelope (and against the original anchor's bundle when fetched or carried), THEN — if manifest.disclosure is present — additionally satisfies the §A–§E checks below. A verifier that does not implement disclosure rendering is still a conformant bundle-v1 verifier; it satisfies §A.1 of this document by tolerating the unknown manifest.disclosure key per bundle-v1.md §9.2 and parsing the rest of the bundle unchanged.

Normative-source pointer

docs/notary_spec/disclosure-v1.md is the normative master spec. Per-profile rules (CSV row / JSON field / text paragraph_sentence) bind into this document by cross-reference; the profile specs at docs/notary_spec/profiles/csv-row-v1.md, docs/notary_spec/profiles/json-field-v1.md, and docs/notary_spec/profiles/text-paragraph-sentence-v1.md are themselves normative for their own preimage / canonicalization / leaf-id / salting rules. This document is a flat checklist mapping each MUST in those sources to a triggering input vector and the required verifier output.

Conformance classes

A verifier that runs the disclosure checks out of order, that silent-skips a missing fail code, or that downgrades a closed failure to a warning under any flag is not conformant.

§A — Manifest tolerance and discovery

Conformance items derived from disclosure-v1.md §2 (where disclosure lives in the bundle) and bundle-v1.md §9.2 (unknown-JSON-key tolerance).

A.1 — Tolerate manifest.disclosure when not implementing disclosure

A.2 — Run §A–§E checks in order on a disclosure-aware verifier

A.3 — Version literal pinning

A.4 — Forever-prohibition: no original-anchor proofs.json carried

§B — Linked-anchor binding chain

The five conformance items below map one-to-one to the five steps of the binding chain in disclosure-v1.md §4. A verifier MUST run them in order; the first failure terminates closed with the indicated code.

Triggering inputs are described as minimal mutations of a known-good disclosure bundle — concretely, of fixture G1 (text disclosure) or G2 (JSON disclosure) of §G, with the named field altered as described.

B.1 — Original-canonical-doc carrier missing

B.2 — Carrier-to-on-chain commit mismatch

Note — on-chain commit well-formedness floor (defense-in-depth). Before performing the carrier-to-commit comparison, a conformant verifier MUST reject an on-chain document_hash that is absent, is not lowercase hex, or is shorter than 40 hex characters (the width of the 20-byte on-chain commitment), failing closed with the same linked_anchor_canonical_hash_mismatch code. This closes a vacuous-match hole: a verifier that compares only the commitment's leading width — e.g. sha256(carrier).slice(0, commit.length) === commit — would accept an empty or truncated commit (slice(0, 0) === "") and bind an arbitrary carrier to the chain. The floor is an additional trigger of the existing §B.2 code, not a new fail-code, so the §B/§C registries are unchanged. Reference implementations pin _MIN_ONCHAIN_COMMIT_HEX_LEN = 40 in both the Python (disclosure/verifier.py) and JS (verify-disclosure.mjs) verifier twins.

B.3 — Carrier root vs. disclosure.linked_anchor.root mismatch

B.4 — Carrier scheme vs. disclosure.linked_anchor.subject_profile mismatch

B.5 — Unsupported linked-anchor algo

§C — Per-revealed-leaf verification

Items map to disclosure-v1.md §7 step 4 (per-revealed-leaf recompute) and §3.4 (merkle-proof invariants). A verifier MUST run these checks for each entry in disclosure.revealed[] before reporting the disclosure verified. Per §7 closing prose, partial verification ("3 of 5 leaves passed") MUST NOT be reported as a success state.

C.1 — Leaf-hash mismatch

C.2 — Merkle path mismatch

C.3 — Per-leaf profile mismatch

C.4 — Invalid hash format

C.5 — View hash mismatch

C.6 — Sealed leaf missing salt

§D — Profile-literal handling

Items derived from disclosure-v1.md §7 step 3, §8 closing bullet, and §11 (profile registry pointer).

D.1 — Unsupported profile literal fails closed

D.2 — Five v1 profile literals MUST be recognized by a fully-conformant verifier

• csv-row-v1 — preimage (standard bare sha256) at docs/notary_spec/profiles/csv-row-v1.md §4 and leaf-id (data-row ordering, header excluded) at §3; canonicalization at §2; salt handling at §5 (standard is UNSALTED) plus the sealed merkle-hmac-sha256 mode at §5b.
• csv-column-v1 — preimage (standard bare sha256 of the LF-joined column) at docs/notary_spec/profiles/csv-column-v1.md §4 and leaf-id (per-column by 0-based header INDEX, header cells excluded from values) at §3; canonicalization (same RFC-4180 §2 as csv-row-v1) at §2; salt handling at §5 (standard UNSALTED) plus the sealed merkle-hmac-sha256 mode at §5b (frozen — the bare "chunk/" per-leaf HKDF info shared with the other three native profiles; csv-column-v1 is in the native-sealed set on equal terms).
• text-line-v1 — preimage (standard bare sha256) at docs/notary_spec/profiles/text-line-v1.md §4 and leaf-id (non-empty-line ordering, no header) at §3; canonicalization (text-norm-v1) at §2; salt handling at §5 (standard is UNSALTED) plus the sealed mode at §5b.
• json-keypath-v1 — preimage (standard bare sha256 of key:jcs(value)) at docs/notary_spec/profiles/json-keypath-v1.md §4 and leaf-id (sorted top-level-key ordering, no header) at §3; canonicalization (json-jcs-v1) at §2; salt handling at §5 (standard is UNSALTED) plus the sealed mode at §5b and the two render modes at §7.
• json-ast-v1 — preimage (sealed HMAC-SHA256(per-leaf salt, utf8(entry)) of the canonical "<pointer>":<value> node entry) at docs/notary_spec/profiles/json-ast-v1.md §4/§5b and leaf-id (one leaf per JSON node — root, every object, every array, every primitive — keyed by RFC-6901 JSON Pointer, no header) at §3; canonicalization (json-jcs-v1, same as json-keypath-v1) at §2. SEALED-ONLY: the only accepted algo is merkle-hmac-sha256 (salt_version: "salt_v1"); a standard (algo: "sha256") json-ast-v1 carrier is rejected at submit with scheme_requires_sealed (finer per-node granularity lowers per-leaf entropy), and json-ast-v1 is in the native-sealed set (see §B.5) but NOT the standard-sha256 set.

The deprecated dotted literals — satsignal.csv.row.v1, satsignal.json.field.v1, satsignal.text.paragraph_sentence.v1 — are NOT part of the required live set. They are inert per disclosure-v1.md §11 (retained in the merkle-scheme allowlist forever and kept as a frozen regression-guard corpus, but no production flow emits or consumes them). A verifier MAY still recognize them to walk legacy bundles, but a fully-conformant verifier is not required to implement them; the live successors are csv-row-v1 (← satsignal.csv.row.v1), json-keypath-v1 (← satsignal.json.field.v1, top-level-key vs. deep RFC-6901 pointer), and text-line-v1 (← satsignal.text.paragraph_sentence.v1, line vs. sentence granularity).

Each profile's preimage / leaf-id construction / canonicalization is normatively defined in the profile spec, not in this document. A verifier that disagrees with the profile spec on any of these rules is non-conformant for that profile literal, regardless of whether the disclosure-v1 plumbing is implemented correctly.

D.3 — Partial-conformance disclosure

• Advertise its supported subset to its caller (the exact surface — CLI flag, API field, README — is implementation-defined).
• Fail closed with unsupported_profile on any disclosure whose linked_anchor.subject_profile is outside the supported subset.
• MUST NOT skip the disclosure check entirely just because the disclosure's profile literal happens to be one the verifier does not support.
• MUST NOT mark the disclosure "verified" or "partially verified" when its profile is unsupported.

A disclosure bundle that involves more than one profile literal is out of scope for v1 — every revealed[i].profile MUST equal linked_anchor.subject_profile (per disclosure-v1.md §3.3 and §C.3 above), so a single disclosure bundle binds exactly one profile. A consumer verifying an audit packet that contains multiple disclosure bundles (each binding its own profile) MUST run the partial-conformance rule per bundle: any bundle whose profile is unsupported fails closed; bundles whose profile is supported verify normally.

§E — Claims rendering

Items derived from disclosure-v1.md §3.6 (claims contract) and §8 (verifier rendering behavior). The claims block is part of the cryptographic commitment (§6 JCS canonicalization) and a verifier that mis-renders it has broken the contract.

E.1 — Required does_not_prove codes present

E.2 — Required proves codes present

E.3 — Verbatim display of does_not_prove text

§F — Merkle-proof invariants

Items cross-reference disclosure-v1.md §3.4 (the merkle-proof invariants). The proof-path walk — the raw-byte fold, the L/R direction encoding, the empty-proof_path single-leaf case — is uniform and shared across every v1 profile and carrier. What is not uniform is the odd-node tree shape: that is a property of the original anchor's tree, encoded into the proof_path, and it differs by anchor. The legacy salted profiles (the deprecated dotted satsignal.csv.row.v1 and the salted JSON / text profiles) use promote-unchanged; the native csv-row-v1 profile (standard and sealed) uses duplicate-last (disclosure-v1.md §3.4). The verifier walks whatever siblings it is given and MUST NOT rebuild the root from an assumed odd-node convention — see §F.3.

F.1 — Raw-byte concatenation (positive vector)

F.2 — Single-leaf tree (proof_path = [])

F.3 — Odd-node behavior: the anchor rule, encoded in the proof_path (structure-agnostic walk)

The odd-node convention is not a verifier-implemented uniform rule — it is the original anchor's tree shape, baked into the proof_path. A conformant verifier is structure-agnostic: it walks the supplied proof_path (folding each {side, hash} sibling into the frontier per §3.4) and compares the final frontier to linked_anchor.root. It does NOT rebuild the root and does NOT assume any single odd-node convention. The two live conventions differ only in how the builder emitted the odd-promoted node; the walk of either is identical machinery.

A verifier that rebuilds the root from an assumed convention is the bug — not one that walks. Concretely it MUST NOT assume promote-unchanged and reject a self-sibling proof_path entry as spurious, and it MUST NOT assume duplicate-last and synthesize a self-sibling level where the proof_path skipped one. Both of the positive vectors below MUST verify.

Positive vector (a) — LEGACY salted, PROMOTE-UNCHANGED (1-entry path).

Positive vector (b) — NATIVE csv-row-v1, DUPLICATE-LAST (2-entry self-sibling path).

Required behavior, precisely. The verifier MUST fold the supplied proof_path siblings (§3.4 raw-byte rule) and compare the final frontier to linked_anchor.root; it MUST verify both a promote-unchanged (skip-level, 1-entry) path and a duplicate-last (self-sibling, 2-entry) path correctly, because the convention is baked into the path it is handed. A verifier that hard-codes one convention and rebuilds the root will fail one of the two vectors above and is non-conformant.

F.4 — Leaf ordering: profile-defined, verifier does NOT re-sort

• csv-row-v1 (the native literal, standard + sealed) — data-row document order, zero-indexed, header (row 0) EXCLUDED; leaf i is data row i = file row i + 1 (csv-row-v1.md §3, "Leaf ordering is data-row document order, zero-indexed").
• satsignal.csv.row.v1 (the deprecated salted dotted literal) — document order, zero-indexed row position, every row a leaf including row 0 (the legacy ordering; csv-row-v1.md §9 deprecation note + the frozen salted corpus). Retained only as the inert promote-unchanged example; new CSV disclosures use the native literal above.
• satsignal.json.field.v1 — depth-first walk in JCS-canonical-key order (json-field-v1.md §3.3).
• satsignal.text.paragraph_sentence.v1 — document order, paragraph then sentence (text-paragraph-sentence-v1.md §9).

The verifier MUST NOT re-sort revealed[], MUST NOT impose a verifier-local sort (e.g. by leaf_id ASCII), and MUST walk each revealed leaf's proof_path from the published leaf_hash exactly as written. A verifier that re-sorts will compute proof-walk paths against the wrong sibling indices and will spuriously report merkle_path_mismatch on conformant disclosures.

§G — Positive conformance vectors

Two end-to-end "happy path" cases that a fully-conformant verifier MUST accept. These fixtures already exist in the profile specs; this section binds them into the disclosure verifier contract by reference.

G.1 — Text disclosure (cites fixture C15)

Source fixture: text-paragraph-sentence-v1.md §11.15 (C15 — the e.g. / i.e. multi-dot-abbreviation fixture).

Construction. Wrap C15 in a disclosure bundle whose manifest.disclosure is:

• version: "satsignal.disclosure.v1"
• disclosure_id: "<any opaque string>"
• linked_anchor.root: 65bc540ee29ee81834460758069e4ed48c2bc05ca8958f11db98ea5b08a060ba (the C15 merkle root, from §11.15)
• linked_anchor.txid: <txid of the original anchor>
• linked_anchor.subject_profile: "satsignal.text.paragraph_sentence.v1"
• linked_anchor.bundle_id: <opaque pointer to the original proof> (bundle_id is the proof id's spelling in the frozen disclosure format)
• revealed[0]: leaf_id=p0/s0, profile=satsignal.text.paragraph_sentence.v1, value="He said e.g. before lunch.", salt_b64=Dw8PDw8PDw8PDw8PDw8PDw==, leaf_hash=be173bfa3463ca7be346c197d5271764a3320c5ecf32408ee0b3aa1fce279882, proof_path=[{"side":"R","hash":"1a455dea1a4456b1bb6af79022bb3bdd77900367a4a91184904d3c395cb9dcb4"}]
• revealed[1]: leaf_id=p0/s1, profile=satsignal.text.paragraph_sentence.v1, value="Then i.e. after.", salt_b64=8PDw8PDw8PDw8PDw8PDw8A==, leaf_hash=1a455dea1a4456b1bb6af79022bb3bdd77900367a4a91184904d3c395cb9dcb4, proof_path=[{"side":"L","hash":"be173bfa3463ca7be346c197d5271764a3320c5ecf32408ee0b3aa1fce279882"}]
• claims: with the three required does_not_prove codes and the two required proves codes (no presentation_integrity unless presentation is included).
• linked_anchor/canonical.json in the .mbnt archive: a canonical doc whose subject.proofs.chunk_merkle = {scheme: "satsignal.text.paragraph_sentence.v1", algo: "sha256", leaf_count: 2, root: "65bc540ee29ee81834460758069e4ed48c2bc05ca8958f11db98ea5b08a060ba"}.

Expected verifier outputs at each §4 / §7 step:

1. §7 step 1 — version literal matches "satsignal.disclosure.v1" → pass.
2. §4 step 1 — carrier linked_anchor/canonical.json present → pass.
3. §4 step 2 — sha256(carrier_bytes) == on_chain_document_hash → pass.
4. §4 step 3 — carrier chunk_merkle.root == 65bc540…0ba == disclosure.linked_anchor.root → pass.
5. §4 step 4 — carrier chunk_merkle.scheme == "satsignal.text.paragraph_sentence.v1" == disclosure.linked_anchor.subject_profile → pass.
6. §4 step 5 — carrier chunk_merkle.algo == "sha256" → pass.
7. §7 step 3 — subject_profile literal recognized by a fully-conformant verifier → pass.
8. §7 step 4 (per-leaf, p0/s0) — preimage recompute via text-paragraph-sentence-v1.md §7 yields be173bfa…9882, matches published leaf_hash; proof-walk from leaf with one side: R sibling yields 65bc540…0ba, matches linked_anchor.root; revealed[0].profile == subject_profile → pass.
9. §7 step 4 (per-leaf, p0/s1) — analogous walk yields 65bc540…0ba → pass.
10. §7 step 5 — no presentation block, no view-hash check → not applicable.
11. §8 claims rendering — three required does_not_prove codes present; required proves codes present (with presentation_integrity omitted by precondition) → pass.

Disclosure VERIFIED.

G.2 — JSON disclosure (cites fixture B1)

Source fixture: json-field-v1.md §8 (B1 — minimal {"name":"Alice","age":42}).

Construction. Wrap B1 in a disclosure bundle whose manifest.disclosure is:

• version: "satsignal.disclosure.v1"
• disclosure_id: "<any opaque string>"
• linked_anchor.root: c1f5e68c87dcbf89ebd99b0967a34e81fb730b70569733c295f9a4769132e17c (the B1 root, from §8)
• linked_anchor.txid: <txid of the original anchor>
• linked_anchor.subject_profile: "satsignal.json.field.v1"
• linked_anchor.bundle_id: <opaque pointer to the original proof> (bundle_id is the proof id's spelling in the frozen disclosure format)
• revealed[0]: leaf_id=/age, profile=satsignal.json.field.v1, value=42, salt_b64=/+N9Hd4a6Sp3vMDBX4kBvQ==, leaf_hash=533e320213e48d42a8a9472c8ad12739a576ab172fd126b632ad4f27a79ae687, proof_path=[{"side":"R","hash":"e5cb099fc0fe04f443c0ff86879162159cfed1fa92c80862a86021d391f9563c"}]
• (Alternatively reveal /name only, with the symmetric side: L proof path. Or reveal both.)
• claims: with the three required does_not_prove codes and the two required proves codes.
• linked_anchor/canonical.json in the .mbnt archive: a canonical doc whose subject.proofs.chunk_merkle = {scheme: "satsignal.json.field.v1", algo: "sha256", leaf_count: 2, root: "c1f5e68c87dcbf89ebd99b0967a34e81fb730b70569733c295f9a4769132e17c"}.

Expected verifier outputs at each §4 / §7 step: mirror G.1's walk verbatim, substituting the B1 root and the json-field-v1.md §4 preimage rule. The preimage rule for revealed[0] is documented explicitly in json-field-v1.md §4.3 (48-byte preimage, sha256 → 533e320213e48d42a8a9472c8ad12739a576ab172fd126b632ad4f27a79ae687).

Disclosure VERIFIED.

G.3 — Native CSV standard disclosure (frozen fixture N1)

Source fixture: tests/vectors/disclosure-v1/csv_row_v1_native/N1.fixture.json the frozen native standard corpus; the inline values mirror profiles/csv-row-v1.md §4/§8 N1 (root 19d82f92265bc904b4f356b1f69bb418e96bca56e57785d2d1ae7c1acc8d5e3e).

Construction. A disclosure bundle over the native standard CSV anchor (name,age,role\nAlice,42,Engineer\nBob,35,Designer\nCarol,29,Writer):

• linked_anchor.subject_profile: "csv-row-v1" (the hyphenated native literal).
• linked_anchor/canonical.json carrier whose subject.proofs.chunk_merkle = {scheme: "csv-row-v1", algo: "sha256", leaf_count: 3, root: 19d82f…5e3e}.
• revealed[] entries carry no salt_b64 (standard is UNSALTED, profiles/csv-row-v1.md §5); each leaf is the bare sha256(utf8(value)).

Expected verifier outputs: the §4 binding chain passes (§4 step 5 admits algo == "sha256"); per-leaf §7 step 4 recomputes each leaf as the bare sha256(utf8(value)) (no salt read) and walks the duplicate-last proof path to the root. Disclosure VERIFIED.

G.4 — Native CSV sealed disclosure (frozen fixture S1)

Source fixture: tests/vectors/disclosure-v1/csv_row_v1_native_sealed/S1.fixture.json the frozen native sealed corpus; the inline values mirror profiles/csv-row-v1.md §5b (root 2207e09f1cafe3cb7099d905d47eef8c998d42a0b2413b3a0a0413110f47f6a3).

Construction. A sealed disclosure bundle over the same CSV anchored in sealed mode:

• linked_anchor.subject_profile: "csv-row-v1".
• linked_anchor/canonical.json carrier whose subject.proofs.chunk_merkle = {scheme: "csv-row-v1", algo: "merkle-hmac-sha256", salt_version: "salt_v1", leaf_count: 3, root: 2207e0…f6a3}.
• revealed[] reveals r000000 (Alice) and r000002 (Carol, the odd-last self-sibling node) and REDACTS r000001 (Bob). Each revealed entry carries salt_b64 = the per-leaf HKDF salt (never the master salt; profiles/csv-row-v1.md §5b.1 master-salt-strip rule) and leaf_hash = the sealed HMAC leaf.

Expected verifier outputs: §4 step 5 admits ("csv-row-v1", "merkle-hmac-sha256") with salt_version == "salt_v1"; per-leaf §7 step 4 recomputes each leaf as HMAC-SHA256(base64decode(salt_b64), utf8(value)) under the published per-leaf salt and walks the duplicate-last proof path (including Carol's two-entry self-sibling path) to the root. Disclosure VERIFIED.

G.5 — Native TEXT standard disclosure (frozen fixture N1)

Source fixture: tests/vectors/disclosure-v1/text_line_v1_native/N1.fixture.json the frozen native standard text corpus; the inline values mirror profiles/text-line-v1.md §4/§8 N1 (root 5e4f6278d3e8f1a8175e8f635e76f828262e48b3f4e5b6ffd326357cc04a607c).

Construction. A disclosure over a native standard TEXT anchor (a .txt with a BOM, a blank line, and a trailing-whitespace line — canon drops the blank line and strips trailing whitespace → 3 non-empty-line leaves; NO header):

• linked_anchor.subject_profile: "text-line-v1" (the hyphenated native literal).
• linked_anchor/canonical.json carrier whose subject.proofs.chunk_merkle = {scheme: "text-line-v1", algo: "sha256", leaf_count: 3, root: 5e4f62…607c}.
• revealed[] reveals l000000 + l000002 (the odd-last self-sibling) and REDACTS l000001; entries carry no salt_b64; each leaf is the bare sha256(utf8(line)).

Expected verifier outputs: §4 binding passes (admits algo == "sha256"); per-leaf §7 step 4 recomputes the bare sha256(utf8(value)) and walks the duplicate-last path to the root. Disclosure VERIFIED.

G.6 — Native TEXT sealed disclosure (frozen fixture S1)

Source fixture: tests/vectors/disclosure-v1/text_line_v1_native_sealed/S1.fixture.json ; the inline values mirror profiles/text-line-v1.md §5b (root 0c108f30ce50f1348d572a9480806d6e0bf990971abb88e440206cd5175b0358).

Construction. A sealed disclosure over the same text anchored in sealed mode:

• linked_anchor.subject_profile: "text-line-v1".
• carrier subject.proofs.chunk_merkle = {scheme: "text-line-v1", algo: "merkle-hmac-sha256", salt_version: "salt_v1", leaf_count: 3, root: 0c108f…0358}.
• revealed[] reveals l000000 + l000002 (odd-last self-sibling), REDACTS l000001; each revealed entry carries salt_b64 = the per-leaf HKDF salt (never the master salt; text-line-v1.md §5b.1) and the sealed HMAC leaf_hash.

Expected verifier outputs: §4 step 5 admits ("text-line-v1", "merkle-hmac-sha256") with salt_version == "salt_v1"; per-leaf §7 step 4 recomputes HMAC-SHA256(base64decode(salt_b64), utf8(value)) and walks the duplicate-last path (including the odd-last two-entry self-sibling path) to the root. Disclosure VERIFIED.

G.7 — Native JSON standard disclosure (frozen fixture N1)

Source fixture: tests/vectors/disclosure-v1/json_keypath_v1_native/N1.fixture.json the frozen native standard JSON corpus; the inline values mirror profiles/json-keypath-v1.md §4/§6/§8 N1 (root 3c06af94a0af735cd19cc77349b7a962464cda703be16c66bbad2395913dbec8).

Construction. A disclosure over a native standard JSON anchor (the compact object {"name":"AcmeCorp","ssn":"123-45-6789","balance":1000,"public_id":42} → JCS canon, objects-only, sorted top-level keys balance,name,public_id,ssn → 4 leaves; NO header):

• linked_anchor.subject_profile: "json-keypath-v1" (the hyphenated native literal).
• linked_anchor/canonical.json carrier whose subject.proofs.chunk_merkle = {scheme: "json-keypath-v1", algo: "sha256", leaf_count: 4, root: 3c06af…dbec8}.
• revealed[] reveals k000001 ("name":"AcmeCorp") + k000002 ("public_id":42) and REDACTS k000000 (balance) + k000003 (ssn); entries carry no salt_b64; each leaf is the bare sha256(utf8(entry)) over the canonical "key":jcs(value) entry. presentation is the drop-mode copy {"name":"AcmeCorp","public_id":42}, view_sha256 = 4d07c173…a444b.

Expected verifier outputs: §4 binding passes (admits algo == "sha256"); per-leaf §7 step 4 recomputes the bare sha256(utf8(value)) over the canonical entry and walks the duplicate-last path to the root. Disclosure VERIFIED.

G.8 — Native JSON sealed disclosure (frozen fixture S1)

Source fixture: tests/vectors/disclosure-v1/json_keypath_v1_native_sealed/S1.fixture.json ; the inline values mirror profiles/json-keypath-v1.md §5b (root 8d8a2a6d5b0490b19501452a729a967e1306df3164d2e8fc129c9afd52cb463c).

Construction. A sealed disclosure over the same object anchored in sealed mode:

• linked_anchor.subject_profile: "json-keypath-v1".
• carrier subject.proofs.chunk_merkle = {scheme: "json-keypath-v1", algo: "merkle-hmac-sha256", salt_version: "salt_v1", leaf_count: 4, root: 8d8a2a…463c}.
• revealed[] reveals k000001 + k000002, REDACTS k000000 + k000003; each revealed entry carries salt_b64 = the per-leaf HKDF salt (never the master salt; json-keypath-v1.md §5b.1) and the sealed HMAC leaf_hash.

Expected verifier outputs: §4 step 5 admits ("json-keypath-v1", "merkle-hmac-sha256") with salt_version == "salt_v1"; per-leaf §7 step 4 recomputes HMAC-SHA256(base64decode(salt_b64), utf8(value)) and walks the duplicate-last path to the root. Disclosure VERIFIED.

§H — Test vector registry

Every fixture used in this document, with file pointers back to the profile-spec source.

The above are the profile-spec prose fixtures. In addition, two frozen JSON disclosure corpora for the native csv-row-v1 profile ship on disk and a conformance runner consumes them directly via tests/vectors/disclosure-v1/schema/fixture.schema.json. Each fixture pins expected.verify_ok (and, for negatives, the expected_fail_code / expected.fail_code); they bind the §B / §C / §D codes to concrete native payloads.

Native CSV — STANDARD corpus (tests/vectors/disclosure-v1/csv_row_v1_native/, algo: "sha256", unsalted):

Native CSV — SEALED corpus (tests/vectors/disclosure-v1/csv_row_v1_native_sealed/, algo: "merkle-hmac-sha256", salt_version: "salt_v1", per-leaf HKDF salts):

Native TEXT — STANDARD corpus (tests/vectors/disclosure-v1/text_line_v1_native/, scheme: "text-line-v1", algo: "sha256", unsalted; NO header, empty lines dropped, duplicate-last):

Native TEXT — SEALED corpus (tests/vectors/disclosure-v1/text_line_v1_native_sealed/, scheme: "text-line-v1", algo: "merkle-hmac-sha256", salt_version: "salt_v1", per-leaf HKDF salts):

Native JSON — STANDARD corpus (tests/vectors/disclosure-v1/json_keypath_v1_native/, scheme: "json-keypath-v1", algo: "sha256", unsalted; JCS canon, objects-only, sorted top-level keys, NO header, duplicate-last):

Native JSON — SEALED corpus (tests/vectors/disclosure-v1/json_keypath_v1_native_sealed/, scheme: "json-keypath-v1", algo: "merkle-hmac-sha256", salt_version: "salt_v1", per-leaf HKDF salts):

The profile-spec prose fixtures above are the existing inline material; this CONFORMANCE document does NOT mint new fixtures. The frozen native corpora are the on-disk frozen material captured against the profile rules; this registry binds them to the §A–§E codes by reference.

§I — Out-of-scope for v1 conformance

Per disclosure-v1.md §12, the following are explicitly out of scope for satsignal.disclosure.v1 conformance. A claim of conformance under this document does NOT imply any of:

• Email-profile conformance. No satsignal.email.sentence.v1 or any other email-shaped profile is part of v1 (per disclosure-v1.md §12 "Email profiles" bullet). A verifier that ships an email-profile implementation does so outside this conformance suite.
• PDF / DOCX native-redaction conformance. Disclosure under v1 generates a new presentation artifact (HTML / TXT / canonical CSV / canonical JSON); it does not mutate the original PDF / DOCX. Native-format redacted-PDF verification is not in scope.
• Word-level / token-level disclosure conformance. No text.word.v1 or text.token.v1. v1's leaf granularity is profile-defined (CSV row, text line, JSON top-level key, text sentence). Sub-line / sub-sentence disclosure is not in scope; sentence-level text disclosure is a planned FUTURE anchor scheme (text-sentence-v1), not part of v1. Deep-field / RFC-6901-pointer JSON disclosure (a leaf per nested field) is likewise NOT this profile — json-keypath-v1 granularity is top-level key only; a deep-field anchor scheme is a planned future scheme, not part of v1.
• Native text-line-v1 disclosure conformance — IN scope. Standard AND sealed disclosure of a native text-line-v1 anchor IS conformant, per profiles/text-line-v1.md and disclosure-v1.md §4.5/§11 (repeats the csv-row-v1 pattern for text; no version-literal bump). A disclosure-aware verifier MUST verify it under the SAME native leaf rule as csv-row-v1 (bare sha256(utf8(value)) standard / HMAC(per-leaf salt, utf8(value)) sealed) — the value is the canonical non-empty line — walking the duplicate-last proof path to the committed root. The text-line-v1 leaf-set EXCLUDES empty lines and has NO header (leaf 0 = first non-empty line).
• Native json-keypath-v1 disclosure conformance — IN scope. Standard AND sealed disclosure of a native json-keypath-v1 anchor IS conformant, per profiles/json-keypath-v1.md and disclosure-v1.md §4.5/§11 (repeats the csv-row-v1 / text-line-v1 pattern for JSON; no version-literal bump). A disclosure-aware verifier MUST verify it under the SAME native leaf rule as csv-row-v1 / text-line-v1 (bare sha256(utf8(value)) standard / HMAC(per-leaf salt, utf8(value)) sealed) — the value is the canonical top-level-key entry "key":jcs(value) (JCS, whitespace-free, NFC) — walking the duplicate-last proof path to the committed root. The json-keypath-v1 leaf-set is the top-level keys sorted by code point, objects-only (a top-level array/scalar has no chunk_merkle and is not redactable), with NO header (leaf 0 = first sorted key). The redacted copy ships in one of TWO owner-chosen render modes (drop default / mask), which are presentation-only — presentation.view_sha256 binds the copy bytes; the proof binds the revealed keys, independent of render mode.
• Sealed-mode native disclosure conformance — IN scope (csv-row-v1, text-line-v1, json-keypath-v1). Sealed-mode disclosure of a native anchor (algo: "merkle-hmac-sha256", salt_version: "salt_v1") IS conformant, per profiles/csv-row-v1.md §5b / profiles/text-line-v1.md §5b / profiles/json-keypath-v1.md §5b and disclosure-v1.md §4.5 (the additive sealed lift — no version-literal bump). A disclosure-aware verifier MUST verify it: recompute each revealed leaf as HMAC-SHA256(base64decode(salt_b64), utf8(value)) under the published per-leaf salt (never the master salt), walk the proof path to the committed root, and report the disclosure verified when the chain holds. The verifier MUST fail closed with sealed_leaf_missing_salt (§C.6) on a sealed revealed leaf lacking its required salt_b64, and with unsupported_linked_algo (§B.5) on a sealed native carrier whose salt_version is not "salt_v1" or on the sealed algo presented for a non-native profile. (Genuinely out of scope: sealed-mode for the salted dotted / json-field-v1 / text-paragraph-sentence-v1 profiles — merkle-hmac-sha256 is native-only, and a verifier encountering it on those profiles fails closed with unsupported_linked_algo per §B.5(b); and any future algo other than "sha256" / "merkle-hmac-sha256".)
• Disclosure Builder (client-side) conformance. The Builder is a client-side artifact; the server only ever sees the disclosure bundle hash for the optional T2 anchor. UI conformance for the Builder is not in scope.
• Canonical schema-extension conformance. canonical.schema.json is not extended for disclosure (per §2 and §12); no subtype: "disclosure" exists. Anyone who emits a canonical doc with a disclosure field has produced a non-conformant canonical doc, and a bundle-v1-conformant verifier will reject it under the existing additionalProperties: false rule (independent of this document).
• New on-chain subtype conformance. No new MBNT subtype byte is allocated for disclosure (per §12). The T2 anchor of a disclosure bundle is mechanically identical to any other standard anchor; on-chain conformance is bundle-v1's concern, not this document's.

§J — Followups (in-tree gaps)

Disclosure conformance has zero executable checks in-tree as of 2026-05-27 — there is no scripts/test_disclosure_*.py runner, no tests/vectors/disclosure-v1/ directory, and no scripts/run_vectors.py-equivalent entry that exercises a frozen disclosure .mbnt against the §A–§F checklist. Every fixture cited in §G and §H lives in a profile spec as prose; none have been captured as a frozen .mbnt. The categories below are tracked followups; adopters needing immediate executable coverage should supply their own against the cited profile fixtures.

1. Disclosure-bundle fixture set. RESOLVED (block layer); partial-RESOLVED (archive layer). A frozen JSON fixture corpus at tests/vectors/disclosure-v1/ carries positive vectors (csv_row_v1/A1.fixture.json through A10 — the DEPRECATED salted satsignal.csv.row.v1 corpus, promote-unchanged, retained as an inert regression guard, distinct from the LIVE native csv-row-v1 vectors N1 (standard) + S1 (sealed) under csv_row_v1_native/ + csv_row_v1_native_sealed/; json_field_v1/B1 through B13; text_paragraph_sentence_v1/C1 through C15) and negative end-to- end vectors for every fail code in §A.3, §B.1–B.5, §C.1–C.6, §D.1, and §E.1–E.2 (one fixture per code under disclosure_end_to_end/negatives/). A stdlib-only conformance runner (Python or any other language) consumes these via tests/vectors/disclosure-v1/schema/fixture.schema.json and runs the §A–§E checklist against the corpus's disclosure_block + linked_anchor_carrier payloads. The fixture-corpus layer also satisfies the cross-language drift-prevention contract: any conformant implementation in any language proves itself by matching every fixture's expected_* byte-for-byte.

Still residual. A frozen .mbnt archive set (binary-zip format with manifest.json + canonical.json + optional proofs.json + optional rendered-view sidecar) is not yet in-tree. The corpus models the disclosure-block and carrier-bytes layers above the bundle envelope; archive-level checks for §A.4 (original_proofs_carrier_forbidden triggered by an unrevealed proofs.json in the zip) and §C.5 (view_hash_mismatch against the rendered artifact delivered with the archive) are not exercised by the JSON corpus and remain open as the residual §J.1 archive-layer gap. Adopters needing archive-layer coverage should ship their own .mbnt test archives wrapped around these fixtures' disclosure blocks.

1. Positive G.1 / G.2 vector capture. The two happy-path vectors in §G are currently described as constructions over profile-spec fixtures (C15 / B1). Capturing them as concrete .mbnt bundles with a published canonical-doc carrier and a published on-chain document_hash (mock or real) would let scripts/test_legacy_bundles.py gain a disclosure sibling — scripts/test_disclosure_bundles.py — that walks §A–§E end-to-end against a frozen archive.
2. Merkle-machinery positive vectors as standalone tests. §F.1 (raw-byte concat), §F.2 (single-leaf tree), §F.3 (odd-node walk — both the legacy salted promote-unchanged 1-entry path and the native csv-row-v1 duplicate-last 2-entry self-sibling path) are crisp arithmetic checks that could be exercised with a tiny stdlib script over the cited profile fixtures without needing a full .mbnt. A targeted scripts/test_merkle_invariants.py would close this gap quickly.
3. §A.4 fail-code mint. RESOLVED. disclosure-v1.md §4's forever-prohibition on the original anchor's proofs.json riding in the disclosure bundle now mints a dedicated fail code: original_proofs_carrier_forbidden. The code is pinned in disclosure-v1.md §4 closing "Forever-prohibition" prose and cited as the required verifier output in §A.4 above. Verifier authors now have a stable identifier to surface for this case; no fallback to generic envelope-level "malformed bundle" is required.
4. Multi-disclosure audit-packet conformance. §D.3 contemplates a consumer verifying an audit packet containing multiple disclosure bundles (each binding its own profile). The verifier behavior is implied by per-bundle conformance, but no audit-packet-level conformance contract is pinned in disclosure-v1.md. A follow-up spec (e.g. audit-packet-v1 revision) should pin the per-bundle roll-up rules.
5. Claims-rendering executable check. §E.3 (verbatim display of does_not_prove text) is a UI invariant and cannot be exercised by a stdlib data-level test. A reference-implementation invariant in verifier.html (analogous to the §2.2 envelope-hardening enforcement at lines 1944–2111 cited in CONFORMANCE_bundle.md) would let adopters point at a known-correct implementation; a linter check would be even better. Currently both are absent.

Cross-references

• docs/notary_spec/disclosure-v1.md — normative spec.
• docs/notary_spec/profiles/csv-row-v1.md — normative native csv-row-v1 profile (the live CSV literal; §9 carries the deprecation pointer for the inert satsignal.csv.row.v1).
• docs/notary_spec/profiles/text-line-v1.md — normative native text-line-v1 profile (the live TEXT literal).
• docs/notary_spec/profiles/json-keypath-v1.md — normative native json-keypath-v1 profile (the live JSON literal).
• docs/notary_spec/profiles/json-field-v1.md — DEPRECATED / INERT satsignal.json.field.v1 profile, retained as a frozen regression-guard corpus only; live successor is json-keypath-v1.
• docs/notary_spec/profiles/text-paragraph-sentence-v1.md — DEPRECATED / INERT satsignal.text.paragraph_sentence.v1 profile, retained as a frozen regression-guard corpus only; live successor is text-line-v1.
• docs/notary_spec/CONFORMANCE.md — provenance-v1 conformance (independent surface).
• docs/notary_spec/CONFORMANCE_bundle.md — bundle-v1 conformance (the layer disclosure conformance sits above).
• docs/notary_spec/bundle-v1.md — .mbnt envelope spec; §9.2 is the unknown-JSON-key tolerance rule §A.1 leans on.
• The manifest-as-bundle architectural decision (internal) — decision authority for the whole shape.

Questions about this specification? Email hello@satsignal.cloud.