handwritten margin strike-through read as characters — OCR injected jun

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.

Not specified by the original author.

TL;DR

Dropping one digit from 81,000 to 8,100 poisoned every downstream comparison, because the agent trusted the OCR total as ground truth and judged each line against a total that was never real. Reprocess from the source document with validation switched on: the sum of the statement lines must agree with the read total, the opening balance plus movements must equal the closing balance, and any total failing those checks goes back for a second read at higher resolution or to a human. Add digit-length sanity rules - a total an order of magnitude away from the sum of its lines is a read error, not a discovery of fraud. Then clear the false exception report in bulk with a note, because hundreds of phantom breaks left in the queue will distort every ageing and quality metric built on it.

agent's OCR pass misread the statement total as 8,100 instead of 81,000 and flagged every line as a break

Use this when

• An agent's OCR of a bank or card statement produced a total inconsistent with the statement's own lines.
• The exception report flags nearly every line on one statement, an implausible pattern for a real break.
• Statements arrive as PDFs or scans rather than structured bank files.

Not for this skill when

• The statement lines themselves sum to the bank's printed total and transactions are genuinely missing. That is a feed completeness issue, not OCR.
• The document is a low-quality fax or photo where re-reading cannot help. Request a digital statement from the bank instead.

Steps

1. Open the source statement image and read the printed total yourself, then sum the extracted lines independently. Verify: the true total and the line sum agree, proving the OCR total was the error
2. Quarantine the statement's exception batch so the phantom breaks do not flow into reports or ageing while you fix the read. Verify: the false exceptions are isolated and labelled as an OCR incident
3. Re-run OCR on the statement with balance-equation validation enabled and higher resolution on the totals region. Verify: the re-read total satisfies opening plus movements equals closing
4. Add permanent pipeline checks: line-sum versus total tolerance, digit-count sanity, and a confidence threshold that routes weak reads to review. Verify: the checks are live in the pipeline configuration
5. Reprocess the statement through matching, close the phantom exceptions with an incident note, and confirm the real exceptions, if any, remain. Verify: the statement reconciles and only genuine exceptions stay open

Variant phrasings

agent OCR misread statement total 8100 instead of 81000 all lines flagged

The digit-drop symptom verbatim in spirit.

OCR bank statement total validation sum of lines balance equation check

The validation-design phrasing.

phantom reconciliation breaks OCR error quarantine exceptions fix

The queue-cleanup search.

Compatibility: Agent document pipelines using OCR engines such as Tesseract, Azure Document Intelligence, AWS Textract or Google Document AI over bank statement PDFs and scans.

Why it happens

OCR errors are not random noise; they cluster on exactly the characters that matter - a faint comma or a broken digit glyph turns 81,000 into 8,100. An agent that treats extracted control totals as authoritative then reasons perfectly from a false premise, generating a flood of internally consistent, entirely fictional breaks. The defence is arithmetical, not visual: statements obey balance equations, and any read that violates its own document's arithmetic should distrust itself before it accuses the ledger.

Edge cases / pitfalls

• European statements using dots as thousands separators are a classic digit and decimal trap; configure locale per bank.
• A second OCR engine voting on totals only is a cheap, high-value check for high-volume pipelines.
• Keep the misread image in the incident file; it is the training example that justifies the validation rules.

Provenance

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

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

Thread query: agent's OCR pass misread the statement total as 8,100 instead of 81,000 and flagged every line as a break

TL;DR: Dropping one digit from 81,000 to 8,100 poisoned every downstream comparison, because the agent trusted the OCR total as ground truth and judged each line against a total that was never real. Reprocess from the source document with validation switched on: the sum of the statement lines must agree with the read total, the opening balance plus movements must equal the closing balance, and any total failing those checks goes back for a second read at higher resolution or to a human. Add digit-length sanity rules - a total an order of magnitude away from the sum of its lines is a read error, not a