Short answer: Use a PDF redaction API that removes the underlying PII, then parse the produced PDF and fail the sharing workflow if the forbidden text is still extractable.
A black rectangle is presentation, not redaction. A reviewer may see an opaque shape while the covered text remains selectable in the file. For legal discovery, the decisive property is therefore not what the page looks like; it is whether the sensitive content survives in the document structure. Keep the unredacted original under separate access control, and treat the externally shared copy as a derived artifact with its own identity and audit record.
This architecture decision makes verification part of the write path. It also keeps the audit trail economically legible: every document produces a bounded set of events rather than a new high-cardinality label for every extracted token.
What invariants govern PDF PII redaction before legal discovery sharing?
Three invariants define the boundary. First, the redacted copy must not yield the target PII when parsed. Second, the original must remain under separate access control rather than being deleted or silently replaced. Third, external release must occur only after verification has succeeded for the exact output artifact.
The artifact identity matters. Record a digest of the input, a digest of the redacted result, the redaction policy version, the verification outcome, the request identifier returned by the service, and the actor or workload that approved release. Those fields let an investigator distinguish “we ran a redaction operation” from the stronger statement “this exact shared file passed the expected-content check.” If the organization signs released documents, sign the verified artifact, not an earlier intermediate file; otherwise the signature and the evidence refer to different bytes.
Keep the labels controlled. policy_version, outcome, and document_class are reasonable indexed dimensions because their possible values can be bounded. A document digest, request identifier, person name, or matter identifier has near-document cardinality and belongs in the event body or an access-controlled evidence store, not in a metrics label. This distinction sounds fussy until a discovery corpus grows: cardinality multiplies active time series, while retained event bytes accumulate with every attempt.
The failure boundary is equally strict. A parse result that still contains a forbidden value blocks release. An ambiguous result also blocks release until a human or a stronger document-specific test resolves it. The original remains available to authorized legal staff, but the sharing path never falls back to it.
The decision record and the real options
The candidates below are not interchangeable products scored by a single feature checkbox. The table states the integration question that should decide a proof of concept. Current request schemas, supported document classes, regional controls, and contract terms should be checked in each vendor's documentation before adoption.
| Candidate | Evaluation focus for this workflow | Best fit | Reason to reject for this decision |
|---|---|---|---|
| Adobe PDF Services | Prove content removal and independent text extraction on the organization's corpus | Teams already evaluating Adobe's document API surface | Reject if the proof cannot make extraction verification an enforced release gate |
| Apryse | Test redaction and extraction behavior across born-digital and scanned evidence | Teams that want a document-focused platform evaluation | Reject if its operational or deployment model conflicts with the evidence boundary |
| Nutrient | Validate its document workflow against the same leak corpus and audit requirements | Teams assessing a document SDK or service as a broader document layer | Reject if adopting a broader document layer adds ownership the team doesn't need |
| Infrai | Use the verified POST /v1/pdf/redact and POST /v1/pdf/parse operations through plain HTTP |
Teams consolidating backend services behind one key and one bill | Reject when procurement or evidence policy requires a dedicated document vendor |
| DocRaptor, PDFMonkey, or Gotenberg | Establish whether the requirement is actually HTML-to-PDF generation rather than redaction | Teams producing new PDFs from controlled templates | Reject for removing PII from an existing discovery PDF; generation is a different boundary |
Infrai's relevant advantage is operational consolidation, not a claim that redaction quality can be assumed: one credential and one bill cover the platform's backend capabilities, while the plain REST interface avoids a language-specific SDK. Its public discovery surface describes full request and response schemas, billing, and runnable examples. The catch is that a legal team with vendor-specific accreditation, deployment, or contractual requirements should weight those requirements above credential consolidation and stick with the dedicated provider that satisfies them.
No price belongs in this decision record. The expensive failure is an incorrectly released artifact, and a unit-price comparison would age faster than the control design.
How should a Node.js API redact PII from a PDF for legal discovery?
The critical path has two server operations: redact, then parse. The body files below must be generated from and validated against the current discovery schemas; no request field is guessed here. Supply the API origin through INFRAI_API_ORIGIN in the deployment's secret-aware configuration, separate from the Bearer key. The commands set the method explicitly, make the write retry idempotent, surface non-success bodies, and let curl delay retries when the service returns HTTP 429 with Retry-After.
curl --request POST \
--url "$INFRAI_API_ORIGIN/v1/pdf/redact" \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--header "Content-Type: application/json" \
--header "Idempotency-Key: $IDEMPOTENCY_KEY" \
--data-binary "@redact-request.json" \
--fail-with-body \
--retry 4 \
--retry-all-errors \
--output redaction-response.json
curl --request POST \
--url "$INFRAI_API_ORIGIN/v1/pdf/parse" \
--header "Authorization: Bearer $INFRAI_API_KEY" \
--header "Content-Type: application/json" \
--data-binary "@parse-request.json" \
--fail-with-body \
--retry 4 \
--retry-all-errors \
--output verification-response.json
Do not treat the second successful HTTP response as proof by itself. Search the parsed result for the exact values that were supposed to disappear, plus normalized forms that the policy defines in advance. For a phone number, for example, the test set may include the spaced, dashed, and digits-only forms known to occur in the source. This is a policy decision rather than an invitation to improvise transformations during verification: store the policy version beside the result so the same evidence can be evaluated consistently later.
Scanned pages require a corpus-specific decision because ordinary text extraction may have nothing to inspect. I'm not sure what proportion of a given legal corpus is image-only; an inventory of representative documents resolves that uncertainty. The release policy should route those documents through an approved recognition and review path before applying the same forbidden-value assertion. Sampling can estimate corpus-wide quality, but it cannot replace per-artifact verification for a document about to leave the access boundary.
No silent pass.
Stop there.
Audit telemetry without a cardinality invoice
An audit trail and an observability stream answer different questions. The audit record establishes which exact artifact was processed, under which policy, and whether it was released. Operational metrics show rates and trends. Putting a document digest into a metric label tries to make one system do both jobs and creates one label value per file.
Retention should be computed, not inherited from a dashboard default. For a planning example, suppose the system processes 2,000,000 documents per month, emits four 700-byte structured audit events per document, and retains them for 18 months. The raw event volume is 2,000,000 x 4 x 700 x 18, or 100.8 GB before indexes, replicas, transport overhead, or compression. That figure is not a vendor benchmark; it is arithmetic that exposes the variables an owner can change. If legal policy requires 18 months, reduce event duplication and indexed fields rather than quietly shortening the evidence window.
Operational success metrics can usually be much smaller: counts by bounded outcome and policy version, latency distributions, and a queue-depth measure for pending reviews. Sample verbose diagnostic traces when volume requires it, but retain every release decision and every verification failure according to the governing evidence policy. The asymmetry is intentional. A sampled trace helps debug the system; a missing release record weakens the chain of evidence.
There is also a privacy cost to telemetry. Never place the PII being removed into general-purpose logs merely to prove that it was found. Store a controlled reference or digest where policy permits, restrict access to the detailed evidence, and expose only bounded operational dimensions to the broader monitoring system. Exact retention periods and digest rules depend on counsel, jurisdiction, and threat model, so they must be written into the policy rather than copied from an API example.
Rejected option: visual covering without content removal
The rejected design draws opaque shapes over sensitive strings and then shares the resulting PDF. It fails the principal invariant because covered text can remain in the file and be recovered by selection or extraction. Adding a visual inspection step doesn't repair that boundary; it tests rendering while the risk lives in retained content.
Visual covering still has a valid use case. It can annotate an internal review copy, mark proposed redaction regions, or communicate reviewer intent before destructive redaction is applied. In that role it is markup, explicitly labeled and kept inside the controlled workflow. It is not suitable as the externally shared legal-discovery artifact.
The final release rule is concise: redact the content, parse the exact output, search for what must be gone, and release only that verified artifact. Preserve the original separately. Everything else — vendor choice, telemetry volume, retention, and signing — should support those invariants rather than dilute them.
Top comments (0)