Legal hold & redaction receipts

The problem: redaction that cannot prove it respected hold

For buyers in legal and investigations, eDiscovery, and risk, redaction is not a visual edit. It is a legal act that must be separable from destruction. The question opposing counsel will ask is not "did you hide the PII?" It is "can you prove the redacted material was not subject to preservation, and that the original remains intact under your custody?"

Most tooling fails that question in predictable ways. A user draws black boxes in a PDF editor, exports a flattened copy, and moves on. The original is overwritten, the mapping of what was removed is lost, and there is no record of which custodian, policy version, or hold order authorized the disclosure. When a hold notice later expands, the team cannot demonstrate that earlier redactions were hold-aware at the time they ran. Reconstructing that after the fact requires trusting the operator's memory and the desktop log — both challenged in review.

The cost is not theoretical. Over-redaction delays production and invites motions to compel. Under-redaction waives privilege or discloses protected data. Redaction that ignores active hold creates spoliation exposure that no amount of post-hoc attestation cures. Platform teams inherit the worst of this: they are asked to "add logging" when what is needed is a control that makes an impermissible redaction impossible to execute.

This guide treats redaction as a gated operation on your infrastructure: no redaction runs until legal-hold-flag clears the requested scope, redaction-vault executes against the validated original, and a hash-bound receipt captures what was done for verification inside evidence-locker. The original never leaves your custody; the receipt is what travels.

Why black boxes are not evidence

Visual redaction tools optimize for appearance. Auditability requires structure. A blacked-out PDF tells a reviewer nothing about whether the underlying text stream was actually removed, whether the redaction is reversible by copy-paste, or whether an earlier flattened copy destroyed the original. Many editors leave the original text layer intact beneath the annotation — a common source of inadvertent disclosure. Others rasterize and re-OCR, silently altering line breaks, Bates ranges, and custodial metadata.

Even when the tool performs true content removal, generic logs make verification fragile. A log that says "User X redacted Document Y" does not bind the exact byte range redacted, the policy rule that authorized it, or the hold registry version checked. Without a purpose and scope declaration tied to the request, a redaction done for privacy and a redaction done for privilege look identical after the fact. Investigators cannot filter by basis, and legal cannot demonstrate least-privilege disclosure.

The deeper gap is temporal. Legal hold is not a one-time flag. Holds are issued, narrowed, expanded, and released across matters, custodians, and date ranges. A redaction that was permissible on Tuesday may become impermissible on Thursday when a new matter adds the same custodian to hold. If the redaction pipeline does not evaluate hold at execution time against a versioned hold manifest, the team is left arguing that operators "would have checked." Gate-enforced pipelines remove that argument by making the check mandatory and captured in the receipt.

For procurement and risk review, the tell is where the check lives. If hold enforcement lives in a playbook, a ticket, or an operator prompt, it will not survive a controls review. Reviewers expect separation: a deterministic gate that evaluates hold and disclosure policy outside the operator and outside any LLM, emitting a signed receipt that the redaction engine must present to proceed.

Architecture sketch — hold-aware redaction on your infrastructure

No diagram needed. The loop is five stages that run entirely on your infrastructure — VPC, on-prem, or air-gapped — under your key custody and sovereign controls. The pattern keeps originals immutable and makes disclosure provable without moving sensitive content.

1. Hold registry as a versioned artifact

Legal maintains a hold manifest: matter IDs, custodian and data-source scope, date ranges, and hold status. The manifest is versioned and hashed, deployed through your change control, and signed. Every downstream receipt cites the specific hold manifest version evaluated. When a hold expands, the version increments; there is no ambiguity about which redactions were gated under which scope. Legal hold flag exposes this registry as a queryable gate input without copying custodial data into the redaction tool.

2. Pre-execution gate

Before any bytes are altered, the redaction request — asset hash, requested redaction scope, disclosure purpose, and matter context — is evaluated by a deterministic policy gate outside the redaction engine. The gate checks hold overlap, privilege and privacy rules, and approval binding. It emits an allow or deny receipt with policy version hash, rule path, and hold-manifest version. Only allow receipts with a valid signature proceed. Deny receipts are themselves retained as evidence that the control operated.

3. Bounded redaction in the vault

Redaction vault executes only with a valid allow receipt, against the immutable original preserved in evidence locker. The vault removes content at the content layer — text stream, image region, audio segment, or field — and produces two outputs: the redacted disclosure artifact and a redaction map. The map describes what was removed by location and category, hashed and sealed, without retaining the sensitive content in the receipt. Original hash, output hash, and map hash are bound together.

