OCR read "30 days" as "30 clays" in the notice period - the agent's clause classifier scored it as non-notice...

TL;DR The OCR engine read "30 days" as "30 clays" because a printed "d" looks like "cl" at scan resolution, and the classifier scored the mangled phrase as non-notice language. Normalize the d/cl confusion pair in a post-OCR pass, and validate notice periods with a simple number-plus-time-unit check instead of relying on the classifier alone. The notice period gets found even when the letters are wrong.

The misread text in your OCR output:

30 clays

Steps

1. Confirm the notice language is present but mangled. Search your OCR text for near-misses of time units.

Command: grep -rniE "[0-9]+ (clays|days|cays)" ocr_text/ | head Expected: hits showing "30 clays" next to notice or termination language, proving the period is there and the classifier is the failure point.

1. Add a d/cl confusion normalization after OCR. Map the common misread back to "d" in alphabetic contexts before classification.

   def normalize_d_cl(text):
       return text.replace("cl", "d").replace("Cl", "D")

Apply it to a copy used for classification, keep the original for citations. Expected: "30 clays" becomes "30 days" in the classification stream.

1. Add a notice-period validation check independent of the classifier: look for a number followed by a time unit (days, months, years) within a few words of notice, termination, cure, or renewal language.

Expected: the 30-day notice period is extracted with the correct number and unit even if the classifier still scores the clause low.

1. Re-run extraction and spot-check other notice periods in the document for the same confusion.

Expected: all notice periods extracted, and a grep for remaining "clays" style misreads comes back empty.

Use this when

• Scanned contracts where "d" renders as "cl" in the body font
• Notice, cure, or termination periods are skipped while nearby clauses extract fine
• OCR output has words like "clays", "cleadline", or "inclividual" that should contain a "d"
• Your classifier scores mangled but recognizable notice language below threshold

Not for this skill when

• The period is genuinely absent from the contract, check the source page first
• The document is born-digital, the text layer will not have this confusion
• The number itself is misread, like "30" becoming "80", which needs confidence-based validation instead
• The classifier misses clean notice language, that is a training problem, not a glyph problem

Variant phrasings

• OCR read 30 days as 30 clays, classifier skipped the notice period
• d versus cl confusion in scanned contract OCR
• notice period missed because OCR mangled the word days
• how to normalize OCR confusables before clause classification
• agent skipped the termination notice period on a scanned contract

Why it happens

At typical scan resolutions a lowercase "d" is two vertical strokes with a curve, which is exactly what "cl" looks like when the pixels blur together. The OCR engine guesses "cl", the classifier sees a word it does not recognize, and the whole phrase scores as non-notice language. The classifier was trained on clean text and has no idea OCR text is approximate, so one wrong letter pair is enough to drop a critical period.

Edge cases

• The global "cl" to "d" replace can corrupt real words containing "cl", like "clause" becoming "dause", so run the replace only inside candidate time-unit phrases, or use fuzzy matching on the unit word instead of a blind replace.
• Some engines misread "d" as "ol" or "a" instead of "cl", keep your confusion map per-engine based on what you actually observe.
• The number-plus-unit check should accept written-out numbers too, "thirty days" is common in legal text.
• If the unit is misread beyond recognition, like "clays" becoming "c1ays", fall back to proximity: a bare number near notice language is worth flagging for review.
• Always cite the original OCR text in your output, not the normalized version, so a reviewer sees what the page actually said.

Provenance

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