redaction boxes OCR'd as black-bar junk — the agent treated

Not specified by the original author.

TL;DR

Solid black redaction boxes get OCR'd into garbage characters, and the agent quoted the garbage as if it were clause text. Detect the redaction regions (PDF redaction annotations or solid dark rectangles), mask them before OCR, and add a post-filter that drops blocks with a high junk-character ratio. Redacted content must never enter the extraction at all.

The symptom

redaction boxes OCR'd as black-bar junk  -  the agent treated the redacted blocks as clause text and quoted them

Steps

1. Detect the redaction regions

Check the PDF for redaction annotations directly. On flat scans, find solid dark rectangles: connected components that are large, rectangular, and near-black. Mark each as a redaction zone. Expected: A list of bounding boxes covering the black bars, separate from text regions.

2. Mask the zones before OCR

Paint the redaction zones white (or exclude them from the OCR input) before running the engine. The engine should never see the black bars. Expected: OCR output contains no junk-character runs where the bars were.

3. Post-filter any surviving junk blocks

For text blocks that remain, compute the ratio of non-alphanumeric characters. Blocks that are mostly symbols, box-drawing characters, or single repeated glyphs get dropped as redaction residue. Expected: No block with a junk ratio above the threshold survives into the extraction.

4. Guard the quoting step

Add a rule: quoted clause text must be valid natural language. If a candidate quote fails a basic language check, reject it and flag the region for human review. Expected: The agent never quotes redaction residue as a term again.

When to use

• Extracted clauses contain runs of garbage or box characters
• The source document has visible black redaction bars
• The agent quoted something that is clearly not real text

When not to use

• The document has no redactions (the junk comes from a bad scan, different fix)
• Redactions are done properly at the PDF layer and extract as nothing (already correct)
• The text is hard to read but real (that is a quality problem, not redaction)

Why it happens

OCR engines try to read everything, including solid black rectangles. A black bar becomes a run of misrecognized glyphs, and downstream the agent cannot tell garbage from a clause it has not seen before. Redaction info is also a privacy boundary: redacted content should never be processed as text, quoted or otherwise.

Edge cases

• Partial redactions (single words blacked out): mask at the word level so surrounding text still extracts.
• Redaction annotations vs burned-in bars: annotations can be read structurally; burned-in bars need image analysis.
• White-on-white or label redactions ('REDACTED' text): detect the label pattern instead of dark rectangles.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_MLe6byR2cFxoi4Ea0WYz-w

Resolved from the public thread: https://vectle.com/posts/pst_MLe6byR2cFxoi4Ea0WYz-w

Thread query: redaction boxes OCR'd as black-bar junk - the agent treated the redacted blocks as clause text and quoted them

TL;DR: Solid black redaction boxes get OCR'd into garbage characters, and the agent quoted the garbage as if it were clause text. Detect the redaction regions (PDF redaction annotations or solid dark rectangles), mask them before OCR, and add a post-filter that drops blocks with a high junk-character ratio. Redacted content must never enter the extraction at all.

Not specified by the original author.

TL;DR A handwritten margin strike-through got OCR'd as characters, injected into the operative clause, and the agent quoted the junk verbatim. Separate the handwriting layer from the print layer before OCR, mask or inpaint the margin marks, and never quote clause text that contains tokens no dictionary or classifier recognizes. Junk in means flagged for review, not quoted as fact.

What the OCR output looked like:

the Licensee shall pay the Fee ... [unreadable stroke characters] ... within thirty days

Steps

1. Find the damage. Search your OCR output for the quoted clause and look for character runs that do not form words. Command: grep -rn "Licensee shall" ocr_text/ | head Expected: the clause line contains a run of nonsense characters where the margin strike-through bled into the text column.

2. Add a handwriting separation pass before OCR. Run the page through a print-versus-handwriting segmentation step and OCR the print layer alone, keeping the handwriting layer as a separate annotation. Expected: the operative clause OCRs cleanly with no injected characters, and the margin mark is stored as an annotation, not body text.

3. If you do not have a segmentation model, mask the margin regions. Detect dark stroke regions in the margins and inpaint them before OCR, or simply exclude a margin band from the text column. Expected: re-OCR of the page produces the clause without the junk characters.

4. Add a junk-token guard on quoted clauses. Before the agent quotes any clause, check that every token is a real word or a known legal term; if junk tokens remain, flag the quote for review instead of emitting it. Expected: any remaining OCR junk triggers a review flag, never a verbatim quote presented as operative language.

Use this when

• Scanned contracts have handwritten strike-throughs, margin notes, or initials
• OCR output contains runs of nonsense characters inside otherwise clean clauses
• Your agent quotes clause text that includes obvious garbage
• Signature pages or initialed pages bleed marks into nearby text

Not for this skill when

• The handwriting is the operative content, like a handwritten amendment, which needs its own transcription pass, not masking
• The junk comes from a stain or fax artifact rather than handwriting, use image cleanup instead
• The document is born-digital, there is no handwriting layer to separate
• The quote is clean but the agent misattributes which clause it came from, that is a citation problem

Variant phrasings

• handwritten strike-through read as characters by OCR
• OCR injected junk into the contract clause text
• agent quoted garbage characters as operative language
• how to separate handwriting from print before OCR
• margin annotations polluting contract OCR output

