▌ Case study
Six thousand shirts
and one awkward
question.
A collector owns around 6,000 football shirts. Every one of them has been
photographed by a professional at 5424 × 7723 pixels — two hundred
gigabytes in total. And they all sit in folders with names like
_1000795.jpeg.
Behind each one, the same question:
was this one actually worn?
▌ The problem
A beautiful photo
is not an archive.
The digitisation was done and paid for. What did not exist was the archive: what each item is, which year, which match, and above all what can be proven and what cannot. Without that, two hundred gigabytes of professional photography are two hundred gigabytes of professional photography.
And there is one dividing line that shapes everything: today a player shirt is born authenticated — the club collects the garment unwashed, photographs it and tags it with a chip. Every item in this collection predates that practice. Which leaves two routes only: photomatching (finding the agency photograph showing that exact garment) and documenting provenance.
▌ The decision
The easy build was
an oracle.
One button, one answer: authentic / not authentic. It would have demoed beautifully and it would have been reckless. A model cannot sign off the authenticity of a collector’s garment, and if it did, the one answering for it isn’t the model — it’s whoever built the system.
So the system hands down no verdicts. It hands over evidence, and says precisely what is missing before a claim can be made. Four non-negotiable rules, written before the first line of code:
-
01
The system never says whether a shirt is authentic.
It returns status, a chain of evidence, and exactly what is missing before anyone can make that claim. Authenticity is signed off by a human expert. With items of this value, a wrong verdict from the system is the responsibility of whoever built the system.
-
02
Nothing is saved without confirmation.
Every change goes through a before-and-after screen with apply or discard. An invisible change is worse than a visible mistake.
-
03
Nothing is overwritten, everything is appended.
Analyses stack up as dated versions with diffs. Version one is never deleted, even when it was wrong. Especially when it was wrong.
-
04
Every field carries its source.
A fact read off the photograph, a fact the owner remembers, and a fact checked against an external source do not weigh the same. They are marked differently and they look different.
▌ The screens
Two statuses,
never one.
A record can be flawless while the item itself has nothing proven. It happens constantly. That is why the record status (draft, complete, reviewed) and the evidence level (no evidence, partial, expert-verified) are two separate things and look separate. Neither is chosen by the user: both are derived from what is actually there.
Tasks aren’t written by hand either. Every unverified link generates its own. Grouped by type, “412 items missing a label photo” stops being 412 notifications and becomes one afternoon with a camera.
▌ The catalogue
Search, filters by type, competition, decade and status, and the counter up top: 12 items out of the 6,000 in the inventory. The black bar is printed by the file itself — this is the demo build, with invented data.
▌ One record
The same item from the inside. Two greens, two ambers and one grey: that is everything the system allows itself to say. At the bottom, the conclusion — “compatible, pending more evidence” — and the sentence that governs the whole project.
▌ Real screenshots of the prototype · demo build, no photographs from the collection
▌ Try it
Your shirt,
the same chain.
Pick a photo of one of your own shirts and answer what can be seen in it. The system will not tell you whether it is authentic — it will tell you what can be claimed, what cannot, and what you are missing before you can claim it.
The photo is not uploaded anywhere. It opens inside this tab and stays there: no server, no request, nothing stored.
No photo — you can still answer
Record status
- Draft
- Complete
- Reviewed
“Reviewed” is marked by a person, not by this form.
Evidence level
- No evidence
- Partial
- Expert-verified
“Expert-verified” cannot be reached here. A human expert signs it.
▌ The chain, link by link
Conclusion
No evidence. The record can look flawless while the item has nothing proven: two different things, which is exactly why they are shown separately.
The system never says whether a shirt is authentic.
▌ What is missing
▌ The technique
Everyone else’s
squad numbers.
The breakthrough wasn’t looking harder at the shirt. It was looking away from it.
In an archive photograph, besides the player wearing that garment, you can usually see two or three other squad numbers in the same frame. That specific combination of numbers on the pitch doesn’t repeat: it identifies the line-up, and the line-up identifies the match. You go from “some match between 1999 and 2001” to five fixtures with a date and a stadium.
With one caveat that has to be said every single time: that identifies the match in the photograph, not the match the shirt was worn in. It narrows the archive; it doesn’t close the case. Conflating the two is exactly the mistake this system exists to avoid.
▌ What went wrong
Grouping the photos by colour.
There were twenty loose photographs to assign to their items. They were grouped by colour analysis, which seemed obvious. Two clusters were assigned to the wrong shirts: the yellow one belonged to one item and went to another, and the same for the white. Nobody noticed until a human looked at the photographs.
No automatic inference is worth anything until a person looks at the photo.
That failure is the origin of a product rule: every record is born “unreviewed.” Not out of politeness — because we already know what happens otherwise.
The second mistake was of a different kind, and worse: a
replace over the prototype’s HTML looked for
const $=s=> while the file said
const $ = s =>. No match, no error, and the task list
came out empty. A silent failure. Hence the habit of
verifying that the data landed where it should after every change,
instead of settling for the absence of an exception.
▌ What it costs
The numbers,
not rounded up.
This is what the software costs: building it and running it. It is not a valuation of the collection or of a business — I have nothing to back either of those up, and quoting a nice round number here would be precisely the sort of thing rule 01 exists to prevent.
- Equivalent build, outsourced to an agency
- €8,000 – 18,000
- Running cost, steady state
- €35 – 45 / month
- Analysing one shirt
- 5 – 12 cents
- One full pass over all 6,000 items
- €200 – 400
- Human review of all 6,000 records
- €3,000 – 6,000
- Pilot: 100 items, one month
- €55 – 70
▌ The photographic digitisation was already done and paid for. That removed an €18,000 – 30,000 line from the original plan.
▌ Where it stands
A prototype. And private.
There is a navigable prototype with the first items catalogued and the full chain of evidence. The architecture is settled — Cloudflare Pages, Workers, D1, R2 and email-gated access, all on accounts already paid for — and the pilot fits inside free tiers.
What there isn’t, and won’t be: sales, a public area, automatic valuation, or certificates issued by the system. It is a lookup tool for one person. The collection grows by about ten items a month: 2% a year. That, not fashion, is what drives the design.
Which is why you won’t find a single photograph of the real catalogue on this page. The collection isn’t mine, the photographs belong to the owner and to a professional photographer, and the rights assignment hasn’t been signed. Publishing an inventory of items of this value wouldn’t be very smart either. What you see above is the interface, with an invented item.