Consent at the core
Consent isn’t a feature here. It’s the floor everything else stands on.
The yearbook industry treats consent as a checkbox at the edge — a terms-of-service click at upload, commercial-use language buried in the fine print, and an algorithm that surfaces any face it matched. Homeroom turns that upside down: one consent decision, which blocks by default and is decided in a single place, sits underneath commerce, publication, and AI. There is no “privacy mode” to switch off — the gate is the foundation, not a setting.
Why we call it the foundation, not a “feature”
A single shared module resolves consent, and every lane — commerce, publication, web publication, AI, face matching, directory — calls it before it acts. Three properties make that the foundation rather than a setting.
One source of truth
One module decides; every gate defers
A single pure resolver owns the policy. No lane carries its own copy of the rules that could drift — the storefront, the cart, and the publish path all read the same decision. Shipped
Blocked by default
Absence is never consent
The do-not-publish kill-switch denies every purpose; the sensitive lanes are deny-unless-explicitly-granted. A student with no record on file is blocked, not waved through. Shipped
Enforced at the floor
The wall lives below the app
The publish gate is a database trigger, so a worker, an import job, or a system lane that skips the application check still can’t stage consent-blocked content. Shipped
1 — A per-subject commerce kill-switch
A portrait is sellable only when, for that one subject, the consent foundation says so. The hard commerce gate canSellPhotoPrint requires the photo to be commerce-eligible and approved with a school attestation, and it reads consent for the commerce purpose as opt-in: a student with no commerce grant has nothing for sale — blocked by default. The same gate runs on every add-to-cart and again at checkout, so the storefront and the cart enforce one identical object.
- Per-subject, not per-school. One child’s guardian can pull that child out of photo sales without touching any other student.
- Do-not-publish is a master switch. Marking a student do-not-publish suppresses them everywhere — commerce, the book, candids — and overrides every other record.
- Per-student opt-out, honored as a denial. A legacy “don’t sell my child’s photo’” flag maps to an explicit commerce denial — it can never silently regress to sellable.
Consent foundation & commerce gate shipped Parent portrait store in early access
2 — Built around COPPA, state biometric-privacy laws, and FERPA
We build the frameworks schools are already required to honor right into the platform, rather than bolting a policy paragraph on top. This describes what the architecture is designed to do — it is not a regulator’s certification, and the binding terms live in the in-app policy your administrator agrees to.
COPPA — an under-13 block in the charge path
Commerce on a student under 13 is hard-blocked at the gate, with a COPPA attestation lane in the schema of record. The protection is code in the money path, not a footnote. Shipped
Biometric privacy — no biometric template for the core flow
“Find my child” is a student-list lookup, not a face match — so for the core flow no face signature is created at all. The optional face lane is off unless a parent turns it on; when it runs, it is permission-checked and is built to honor each state’s biometric-privacy law (such as Illinois’s BIPA), with the strictest setting as the default. The face template is kept only inside our own private system and destroyed when a parent withdraws consent or at the end of the school’s retention schedule (a year by default). Shipped
FERPA — a single-school wall in the database
An adviser, student staffer, or studio sales rep tied to one school cannot read another school’s student rows — a hard rule inside the database, proven against a real database. A studio or rep session sees zero student rows. Shipped
3 — A publish gate the database enforces
Consent is enforced at the database, not only in the app. A BEFORE INSERT OR UPDATE trigger on the placement’s publish-state column rejects a transition into published or scheduled when any tagged subject lacks the required consent or is do-not-publish. Its purpose basis mirrors the shared resolver exactly:
- Public web surfaces are opt-in. For a public online-edition slot, only an explicit granted web-publication consent admits a student — do-not-publish, a denial, a pending record, or no record at all all block. The anonymous internet is not the school community.
- The print/book basis is opt-out. For the directory-style print surface, do-not-publish or an explicit denial blocks; a missing record admits — the FERPA directory default schools already operate under.
- No silent zero-subject pass. A story with no tagged subjects can reach a public web surface only under an explicit “no identifiable students” attestation (a stored who/when) — the absence of tags is never silent consent-clearance.
The trigger is count-only — no student id ever appears in an error message — and it runs under the writer’s own built-in privacy rules. The point for a buyer: a worker, an import job, or a system lane that bypasses the application gate still cannot publish consent-blocked content. The wall is under the floor. Publish gate shipped
The marketing claim and the engine invariant are the same object
| Dimension | The industry default | Homeroom |
|---|---|---|
| Consent basis | A terms-of-service click; commercial use buried in fine print | Opt-in for commerce & public web; a do-not-publish kill-switch over everything; per-student opt-out |
| Who can be sold | Anyone in the gallery the algorithm matched | Only commerce-granted, not-suppressed, not-COPPA-blocked, commerce-eligible portraits |
| Find my child | A biometric face match against a cloud gallery | A student-list lookup — no biometric template created |
| Where the gate lives | App-layer “privacy mode” over a cloud-biometric pipeline | A pure resolver every lane calls + a database trigger below the app |
| Cross-school data | Vendor-wide pool | Single-school wall at the database; a studio/rep sees zero student rows |
There’s no separate “privacy mode” to forget to enable. A competitor would have to rebuild an entire cloud-face-matching pipeline to match it — which is exactly why this advantage holds.
We’re honest about what’s shipped
The consent foundation, the per-subject commerce gate, the do-not-publish off-switch, the COPPA under-13 block, the state face-and-fingerprint hard-off, the single-school FERPA wall, the sales-rep privacy wall, and the database publish-gate trigger are live today — several proven against a real database. The parent portrait store the commerce gate guards is in early access; the gate that protects it is already enforced in code. These statements describe what the platform does today; they are not a regulator’s certification, and the binding policy lives in the app.
Related: the privacy & consent explainer and the security & trust posture.