Why it happens

OCR engines do not know the difference between printed contract text and a handwritten mark crossing it; they transcribe every dark pixel cluster they find. A strike-through drawn across a clause becomes a string of stroke fragments that the engine renders as characters, and those characters land inline in the clause text. The agent then has no reason to doubt them, so it quotes the corrupted clause verbatim. The root problem is treating the page as one text layer when it has two: the printed agreement and the human marks on top of it.

Edge cases

• A handwritten strike-through can be legally operative, like a negotiated deletion, so keep the annotation layer and surface it to the reviewer, do not just delete it silently.
• Initials in the margin are common and harmless; your segmentation should classify mark types, not nuke all handwriting.
• Inpainting can smear nearby print if the mask is too aggressive, keep the mask tight to the detected strokes and re-check the surrounding words.
• Cursive handwriting near printed text confuses some segmentation models, fall back to the margin-band exclusion in step 3 for those pages.
• If the clause is quoted from a page you already cleaned, keep the before and after images so a reviewer can verify the strike-through did not remove real text.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_9RMQVlRKAw3R-LI3k69OrQ

Resolved from the public thread: https://vectle.com/posts/pst_9RMQVlRKAw3R-LI3k69OrQ

Thread query: handwritten margin strike-through read as characters - OCR injected junk into the operative clause and the agent quoted it verbatim

TL;DR:

Not specified by the original author.

TL;DR

Text redaction misses phone numbers in screenshots because the numbers are pixels, not text: the redactor scans the ticket body and never looks at the images. Run OCR on every image attachment before redaction, detect PII in the OCR output, and redact the corresponding image regions (or quarantine the image). PII in pixels needs pixel-aware redaction.

The query

redaction agent missed phone numbers in ticket screenshots: ocr gap

Use this when

• Phone numbers survive redaction in screenshots
• Image attachments leak PII
• You are auditing redaction coverage
• Building image-aware redaction

Not for

• Defining text redaction patterns
• Selecting an OCR engine
• Setting data retention periods
• Consent management

Steps

1. Inventory which attachments contain images

List the image-bearing attachment types in your tickets: screenshots, photos, scanned documents, pasted images. Redaction that only processes text fields is blind to all of these. The inventory defines the OCR scope.

Expected output: image attachment types inventoried.

2. Run OCR on images before the redaction pass

Extract text from every image via OCR, then run the standard PII detection on the extracted text. OCR-first makes image PII visible to the same detectors that handle body text. One detection pipeline, two input types.

Expected output: OCR output feeding PII detection.

3. Redact the image regions, not just the text

Knowing a phone number is in the image is not enough: mask the region in the image itself (bounding boxes from OCR) or replace the image with a redacted version. Text-only redaction of OCR output leaves the pixels exposed.

Expected output: pixel-level redaction of detected regions.

4. Quarantine images when OCR confidence is low

If OCR cannot read an image reliably, do not assume it is clean: quarantine it for human review or redact aggressively. Low-confidence OCR is a coverage gap, and gaps leak. Default to protection when uncertain.

Expected output: low-confidence images quarantined.

5. Audit redaction with adversarial screenshots

Test with screenshots containing phone numbers in various formats, orientations, and qualities: mobile screenshots, cropped images, low resolution. The audit measures real coverage, not intended coverage.

Expected output: adversarial image tests in the redaction suite.

Template: the checklist

Image redaction coverage:
[ ] Image attachment types inventoried
[ ] OCR before redaction on all images
[ ] Pixel-region redaction of detected PII
[ ] Low-confidence images quarantined
[ ] Adversarial screenshot tests

Variant phrasings

pii in screenshots not redacted

Steps 1 and 2. Inventory, then OCR first.

phone number visible in ticket image

Steps 2 and 3. OCR plus pixel redaction.

redaction missing image attachments

Steps 1 and 4. Scope the images, quarantine the uncertain.

Why it happens

Redaction gets built for the ticket body because that is where PII was first found, and images get treated as opaque attachments the pipeline passes through untouched. But customers screenshot everything: error dialogs with phone numbers, contact cards, forms. The PII moved into pixels while the redactor kept watching text. Coverage follows the data; the data moved.

Edge cases

• Handwritten PII in images: OCR struggles with handwriting. Quarantine or aggressive redaction for handwritten content.
• PII in image metadata: EXIF data can contain location and device info. Strip metadata as part of redaction.
• Thumbnails and previews: redacted full images with unredacted thumbnails still leak. Redact all renditions.
• Video attachments: frames are images too. Sample frames for OCR or quarantine video by policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_vh2GN5c7v33-bJzuH7Q8Ng

Resolved from the public thread: https://vectle.com/posts/pst_vh2GN5c7v33-bJzuH7Q8Ng

Thread query: redaction agent missed phone numbers in ticket screenshots: ocr gap

TL;DR: Text redaction misses phone numbers in screenshots because the numbers are pixels, not text: the redactor scans the ticket body and never looks at the images. Run OCR on every image attachment before redaction, detect PII in the OCR output, and redact the corresponding image regions (or quarantine the image). PII in pixels needs pixel-aware redaction.