Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Certification expiry tracker series ~5 min read

How a certificate gets read

A certification card is a small laminated rectangle with a logo, a name, a number and one or two dates on it, photographed at an angle with a flash reflecting off the lamination. It is a much easier document than a till receipt and it has one nasty trap in it, which is that the most important field is a date and dates are ambiguous.

Key takeaways

  • The certification type is matched against your list, never read freely off the card.
  • A card with two dates needs both: issued and expires, and telling them apart matters.
  • An ambiguous date is a question with the crop attached, never a best guess.
  • The holder’s name is matched to the staff list, so a mistyped name cannot create a person.
  • Both sides of the card are captured, because the expiry is often on the back.

What comes off a card

type          first-aid-at-work     matched to your list, not read freely
holder        matched to staff list, or a question
number        as printed, kept verbatim
issued        2023-09-12
expires       2026-09-12            the field everything depends on
awarding_body as printed, for the record
confidence    per field, 0.0-1.0

The read

How a photographed certification card becomes a register rowA vertical chain of five steps inside the AWS account, entered by a box labelled Card photographed, front then back. Step one asks whether both sides were captured, since the expiry is often on the back; a single side exits to Ask for the back, one more tap. Step two pulls the text with Amazon Textract. Step three asks which certification it is, matching against the certification list with its aliases; no match exits to Ask which type with a short pick list. Step four asks whether the date is unambiguous, both in format and in which date is which; unclear exits to Ask about the date with the crop shown. Step five writes the register row with the photographs attached. A note says two questions are possible, both are one tap, and neither is a guess.AWS ACCOUNTCard photographedfront, then backBoth sides captured?expiry is often on the backAsk for the backone more tapone sidePull the textTextractWhich certification?match to your listCertification listtypes and aliasesAsk which typeshort pick listno matchDate unambiguous?format, and which is whichAsk about the dateshow the cropunclearWrite the register rowwith the photographsTwo questions are possible and both are one tap. Neither is a guess.
Fig 1. One card, end to end. The two exits are the only places a person is involved, and both take one tap because the person is holding the card.
  • Database
  • App integration
  • Machine learning
  • Front-end & mobile
  • People

Matching the type rather than reading it

The same qualification is printed a dozen ways by different awarding bodies, and the card frequently names a scheme rather than a skill. Asking a model to read a certification type off a card produces a free-text string, and free-text strings do not group, which means your register ends up with nine spellings of the same ticket and no way to answer “who has first aid”.

So the certification list carries aliases, and the model’s job is to pick one of your types or none. A card that matches nothing is a question with a short pick list, and the answer adds an alias — so the second person with that card is read automatically.

The date problem

  • Format ambiguity. 09/12/2026 is September or December depending on which side of the Atlantic printed it. Where the day is above twelve there is no ambiguity; where it is not, the answer comes from the awarding body’s convention if the list knows it, and from a question if it does not.
  • Which date is which. Most cards carry two. Usually the later one is the expiry, and usually is not good enough — some cards show a training date and a much later review date that is not an expiry at all. Labels are read where they exist.
  • Cards with no expiry. Some qualifications do not expire, and their register rows carry no date and are never chased. Recording that explicitly is much better than an empty field that looks like a failed read.
  • Month-only expiry. Plenty of cards show 09/2026 and expire at the end of that month. Treating that as the first of the month costs somebody a month of validity, so it resolves to the last day.

Names

The holder’s name is matched against your staff list rather than taken from the card, for the same reason the type is: a free-text name creates duplicate people. “J Reed”, “John Reed” and “Jonathan Reed” are one person, and a register that thinks they are three cannot answer any question correctly.

A card whose name matches nobody on the staff list is not registered against a guess. It becomes a question to whoever uploaded it, which is usually resolved instantly — it is normally either a new starter not yet on the list, or a card belonging to somebody else that was photographed by mistake, and both of those are worth catching.

What the reader will not do

  • It will not create a certification type. An unmatched card is a question, and the answer adds an alias to a type you already recognise.
  • It will not create a person. A name that matches nobody is a question, because the alternative is a register full of ghosts.
  • It will not guess an ambiguous date. A wrong expiry is worse than no expiry: it produces confidence rather than a gap.
  • It will not read a card as valid. It reads a card as saying something; whether the qualification is live with the awarding body is a separate question the system does not answer.

Next: how the register handles renewals, history and the question that gets asked after an incident.

All posts