Verifiable redaction

Most redaction asks you to trust the redactor: that the black bars cover the sensitive data, that nothing else changed, that the policy ran at all. Conclave replaces that trust with a cryptographic receipt. It detects and strips regulated data (PCI, PHI, PII) inside a hardware enclave, before anything is stored in the clear, writes a new immutable clean version, and signs a completeness receipt anyone can verify offline on their own machine, with no server and no account.

One mechanism, two problems:

• Compliance — a missed card number or SSN is a breach. Detection runs in-enclave and deterministically, gated on measured recall.
• Trust — a recipient (opposing counsel, an auditor, a regulator) can prove the redaction ran and see exactly what was removed, without trusting Conclave or the sender.

Verify, don't trust

The receipt and the verifier are the whole feature.

The receipt. When the enclave redacts, it emits an Ed25519-signed record:

{ schema: "conclave-redaction/v1", code_measurement,
  input_version_root, H(policy), detections[], dispositions[], output_version_root }

It binds the policy, its version, and every detection to the input and output version roots. It is location-revealed and content-hidden: it shows where and what class was removed, never the removed content. It is float-free, so it verifies bit-for-bit in any language.

The verifier. A single self-contained HTML file (/redaction-verifier.html, WebCrypto Ed25519, zero dependencies) checks a receipt against the published verification key, with no server round-trip and no Conclave account. It confirms the redaction policy ran over the entire input and exactly which spans were removed, by class. The signing key is born inside Intel TDX and bound into the enclave's attestation quote, so the record's enclave origin is provable too: cryptographic evidence it was produced in a genuine sealed enclave, not on a server.

That is what "verify, don't trust" means in practice: a check the recipient runs themselves.

What it strips

Detection runs in-enclave, deterministically, with no LLM. v1 covers seven structured classes: card numbers (regex → normalize → Luhn + BIN), SSN, ABA routing (checksum), context-gated account numbers, phone, email, and context-gated DOB. It catches a card number read aloud the same as a typed one (spoken, spaced, and grouped renderings). A recall/precision harness runs the detectors against a trap corpus and fails the build if per-class recall drops below its floor.

The strip is enclave-native and immutable:

• each detected span becomes a [REDACTED:<class>] marker in a new, system-authored transcript version (the original version stays immutable),
• derived insights are regenerated from the redacted text, never the raw,
• the sealed audio is frame-muted into an encrypted clean derivative; the original sealed recording is untouched,
• only the clean version is shareable or exportable. Any pre-redaction cleartext stays inside the TEE-sealed volume.

Bring your own policy

The detectors above are Conclave's default policy. The receipt is built to carry any policy: the schema binds H(policy), the hash of the exact ruleset that ran, into the signed record. That is the hook for custom verifiable redaction.

A customer defines their own policy — their own regex and pattern set, their own categories (matter numbers, client names, internal codenames, contract IDs, whatever their compliance regime demands). The enclave runs that policy and emits the same conclave-redaction/v1 receipt, signed the same way.

Because H(policy) is bound into the receipt, an auditor verifies offline that your specific policy ran over this specific transcript, and sees exactly which spans it removed and under which category. Bring your own redaction rules, get the same cryptographic proof.

The receipt already carries H(policy), so the verification story is real today. The expanded policy surface — customer-defined categories and free-form PHI/PII — is v2 (below), not yet shipped.

The chain it rides on

The receipt is the last link in a cryptographic chain of custody Conclave already builds:

Each link references the previous link's commitment, so a verifier can trace a redacted export back to audio sealed at capture. Every step is signed, and the final check runs on the recipient's own machine.

Roadmap

• v1 — live today. Deterministic in-enclave detection of structured regulated data: card numbers (Luhn-checked), SSNs, and structured PHI/PII, stripped before anything is stored in the clear, plus a signed conclave-redaction/v1 completeness receipt anyone verifies offline with the single-file WebCrypto verifier. Today's receipt proves the policy ran and exactly what it removed. Shipped 2026-07-21.
• v2 — custom and free-form. Customer-defined policies (your own categories and patterns) and free-form PHI/PII detection for names, health conditions, addresses, and org-specific identifiers, on the same strip-and-attest pipeline. This is where bring-your-own-policy redaction lands. The receipt already binds H(policy), so the same offline proof covers your rules the day they run. Not yet shipped.
• v3 — byte-identical faithful-derivative proof. A salted-Merkle commitment proving the redacted transcript is byte-identical to the sealed original everywhere except the removed spans, verifiable offline. Today's receipt proves the policy ran and what it removed; v3 adds that the rest is provably untouched. Not shipped. The version chain already reserves the fields for it.