4. Receipt chain and sealing

Each stage emits a signed, hash-chained receipt: request, hold-check, gate decision, execution commitment. The chain is appended to the matter's receipt log and anchored for tamper evidence. Verification is deterministic and offline — re-hash, re-evaluate, verify signatures — using keys held in your infrastructure. A reviewer can confirm that a specific redacted production corresponds to a specific original and a specific hold and policy version without ever accessing the undisclosed content.

5. Verifiable disclosure

What leaves your network for production is the redacted artifact plus its receipt bundle — not the original, not the vault internals. Opposing parties and courts see a disclosure package that can be checked: this artifact was produced by this vault version, under this policy, with this hold status, at this time. If challenged, you reveal only what the matter requires, while the internal receipt chain remains available for privilege review on your infrastructure.

What the fix looks like in practice

The migration is incremental. You do not replace your DMS, eDiscovery platform, or review tool. You wrap disclosure paths in gates and vaults that are enforced before effects.

Start by inventorying disclosure surfaces. Every export, production, FOIA response, or internal share that redacts content is a candidate for gating. For each, require a structured redaction request with disclosure purpose and matter binding. Purpose as a mandatory field eliminates silent over-collection where an operator "helpfully" redacts an adjacent file not in scope.

Externalize hold and redaction policy together. Move rules out of checklists and into versioned policy packs with content hashes. Each gate receipt cites the exact pack version. When legal narrows a hold or privilege review updates a rule, the trail shows which production was governed by which version — the basic expectation in any spoliation inquiry.

Enforce vault ordering. Request, gate, then execute — never execute then log. The redaction engine must verify the gate signature with a key under your custody. Compromise of a workstation or a reviewer account alone does not authorize disclosure. On your infrastructure this maps to service identities and hardware-backed keys so the integrity of the receipt chain does not rest on a single host.

Close the loop with reviewer workflow inside evidence locker. Legal and compliance need to sample productions, filter by matter or custodian, view hold status and policy rule at time of redaction, and confirm hash correspondence between original and production. The evidence locker presents that review surface without exposing raw custodial content to every reviewer. Purpose-limited review becomes a policy check, not a data-copy.

Verification — receipts, hashes, and gates

A redaction that cannot be verified independently is an assertion, not a control. Verification is the set of checks that let an auditor confirm, without trusting the redaction workstation, that each disclosure respected hold and policy and that the original remains preserved.

Receipts capture who, what matter, what purpose, what was redacted (by category and location, not by content), what hold and policy versions were evaluated, and when — each signed by the service that emitted it and chained to its predecessor by hash. The vault's execution receipt includes both input and output hashes and the redaction-map hash, so silent substitution of a different original or a different production is detectable.

Hashes preserve verifiability while respecting minimization. The receipt chain commits to payloads by hash; reviewers re-hash the redacted artifact and the redaction map and compare to commitments without needing the withheld content. Hash chaining across the sequence means any insertion, deletion, or reordering breaks the chain at the point of tampering.

Gates make replay possible. Given the structured request, the hold manifest version, and the policy bundle — all identified by hash — a reviewer re-runs gate evaluation deterministically and confirms the recorded allow or deny matches the replay. Because gate logic is policy-as-code without LLM inference, there is no non-determinism to explain away.

Product map — how the pieces fit

Lorca Labs provides the hold-aware redaction loop as composable components that run on your infrastructure. Each maps to a stage above and can be evaluated independently in Studio before you commit to a pilot.

Together these form the loop legal teams need to defend: hold evaluated before redaction, original preserved in the locker, disclosure provable by receipt chain. Every experiment is available at /studio with no signup, running against an isolated demo host. When you are ready, the same binaries deploy on your infrastructure for NDA pilots under your sovereign controls and pre-production gating.

Buyer checklist — before you produce

• Originals immutable? Original hash captured at ingest in the evidence locker; no redaction overwrites the source.
• Hold gate mandatory? No disclosure path bypasses legal-hold-flag; deny is default, allow requires receipt.
• Policy versioned? Redaction rules are hashed bundles; every receipt cites the version that governed it.
• Receipt chain complete? Request → hold-check → gate → execution → anchor, hash-chained and signed under your keys.
• Verification offline? Reviewer can re-hash and re-evaluate without trusting the redaction host or accessing withheld content.