Skip to content
allanninal.dev/build
Collaborate

Part 1 of 7 · Lost property matcher series ~6 min read

A lost property matcher on AWS for a few dollars a month

There is a cupboard behind reception with four umbrellas, a child’s coat, two phone chargers, a set of car keys and a laptop. Nobody knows when the laptop arrived. Somebody rang about a laptop in March and was told there was nothing. It was in the cupboard.

A laptop computer sitting on top of a wooden table
Photo by Cemrecan Yurtman on Unsplash

Key takeaways

  • If logging takes more than ninety seconds it does not happen.
  • Match on structure — where, when, category — not on adjectives.
  • Never show the item first. The description is your only ownership test.
  • Every item ends in a recorded outcome, including the ones nobody claims.
  • Designed on AWS for about $2 a month.

The whole system on one page

Before any code, here is the shape of what we are designing.

System: found items logged, claims matched, outcomes recordedThree boxes across the top sit outside the AWS account. On the left, Whoever finds it, mid-shift with their hands full. In the middle, Whoever lost it, ringing on Thursday about Saturday. On the right, The cupboard, and the day it has to be emptied. Each connects by an arrow to the AWS account container below. Logging takes ninety seconds on a phone. A vague description comes in. An ending on a date goes back out. Inside the AWS account are three components in a row. On the left, The item record: photo, place, time and category. In the middle, Claim and match, structure first and then a person. On the right, Outcome: returned, donated or disposed of. A note says the left-hand arrow is the whole system and everything downstream is worthless if that step is skipped.AWS ACCOUNTWhoever finds itmid-shift, hands fullWhoever lost itringing on Thursdayabout SaturdayThe cupboardand the day ithas to be emptiedThe item recordphoto, place, time,categoryClaim and matchstructure first,then a personOutcomereturned, donated,disposed of90 seconds, on aphonea vaguedescriptionan ending, on adateThe left-hand arrow is the whole system. Everything downstream is worthless if that step is skipped.
Fig 1. Three things outside the account, three pieces inside it. The finder is the only user who cannot be asked for more effort.
  • Machine learning
  • Analytics
  • Front-end & mobile
  • People

Why the cupboard fails

A cupboard has no index, no dates and no memory. Its only query is a person opening the door and looking, which works for umbrellas and fails completely for the thing somebody actually cares about, because that item arrived four weeks ago and is at the back.

It also has no ending. Nothing in a cupboard is ever disposed of on a date; it is disposed of when the cupboard is full, which means the valuable items that should be kept longest are thrown out alongside the umbrellas at exactly the wrong moment.

What runs (the inside)

  • The item record. One photograph and three fields, captured where the item was found. Part 2.
  • Claim and match. Structural matching against a description that will be wrong in at least one detail. Part 3.
  • Return and disposal. Proving ownership, getting it back, and ending the items nobody comes for. Parts 4 and 5.

One jacket, five weeks

One found jacket from discovery through to being returnedA horizontal row of five boxes joined by arrows. Found Saturday, bar area, twenty-three forty. Logged in eighty seconds with a photo and three taps. Claimed Thursday, described as a dark coat, maybe navy. Matched on place and night rather than the colour. Returned Friday after one question. A note says the colour was wrong in the claim and it did not matter, because almost nobody remembers a colour correctly.ONE JACKET, FIVE DAYSFound Saturdaybar area, 23:40Logged in 80sphoto and three tapsClaimed Thursday'a dark coat,maybe navy'Matchedplace and night,not the colourReturned Fridayafter one questionThe colour was wrong in the claim and it did not matter. Almost nobody remembers a colour correctly.
Fig 2. The same system as one line. The match is made on where and when, which the claimant remembers, rather than on what, which they do not.
  • Machine learning
  • Analytics
  • Front-end & mobile

In plain words

Somebody clearing tables finds a jacket. They photograph it on their phone, tap a category, tap where they are, and put it in the cupboard with a printed label. The whole interaction is under ninety seconds and it is the only part of this system that has a hard time budget.

Five days later somebody rings, or fills in a form, describing a dark coat they think they left in the bar on Saturday. They are wrong about the colour and roughly right about everything else, which is the normal case.

The match is made on the parts of the claim that are reliable — roughly when, roughly where, what kind of thing it is — and produces a short list for a human. Nobody is shown a photograph, because the description is the only ownership test that exists and showing the item destroys it.

One question settles it: something about the item that an owner knows and a chancer does not. Then it is collected or posted, and the record closes with who took it and when. Everything unclaimed reaches its retention date and gets an outcome, which is a line in a record rather than a bin bag.

Design rules that shaped every decision

  • Ninety seconds to log, on a phone, one-handed, or it will not happen.
  • Structure over adjectives: where and when beat colour and brand every time.
  • Never show the item to the claimant before they have described it.
  • One ownership question, asked openly, decided by a person.
  • Retention is by category, on a date, and it ends in a recorded outcome.
  • Do not look inside anything. A found device is somebody else’s data.

What it does not do

It does not decide who owns anything. Every actual return is authorised by a person, because the cost of being wrong is handing a stranger somebody’s passport and there is no confidence score that justifies automating that.

It does not identify items from photographs, either. A photograph is for the person confirming a match at the counter, not for a classifier, and building this around image recognition adds cost and failure modes to a problem that is mostly about dates and places.

The next four posts walk through each piece: how a found item gets logged, how a claim gets matched to it, how it gets back to its owner, and what happens to everything nobody comes for. One diagram per post, a cost breakdown, and an engineering reference at the end.

All posts