Consent as substrate
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 inverts the stack: one consent decision, resolved fail-closed in a single place, sits underneath commerce, publication, and AI. There is no “privacy mode” to switch off — the gate is the substrate, not a setting.
Why we say “substrate,” not “feature”
A single pure module resolves consent, and every lane — commerce, publication, web publication, AI, biometric, directory — calls it before it acts. Three properties make that a substrate 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
Fail-closed
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 substrate 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 — fail-closed. 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 substrate & commerce gate shipped Parent-portrait storefront in early access
2 — COPPA, BIPA, and FERPA answered by architecture
We answer to the frameworks schools are already required to honor by building them in, not bolting a policy paragraph on top. We describe what the architecture does today — 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
BIPA — no biometric template for the core flow
“Find my child” is a roster lookup, not a face match — no faceprint to leak, subpoena, or sell, because it isn’t created. Any optional face lane is in-VPC, consent-gated, and hard-off in NY, IL, TX, and WA. Shipped
FERPA — a single-school wall in the database
An adviser, student staffer, or studio rep tied to one school cannot read another school’s student rows — a restrictive database rule, proven against real Postgres. A studio/rep session sees zero student rows (the rep PII wall). Shipped
3 — A publish gate the database enforces
The substrate 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 row-level security. 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 roster 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 re-architect an entire cloud-biometric pipeline to match it — which is exactly why the moat holds.
We’re honest about what’s shipped
The consent substrate, the per-subject commerce gate, the do-not-publish kill-switch, the COPPA under-13 block, the BIPA-state biometric hard-off, the single-school FERPA wall, the rep PII wall, and the database publish-gate trigger are live today — several proven against real Postgres. The parent-facing portrait storefront the commerce gate guards is in early access, building now on the gate you can already run. These statements describe what the platform does today; they are not a regulator’s certification, and the binding policy lives in-app.
Related: the privacy & consent explainer and the security & trust posture.