Privacy & consent
Picture day stays inside the school’s walls.
The yearbook industry quietly turned picture day into a face-recognition data business: a child’s portrait is uploaded to a vendor’s AI cloud, matched by biometric template, and monetized far from the school. Homeroom is built the opposite way. No face leaves the school’s walls, no biometric template is ever created, and a portrait is sellable only when consent says so. This page explains exactly how — in plain language.
Four things this architecture guarantees
No biometric template, ever
We never compute a face-recognition signature for a student. There is no faceprint to leak, subpoena, or sell — because it doesn’t exist. Shipped
“Find my child” is a roster lookup
A parent finds their child by the school’s roster — name, grade, homeroom — not by a face match. It’s a database query a school already trusts, not a surveillance feature. Shipped
No student-image egress
The portrait stays inside the school’s VPC. It is not shipped to a third-party AI service, an ad network, or an enrichment vendor — the image and the child stay where they belong. Shipped
Consent gates the sale
A photo becomes purchasable only when consent on file says it may be — enforced in code (the consent gate), not by a checkbox someone might forget. No consent, no sale. Gate shipped Parent storefront in early access
How the no-egress pipeline actually works
- Capture stays in-VPC. Picture-day photos land in the school’s isolated cloud tenancy. They are never copied to a shared model-training pool or a vendor’s general storage.
- Identity is by roster, not by face. A photo is associated to a student through the roster the school provided — the same authoritative source the gradebook uses — so there is never a need to run face recognition.
- Consent is checked before anything is sellable. The consent gate (
canSellPhotoPrint) reads the consent record before a portrait can appear in a storefront. A photo without sale consent is simply not offered. - The school stays the controller. The school — not a photo vendor — remains the authority over its students’ images. The platform is the data controller of record for the consent flow, and the in-app policy spells out the exact terms.
A single-school wall the database enforces
Privacy isn’t only about picture day. Homeroom enforces a single-school FERPA wall as a restrictive database rule: an adviser, a student staffer, or a studio rep tied to one school cannot read another school’s student rows. It is enforced at the data layer, not the UI, and it is proven against real Postgres across the full student-data census — a cross-school view returns zero student rows even with both schools in scope.
A studio or sales rep sees aggregates, adult contacts, and reconciliation — and never a student row — under the same kind of rule (the rep PII wall). That’s what makes a genuinely resold product possible without anyone outside the school ever touching a child’s record.
The frameworks this design answers to
Homeroom is built to fit how schools are already required to handle student data — FERPA for education records and COPPA for children’s data — rather than bolting compliance on afterward. We describe here what the architecture does; the binding terms, the data-controller relationship, and the exact retention and deletion commitments live in the in-app policy your administrator agrees to. We’d rather show you the mechanism than wave a badge.
We’re honest about what’s shipped
The no-egress capture pipeline, the consent gate, roster-lookup “find my child,” the single-school FERPA wall, and the rep PII wall are live today. The parent-facing portrait storefront the consent gate guards is in early access — building now on the pipeline and gate you can already run. The privacy guarantees above describe what the platform does today; they are not a regulator’s certification, and the binding policy lives in-app.