Kar-Veil

What this is

When an AI (or a person) redacts a document — blacking out names, case numbers, health details, source material — there is normally no way for anyone downstream to check that only the declared parts were touched. Maybe a redaction tool also silently rewrote a sentence. Maybe an extra line quietly vanished. Kar-Veil turns that into something anyone can check by recomputation, not by trusting the redactor's word.

You commit an original document to a single 64-character fingerprint (a Merkle root) before any redaction happens. Later, whoever redacts it publishes a veil proof: the exact text of every line they left visible, plus only the already-known hash of every line they hid. Anyone can recompute the fingerprint from that proof and check it lands on the exact same root — with zero access to the hidden content. If a visible line was quietly edited, or a line was added, dropped, or reordered, the recomputed root will not match, and Kar-Veil names exactly what broke.

Honest limits

• This proves structural faithfulness — that the visible parts are exactly what they claim to be and nothing else changed. It says nothing about whether the redaction was legally correct or whether it removed enough.
• It only means something if the root was written down independently, before the redaction — posted publicly, filed with a notary, committed to git, or anchored with a tool like kar-anchor. Kar-Veil does not do that recording step for you.
• The unit of redaction is a whole line. To redact part of a line, split the sensitive span onto its own line before you commit.
• It cannot verify who did the redacting or when, beyond an optional signature you supply and vouch for yourself.

Paste the full original document. It is split into lines and each line is hashed with SHA-256 (position-bound), then folded pairwise into one Merkle root.

Uses the document you just committed if there is one, or paste the original again. Tick every line you want to hide, then generate the proof — it contains the full text of every other line, and only the hash of the lines you ticked.

Paste a veil proof. Kar-Veil recomputes the hash of every revealed line fresh from the text in front of it — it never trusts a hash the proof itself states for a visible line — folds in the declared hashes for the hidden lines, and checks the result against the root.

Loads a sample document, commits it, redacts two lines, generates a proof, and verifies it — live, in this page. Then tampers with the proof and re-verifies, so you can see the exact catch happen.

How it works

1. Commit. The document is split into lines. Each line is hashed as SHA-256("leaf:" + index + ":" + line) — the position is baked into the hash. The line hashes are folded pairwise with SHA-256("node:" + left + ":" + right) up to one root. An odd hash at any level is promoted unchanged rather than duplicated against itself, which avoids a known ambiguity class in naive duplicate-last-node Merkle trees.
2. Redact. The proof carries the plain text of every line left visible, and — for hidden lines only — the leaf hash that was already fixed at commit time. The hidden content itself never appears in the proof.
3. Verify. A verifier recomputes the leaf hash of every visible line from what is actually in front of them, slots in the declared hashes for the hidden lines at their stated positions, rebuilds the same fold, and compares the result to the root. Forging a hidden line's hash so the final root still matches would require breaking SHA-256's collision resistance, not just trusting the redactor.

FAQ

Why lines, and not the whole document or individual words?

Whole-document hashing only tells you "changed" or "not changed" — it cannot support partial disclosure. Word-level hashing gets tangled in whitespace and structure. Lines are the natural unit for the documents this targets: letters, transcripts, reports, disclosures.

Does this replace a human redaction review?

No. It makes the result of a redaction decision checkable after the fact. It has no opinion on what should have been redacted.

Can I use this on a PDF or a scanned image?

Only via its extracted text. Anything not captured in the text you paste — layout, metadata, images — is outside the commitment.

Does the verifier ever need the original document?

No — that is the entire point. Only whoever generates a proof needs the original. A verifier needs the proof and, ideally, a root they already trust from before the redaction.

What does the optional signature actually prove?

That whoever held that specific private key signed that specific root. It is not a timestamp, and it does not by itself tell you who that key belongs to — that binding is on you, the same as any public key.