Extracting Structured Data From a Warranty Registration Card

Most fields on a warranty registration card are contact details, and getting one slightly wrong costs a returned letter. One field is different: the purchase date is an input to an arithmetic that decides whether a claim two years from now is covered.

One field decides the answer to every later question

Coverage is computed, not recorded:

coverage_end = purchase_date + warranty_term(model, region)

The term is a property of the product and sometimes of where it was sold, and it is not usually on the card. The purchase date is on the card, in handwriting, in a small box, filled in by a customer who was not thinking about downstream systems. So the accuracy of every later coverage decision rests on one handwritten field, and a one-month error is invisible at extraction time and decisive at claim time.

That asymmetry should drive the schema. Contact fields can be captured with ordinary confidence handling. The purchase date warrants candidate values, an explicit ambiguity flag, and a record of which evidence resolved it — a much heavier structure than the field’s size suggests, justified entirely by what depends on it.

The date order problem, stated precisely

A handwritten date of 03/04/26 has two readings that are both valid calendar dates: the fourth of March and the third of April. Neither is malformed, so nothing downstream will ever complain. The gap is thirty days, which is enough to move a claim across a coverage boundary and enough to move a registration inside or outside a registration window.

The general rule for this class of ambiguity is to represent it rather than resolve it silently, and it belongs in a date field validation rule rather than in the prompt. Two candidate dates, a flag, and a resolution field — and a downstream policy, decided once and written down, for what to do when it stays unresolved. Whether the policy favours the earlier or the later date is a business decision with money attached, and the extraction’s job is to make sure somebody made it consciously rather than having it decided by whichever locale a parsing library defaulted to.

Two related traps sit alongside it. A two-digit year needs a windowing rule, and the sensible window depends on the product: a card for an appliance registered decades ago is not hypothetical when a manufacturer digitises an archive. And a date written in a box printed with a format hint should be read as that format even when it disagrees with what looks natural — the hint is evidence about what the customer was told to write, which is not quite the same as evidence about what they wrote, but it is the strongest single signal available.

Three constraints that usually resolve it

The useful observation is that the ambiguity is rarely unresolvable in practice, because a registration card arrives with context, and three independent constraints eliminate one candidate more often than not.

• The card cannot have been posted before the purchase. A postmark, a received-date stamp, or the scan date of a digitised archive gives an upper bound. A candidate date after that bound is impossible, not merely unlikely.
• The product cannot have been bought before it existed. A model number gives a lower bound from the product catalogue, and where the serial encodes a manufacturing date code the bound is tighter still: purchase cannot precede manufacture.
• Registration windows are short. Where a programme requires registration within thirty, sixty or ninety days of purchase, a candidate implying a submission far outside that window is the less likely reading — weaker evidence than the other two, since late registrations happen, but useful as a tiebreak.

A fourth signal is cheaper and often decisive: other dates on the same card. If any of them has a first component above twelve, the writer’s convention is fixed for the whole card, and every other date on it inherits the resolution. Consistency within a document is a stronger assumption than a global default, and applying it document-wide rather than field-by-field is the difference between resolving most cards and resolving few.

Record which constraint did the work, in the field audit trail rather than in a comment. When a coverage decision is disputed later, “resolved by postmark” is defensible and “confidence 0.83” is not.

The model number constrains the serial

Handwritten serial numbers are where character-level errors concentrate, because a serial has no linguistic context to fall back on: nothing about the surrounding characters makes zero more likely than the letter O, one more likely than seven or a European crossed seven, five more likely than S, eight more likely than B, or two more likely than Z. Every heuristic that helps with handwritten words is unavailable, which is the specific reason this field fails more than the address does.

What is available is the format. Manufacturers assign serials with structure — a fixed length, a prefix tied to a product family or a plant, sometimes an embedded date code, occasionally a check character. The card carries the model number a few boxes away, so the format expected for that model is knowable, and the check becomes cross-field: a serial read as ten characters where the model’s scheme is eleven is wrong, and knowing which position is under-populated frequently identifies the misread character.

Where the character set for a position is constrained to digits, an alphabetic read is a substitution with a small candidate list, and the confusion pairs above generate the alternatives directly. Where a check character exists, this becomes a genuinely decidable problem rather than a probabilistic one, and it is worth finding out from the manufacturer whether one does. The general handwriting mechanics are in handwriting recognition with LLMs, and the serial-on-a-printed-document case is covered in product certificate serial extraction, which has the easier version of the same field.

Card mechanics and what to do with the consent box

• The card is a postcard. One side is data, the other is a mailing address and possibly a stamp. A batch scanner captures both, and half your images contain no data at all. Detect and discard by layout rather than by asking a model to read a blank.
• Combs help, and only if you use them. Boxes with one character per cell constrain segmentation enormously. Where the form provides them, segment on the printed cells rather than on the ink, and a character that straddles two cells becomes a detectable event instead of an invisible merge.
• Retailer is free text and needs a match list. Handwritten store names are abbreviated, misspelled and sometimes a branch rather than a chain. Fuzzy-match to a known retailer list and keep the raw string, because the raw string is what proves the match was reasonable.
• Price paid is optional and frequently blank. Blank is not zero, and missing required field handling is the difference: a currency field defaulting to zero produces a fleet of products apparently given away.
• The marketing consent checkbox is not an ordinary field. It records a choice a person made about their own data, and an ambiguous mark must resolve to no consent rather than to a guess. The asymmetry is deliberate: a false negative costs a mailing, a false positive is contacting someone who declined. The same care applies to retention — a card is a small pile of personal data with a long life, and there is rarely a reason to keep the scanned image once the fields are extracted and verified. See PII detection for finding the fields that need this treatment.