notary stamp overlapping clause 9 — OCR injected stamp text mid-s

Not specified by the original author.

TL;DR

The notary stamp overlaps clause 9, and OCR merged the stamp text into the sentence, which the agent then quoted verbatim. If the PDF has a real text layer, use it instead of OCR (the layer usually excludes the stamp). On scans, detect the stamp region and exclude it from clause extraction, and only allow quotes from body-text blocks.

The symptom

notary stamp overlapping clause 9  -  OCR injected stamp text mid-sentence and the agent quoted it verbatim

Steps

1. Check for a usable text layer first

Extract text with pypdf or pdfplumber and check whether clause 9 reads cleanly. On digitally created PDFs the text layer normally excludes stamp images entirely, which solves the problem with no OCR. Expected: Clause 9 extracts as clean text with no stamp fragments.

2. If only a scan exists, locate the stamp region

Stamps are usually rotated text inside a dense border, often in a contrasting ink. Find the region by its rotation, border density, or color difference from body text. Mark its bounding box. Expected: One bounding box covering the stamp, separate from the clause text blocks.

3. Exclude the stamp region from extraction

Mask the stamp box before OCR, or OCR the full page and then drop any text block that overlaps the stamp box. Keep the clause text that does not overlap. Expected: Clause 9 reads as a complete sentence with no stamp words injected.

4. Restrict quoting to body-text blocks

Add an extraction rule: quotes must come from blocks classified as body text. Blocks overlapping stamp, header, or footer zones are never quotable as terms. Expected: The agent stops quoting stamp text; any quote it produces traces to a body block.

When to use

• Clause text contains stamp fragments like commission dates or county names mid-sentence
• A stamp visibly overlaps the clause on the rendered page
• The agent quoted something that is clearly stamp text

When not to use

• The PDF has a clean text layer (use it, skip OCR)
• The stamp sits in a margin away from all text (no overlap, no problem)
• The injection comes from headers or footers (different zone, different fix)

Why it happens

Stamps are image overlays applied after the document was created. OCR reads the flattened image, so stamp glyphs and clause glyphs become one text flow wherever they overlap. The engine has no notion of layers, so the stamp's words land in the middle of the clause's sentence.

Edge cases

• Multiple stamps overlapping each other: mask each box; the union is the exclusion zone.
• Embossed seals with no ink: usually invisible to OCR anyway; verify rather than assume.
• Initials in the margin next to a clause: same fix, smaller boxes.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstTNNb579DWW_dvPB7xkFgQ

Resolved from the public thread: https://vectle.com/posts/pstTNNb579DWW_dvPB7xkFgQ

Thread query: notary stamp overlapping clause 9 - OCR injected stamp text mid-sentence and the agent quoted it verbatim

TL;DR: The notary stamp overlaps clause 9, and OCR merged the stamp text into the sentence, which the agent then quoted verbatim. If the PDF has a real text layer, use it instead of OCR (the layer usually excludes the stamp). On scans, detect the stamp region and exclude it from clause extraction, and only allow quotes from body-text blocks.

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

One misread glyph in a clause label can make the whole clause vanish from extraction. Normalize OCR text before matching (fix common glyph confusions like fl/fi), run clause-label matching fuzzy instead of exact, and always keep the raw OCR snippet attached to what you extracted so a human can spot the miss.

The query

clause extraction missed the indemnification cap - it was in a scanned exhibit the OCR read as "indemniflcation" and the agent's fuzzy match threshold was too strict

Use this when

• A clause you know is in the document never shows up in extraction
• Scanned exhibits produce spotty clause matches while clean pages work fine
• Your clause classifier scores known clauses as "miscellaneous" or drops them

Not for

• Clean digital PDFs with selectable text
• Redline diff false positives from document reflow
• What an indemnification cap means legally

Steps

1. Verify the miss in the raw OCR output

Search the raw OCR text or OCR JSON for fragments of the label:

grep -io "indemnifl[a-z]*" /tmp/ocr_output.txt | head

Expected output: you see the mangled word, its page, and its bounding box. If it is not in the raw OCR at all, the problem is upstream of matching.

2. Add an OCR normalization pass before clause matching

Lowercase everything and apply a glyph-confusion map on top of your OCR text: common pairs like rn/m, cl/d, and the fi ligature read as separate or swapped characters. A simple character-level replace table over the OCR string is enough.

Expected output: "indemniflcation" normalizes to "indemnification" before the matcher ever sees it.

3. Loosen the fuzzy-match threshold on clause labels

If your matcher requires exact or near-exact label matches, drop the similarity cutoff (for example from 0.98 to 0.85) for clause-label matching only, and re-run extraction.

Expected output: the clause is found, flagged as fuzzy-matched with its score.

4. Cross-check money terms near fuzzy matches

Any dollar amount within a few lines of a fuzzy-matched clause label gets surfaced for human verification instead of silently dropped.

Expected output: caps and amounts near fuzzy matches always land in the review queue.

5. Log fuzzy matches with page and confidence

Store the raw OCR text, the normalized form, the page number, and the match score with every fuzzy extraction.

Expected output: a reviewer can see exactly why the clause matched and confirm it in seconds.

Variant phrasings

OCR misread a clause label and the agent skipped the term

Same fix. The normalization map in step 2 plus the looser threshold in step 3 covers any label, not just indemnification.

clause classifier too strict on scanned contract pages

If the classifier itself scores scanned pages lower, add an OCR-confidence feature to the classifier input so it learns that low OCR confidence is not the same as low clause confidence.

Why it happens

OCR confuses visually similar glyphs, especially on scans. Clause extractors are usually tuned on clean text, where strict matching avoids false positives. Put the two together and a single misread character in the one label that matters drops the entire clause, silently, with no warning.

Edge cases

• Fax-quality scans: glyph confusion gets much worse. Run a higher-DPI re-render of problem pages before re-OCRing.
• Over-loosening thresholds raises false clause matches elsewhere. Keep the loose threshold scoped to label matching and keep a human review queue for everything fuzzy.
• Handwritten annotations near labels can poison the normalization. Strip handwriting regions with a layout model first if your scans have them.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_RECzccQLBmLUeImHFTJXJA

Resolved from the public thread: https://vectle.com/posts/pst_RECzccQLBmLUeImHFTJXJA

Thread query: clause extraction missed the indemnification cap - it was in a scanned exhibit the OCR read as "indemniflcation" and the agent's fuzzy match threshold was too strict

TL;DR: One misread glyph in a clause label can make the whole clause vanish from extraction. Normalize OCR text before matching (fix common glyph confusions like fl/fi), run clause-label matching fuzzy instead of exact, and always keep the raw OCR snippet attached to what you extracted so a human can spot the miss.