Redaction

POST /lmkit/v1/pdf-redact permanently DELETES content instead of drawing a black box over it. Text glyphs are removed from the content streams, image pixels are scrubbed and re-encoded, vector graphics are trimmed, intersecting annotations are deleted, and content nested inside shared Form XObjects is processed per instance, so redacting one occurrence never silently blanks another page reusing the same resource. The removed content cannot be recovered from the output by text extraction, raw stream inspection, or rendering. That is the difference between redaction and decoration, and it is not pedantry: cover-up "redaction" keeps leaking real documents, which is why the NSA's redaction guidance exists.

1Three ways to say what goes#

Selectors combine freely in one call:

An encrypted source opens with password; the output carries no trace of what was removed.

2Scope: what kinds of content are in play#

Redaction's reach is explicit, not implied. Four toggles say which content classes a selector may destroy, so a text-only policy cannot accidentally scrub a diagram, and a scorched-earth policy can:

• redact_images: pixels under the target regions are cleared and the images re-encoded.
• redact_vector_graphics: paths and shapes intersecting the regions are trimmed away.
• remove_annotations: annotations intersecting the regions are deleted with the content.
• recurse_into_forms: content inside Form XObjects (shared, reusable content blocks) is processed per instance rather than skipped.

Surviving content is untouched: removal is glyph-granular and pixel-granular, so the sentence keeps every word you did not target.

3Marks are policy, not protection#

draw_fill_boxes optionally paints a box (in fill_color) where content was destroyed. The box is PURELY visual: the content is equally gone without it. Some workflows want the classic black bar as a reading signal ("something was here"); others, like anonymized datasets, want no visual trace at all. Both are one flag, and neither changes what an attacker can recover, which is nothing.

4The response is forensic, and verification is one call#

The response returns the redacted document as a file id plus counters that make the operation auditable: content_removed and pages_processed at the top, search_matches for how many occurrences the terms hit, and the removal ledger: removed_glyphs, removed_text_objects, edited_text_objects, edited_images, removed_images, removed_paths, edited_forms, removed_annotations. A compliance record can state precisely what the operation did.

Then PROVE it: run pdf-search for the redacted terms against the output file id. Zero matches on a search that includes fuzzy mode is the verification a reviewer can rerun at any time, against the artifact itself rather than a log entry. If the document must remain archival, note that redaction is a rewrite: re-validate PDF/A conformance afterward.

5The compliance pipeline#

The high-leverage composition, out of endpoints in this library:

1. PII detection over the document returns what it found and where.
2. A human reviews the findings: detection proposes, a person disposes.
3. The confirmed strings feed search_terms; area selections cover anything visual.
4. pdf-search on the output proves absence; the counters and the search report are the evidence trail.

Detection, review, destruction, proof: two endpoint calls and one human checkpoint around the decision that actually needs one.

6Stated plainly#

• Redaction here means the content is GONE, at glyph, pixel, path, and annotation granularity, with shared resources handled per instance.
• Selectors, scope toggles, and visual marks are separate decisions, so the call states policy exactly; the counters state what happened exactly.
• Absence is verifiable by searching the output, which turns "trust us" into "check it".