# Sealed deep-content sample — anchor everything, disclose selectively

Two synthetic agent-run artifacts, anchored on BSV mainnet in **sealed
deep-content mode** and then selectively disclosed:

| file | what it is | what is withheld in the disclosure |
|---|---|---|
| `agent-run.txt` | an agent's end-of-session run report | the customer-identity paragraph (name, account, invoice, refund amount, email) |
| `session-policy.json` | the session policy the agent ran under (model, tools, limits) | the `credentials` object (key-vault ref, webhook secret) |

Everything here is synthetic demo content. The anchors are real:
`ANCHORS.md` has the transaction ids, on-chain hashes, and verification
pointers.

## Why deep content hashing

A byte-exact sealed anchor commits to one hash of the whole file. That
proves the file later — but only **all-or-nothing**: reveal every byte
or prove nothing.

A **sealed deep-content** anchor hashes the *content structure* instead:
text gets one salted leaf per paragraph, sentence, and token
(`text-tree-v1`); JSON gets one salted leaf per node (`json-ast-v1`).
All leaves roll up to a single Merkle root, so the on-chain footprint is
identical — one commitment, same cost. The gains:

- **The notary never sees the plaintext.** Hashing happens client-side;
  only the salted hash tree — never the text itself — leaves your
  machine.
- **Selective disclosure stays possible forever.** Reveal exactly the
  paragraphs or JSON fields you choose — later, offline, with no key,
  no notary, and no re-anchor. Withheld spans collapse to `[REDACTED]`
  in the shared copy, and the per-leaf salts make them unguessable
  (no dictionary attack on the hidden hashes).
- **Every revealed span is independently provable.** A recipient with
  neither the original file nor the salt can confirm the revealed text
  is exactly what was anchored, and any edit to the disclosure bundle
  or the redacted copy is rejected with a specific failure code.

## Verify it yourself

1. **Web:** open the verifier at
   [proof.satsignal.cloud/verify](https://proof.satsignal.cloud/verify)
   and drop in a `*.disclosure.mbnt` from this folder together with its
   `*.redacted.*` copy. The verifier recomputes the Merkle binding and
   confirms the anchor transaction on a public BSV node.
2. **Chain:** open the `txid` from `ANCHORS.md` on WhatsOnChain. The
   `OP_RETURN` carries the 20-byte `doc_hash` — the first 20 bytes of
   sha256 of the carrier document committed in the disclosure bundle.
3. **Tamper test:** change any character of a redacted copy and re-run
   the verifier — the check fails.

The `*.disclosure.mbnt` bundles are **salt-stripped** and safe to share;
they cannot be used to reveal more than what their owner disclosed.

## How it was made

Made with Satsignal's disclosure tooling — the same pure modules the
in-browser verifier runs, served publicly at
[proof.satsignal.cloud/static/disclosure-builder/](https://proof.satsignal.cloud/static/disclosure-builder/index.html):
sealed deep-content anchoring with client-side hashing, then offline
selective disclosure. The packaged `satsignal-anchor` /
`satsignal-redact` CLIs are **not yet published** — `npm install`
will 404 today; for the runnable headless recipe see
[the headless redaction guide](https://proof.satsignal.cloud/guide-headless-redaction),
or contact hello@satsignal.cloud. The originals are published here
on purpose so you can reproduce every hash; in real use the original
never leaves the owner's machine, and the master salt rides only in the
owner's source bundle — private to the owner's workspace, never in the
published disclosures.