Matching
The everyday answer is boring, and that is the point
A photograph is attached to a student by a permission-checked lookup against the roster the school already keeps — a name and an id. No face scanning is involved in the ordinary path, because the school already knows who was in the session.
A roster lookup, not a recognition problem
A session is booked against a roster before the day begins. When the frames come back, the question is not “who is this?” — it is “which student on this session’s list does this frame belong to?”, and that is a much smaller question with a much smaller blast radius when it is wrong.
The lookup is permission-checked, which means the match is subject to the same wall as every other read: it happens inside one school’s tenancy, and the wall is in the database rather than in the application. A read that came from another school returns zero student rows because the database itself refuses it, and that is re-checked on every build.
None of this is impressive, and it is not meant to be. The impressive version of student photo matching is the one that needs a biometric template for every child in the building, and it is impressive in exactly the way a school should be suspicious of.
Face matching is off, and it is not wired
Off by default, and the capability behind it is not wired and cannot be switched on from this product. Not opt-out, not on-for-the-district, not a setting an administrator can flip on a family’s behalf — and, in the shipping configuration, not a setting anyone can flip at all. No face template is computed from a child’s photograph.
Where the optional lane is exercised at all, what is held stays inside the private cloud we run ourselves and is never sent to an outside recognition service. Withdrawing consent stops the matching — it is refused at the gate, not honoured on a delay.
A minor’s photograph is never made public, never indexed by a search engine, and never sold. Sharing outside the school happens only where a permission on file allows it, and even then it is a deliberate share rather than an open door.
The part we have not finished. The face-matching capability itself. There is no model to load and no way to switch it on from this product, and we would rather say that plainly than describe a feature we have not built. When it is real and can be shown end to end, this callout will say so, and not before.
Roster-first against face-first, as arrangements
This compares two ways of solving the same problem, not two companies. The left column is what a school ends up with when the matching problem is handed to whoever is holding the images.
| The question | Face-first sorting | Roster-first matching |
|---|---|---|
| What has to exist for it to work? | A biometric template per child | A class list the school already maintains |
| Who was missed? | Whoever the sorter did not recognise | A query: roster minus matched frames |
| What does a parent have to agree to? | Usually nothing, because it is on by default | Nothing at all, because it is not used |
| Where does a correction land? | In the album that was corrected | On the student record, so every surface reads it |
| What is retained afterwards? | Templates, on somebody's retention policy | The photograph and the roster link, and nothing biometric |
When a match is wrong
It happens. Two students with the same name in the same year group, a frame filed against the sitting before it, a session that ran on after a class swap. What matters is not the claim that it never happens; it is what a correction costs and how far it reaches.
A correction moves the image on the student record. Every surface that shows a student photograph — the directory, the identification card, the publications editor, the family delivery — reads that record rather than holding its own copy, so the correction reaches all of them in one action. There is no second list to fix and no printer to telephone, unless the run has already gone, which is the one case no software fixes.
This is the same mechanism the retake path uses, for the same reason.
The questions this page exists to answer
So what is actually doing the matching?
The school's own list. A session runs against a roster, the frames from that session are attached to the students that session was for, and the attachment is checked against a name and an id. It is closer to a register than to anything clever, and that is deliberate.
Why not just use face matching for everything, since it exists?
Because the school already knows who was in the room, so a face scan would be solving a problem that the roster has already solved -- while creating a new one, which is a stored biometric template for every child in the building. Choosing the boring mechanism is not a limitation here; it is the design.
What exactly is a face template?
A set of numbers. It is not a gallery of a child's face and it cannot be viewed as one. In the shipping configuration none is computed from a child's photo: the matching capability is not wired and cannot be switched on from this product. Where the optional lane is exercised at all, what is held stays inside the private cloud we run ourselves and is never sent to an outside recognition service.
What happens if a parent withdraws consent?
The matching stops. It is refused at the gate rather than honoured on a delay, so the withdrawal takes effect at the next use rather than at the next nightly job.
Can a mismatch be corrected?
Yes, and correcting it moves the image on the record rather than editing a copy. Because the directory, the identification card and the publications editor all read the record, the correction reaches all of them without anyone chasing it. A correction that has to be applied per destination is the version of this that leaves a child's face in a book.