Skip to content
allanninal.dev/build
Collaborate

Part 2 of 7 · Age check logger series ~5 min read

What the till already knows

Every till in the group has prompted on age-restricted items for years. What it records when it does is the part nobody has looked at, and that detail decides whether the nightly export is evidence or noise.

Key takeaways

  • The prompt is not the control. The answer chosen at the prompt is.
  • ID seen, refused and clearly over the policy age are three answers, stored as three.
  • The category comes from the product file; the rule is looked up by the date of sale.
  • Ages move, and tobacco stops being an age at all on 1 January 2027.
  • The list of accepted ID is dated data too, and it is changing now.

One scan, one record

An age-restricted scan turned into a prompt and a recorded answerA vertical chain inside an AWS account container, entered from a box on the left labelled A scan, an item going through the till. Which category, taken from the product file rather than the product name, with a side exit reading none: No prompt, not restricted, the sale continues. The rule on the day: minimum age, policy age and accepted ID. Prompt on screen: the till waits for one of three answers. Refused, where the item is voided from the sale, with a side exit reading yes: Refusal, and a line in the book is expected. The final step is ID seen or waved through, recorded as two different answers. A note says the last step is where most tills lose the information, by offering one approve button for two answers that mean completely different things.AWS ACCOUNTA scanan item goesthrough the tillWhich category?from the productfile, not the nameNo promptnot restricted,sale continuesnoneThe rule on the dayminimum age, policyage, accepted IDPrompt on screenthe till waits forone of three answersRefused?the item is voidedfrom the saleRefusaland a line in thebook is expectedyesID seen, or waved throughrecorded as twodifferent answersThe last step is where most tills lose the information, by offering one approve button for two answers that mean completely different things.
Fig 1. Five steps and two ways out. The category and the rule are looked up before the prompt appears, so the record says which rule the answer was given under.
  • Machine learning
  • Security & identity
  • Management
  • People

The button that ruins the data

Two of the four stores had tills configured with two answers on the prompt: Approve and Refuse. Approve covered a card being read carefully and a customer who was plainly sixty, and the export carried one number for both. That number says nothing at all about whether anybody is asking for ID. The first change in this project was a till setting, a third answer, and the four weeks used throughout the series are the first four weeks after it.

With three answers, the override becomes the most informative field in the file. A person who waves through ninety-seven prompts in every hundred on Friday and Saturday late shifts is telling you something different from somebody who does the same on a Tuesday morning, and neither can tell you anything until the answers are separate.

Where the till records it, the time the prompt was answered is kept alongside the time it appeared. Two seconds between the prompt and clearly over 25 is a glance; twenty seconds and ID seen is somebody reading a card. Neither proves anything on its own and the system does not treat it as proof, but it costs nothing to keep.

Every rule has a date

Age-restricted categories on one till, each with its own dated ruleA horizontal row of five boxes joined by arrows. Alcohol: eighteen in law, and the policy says twenty-five. Tobacco: eighteen today, and a birth date rule from 2027. Lottery: eighteen since 2021, sixteen before that. Knives: eighteen, with a due diligence defence. Aerosol paint: sixteen, on the same till. A note says each of these is a row with an effective date, and the rule applied to a sale is the row that was in force on the day the sale happened.FIVE CATEGORIES, ONE TILL, NO CONSTANTSAlcohol18 in law; thepolicy says 25Tobacco18 today; a birthdate from 2027Lottery18 since 2021,16 before thatKnives18, and a duediligence defenceAerosol paint16, on thesame tillEach of these is a row with an effective date. The rule applied to a sale is the row that was in force on the day the sale happened.
Fig 2. Five categories on the same till, and not one of them is safe to write into the code. Two have changed in the last five years and one changes again in January.

Why the date matters more than the number

The National Lottery moved from sixteen to eighteen in 2021, and in shops it moved twice: the operator applied eighteen from April, and the law followed in October. For more than five months the policy age and the legal age were different numbers, which is precisely the distinction a record needs to be able to hold.

From 1 January 2027 the tobacco rule stops being an age at all. Nobody born on or after 1 January 2009 can be sold tobacco, however old they are, so two nineteen-year-olds can sit on opposite sides of the line. A system that stores tobacco: 18 as a constant is right today, wrong in under sixteen weeks, and will not say so.

So rules live in a table keyed by category and effective date, and every prompt record stores the version it was answered under. The policy age sits beside the legal one: the licence condition treats eighteen as the floor and lets the policy name an older age, and most shops name twenty-five.

Accepted ID is a rule as well

The mandatory condition on a premises licence that sells alcohol requires an age verification policy, and the policy has to ask anyone who appears to be under the policy age for identification bearing a photograph, a date of birth, and either a holographic mark or an ultraviolet feature. The ultraviolet feature was itself added by amendment, in 2014.

It is being amended again. Parliament has approved an order letting licensed premises accept digital proof of age from a certified digital verification service, as an option rather than an obligation. A shop that takes the option needs the ID-seen answer to record which kind of ID was seen, because a later question about a sale will ask.

What a prompt record holds

  • Store, till and time. When the prompt appeared, and when it was answered where the till records both.
  • Category. From the product file as it stood at the time of sale.
  • Rule version. The age or birth-date rule and the policy age in force that day.
  • Answer. id_seen | refused | over_policy_age. Never a single approve.
  • ID kind. Physical or digital, where the answer is id_seen.
  • Login. Who was logged in, which is not always who was serving.

The login problem

Everything in part four depends on knowing who answered the prompt, and the till only knows who is logged in. With one till and a queue, the person serving is not always the person whose login is on the screen, and a rate calculated on a shared login is a rate for a shift rather than for a person.

The system cannot fix that and does not pretend to. It notices it: a login answering prompts at two stores in the same hour, or through a twelve-hour day without a gap, is flagged as shared rather than counted as a very hard-working colleague. Getting people to log in as themselves is a management job, and it is the job that makes the rest of the series possible.

The next post is the other half of the record: the refusals book, which is paper because the licence says so, and what it takes to turn a photographed page into lines that can be joined to the till.

All posts