Security & trust
The protections that matter live below the application.
The honest question a district’s IT office asks is “what happens when your app code has a bug?” Our answer is that the load-bearing walls aren’t in the app. A query bug can’t return another school’s rows because the database decides what’s visible; a bypassed consent check can’t publish a blocked student because the gate is a database trigger; and raw card data never reaches our server at all. This page is the posture, sourced from the real architecture.
Five walls, each below the app
Keeping schools apart
Privacy rules built into the database
The database itself decides which rows each school can see — not the query a developer writes. Coverage is checked automatically on every build; the single-school wall is proven against real Postgres. Shipped
Consent gates
Blocks by default, with a database backstop
The sensitive lanes are opt-in; do-not-publish denies everything; and a database safeguard blocks a consent-unsafe publish even when the app is bypassed. Shipped
A permanent record
History you can only add to
The money and commission records are add-only and tied to refunds — corrections are new entries, never edits. A record of who approved what outlives the person who made it. Shipped
Payments
PCI SAQ-A — no card data here
The card is captured and tokenized client-side by Stripe’s hosted iframe; our server only ever sees opaque ids. A CI-enforced structural wall keeps it that way. Shipped
Student data
COPPA & FERPA walls
A single-school FERPA wall at the database, a rep PII wall that shows a studio zero student rows, and a COPPA under-13 block in the commerce path. Shipped
1 — Keeping each school’s data separate, inside the database
Keeping schools apart isn’t left to a line of code a developer might forget. The database itself carries a privacy rule on every table that holds school data, so it returns only the rows the current school is allowed to see — no matter how the query is written. That coverage is checked automatically on every build (a table that should be walled off and isn’t fails the build), and the single-school wall is tested against real Postgres across the full set of student-data tables: a read across schools returns zero student rows even with both schools in view. A bug in the app’s own database code therefore cannot leak another school’s data — the wall is one layer down.
2 — Consent gates that block by default
One shared module owns the consent policy, and every lane — commerce, publication, public-web publication, AI, face matching, directory — reads its decision before acting. The sensitive lanes stay blocked unless permission is explicitly granted; a do-not-publish off-switch denies every purpose for a student at once; and the publish path has a database safeguard (it runs before any save to the publish-state column) that refuses to stage a student who lacks the required consent — so a worker or import job that skips the app gate still cannot publish consent-blocked content. The full mechanism is on the consent page.
3 — A permanent record of who did what
The money side is built so history is evidence, not something that can be quietly changed. The commission and payout records are add-only and tied to refunds: a correction is a new entry that points back to what it corrects, never an edit in place, so the record is both the balance and the full history at once. Approvals (a school commerce approval, a “no identifiable students” declaration, a consent grant) record who and when, and that record survives even if the person’s account is later removed — the fact outlives the person who made it. Nothing important is silently rewritten after the fact.
4 — A PCI SAQ-A posture: raw card data never touches our server
Card numbers, CVC, and expiry are captured and tokenized entirely client-side by Stripe’s hosted PaymentElement iframe. Our server seam only ever receives Stripe-issued opaque ids (a PaymentIntent / charge reference) — never a primary account number. This keeps us in the SAQ-A scope (the lightest PCI self-assessment), and it is held by a CI-enforced structural wall — a test that fails the build if raw card fields could reach our code. The order ledger stores integer cents; Stripe holds the card and the card’s lifecycle. Payouts to studios and schools ride Stripe Connect on the same rail.
5 — COPPA & FERPA walls
Student-data protection is structural. The single-school FERPA wall is the built-in database privacy rule above: a member tied to one school cannot read another school’s student rows. A separate rep PII wall means a studio or sales rep sees aggregates, adult contacts, and reconciliation — and never a student row — which is what makes a genuinely resold product possible without anyone outside the school touching a child’s record. And COPPA is a hard under-13 block in the commerce path with an attestation lane of record, not a policy paragraph. The picture-day pipeline is consent-gated the same way: a student’s photos are never sold, and a sale is possible only when permission says so. Facial recognition stays off unless a parent turns it on, and a family finds their own child by a permission-checked roster lookup, never a face match. Any face data a parent opts into stays on our own private system and is destroyed when consent is withdrawn — detailed on the privacy page.
6 — When we use AI, your students’ data stays in our own private system
The common practice across school software is to ship a child’s information — a name, a face, a message — off to an outside artificial-intelligence company to do the work. Homeroom is built the opposite way: when Homeroom uses AI, it runs on Homeroom’s own computers, and no student information is sent to an outside AI company. The AI hides personal information before processing, filters its own output, and refuses to create images of people. Any data it derives — like the photo-organizing vectors that power search — stays inside our own system and is kept only for a defined retention window, never shared with an outside AI company. For a school weighing student privacy in the age of AI, that is a real difference, not a setting. The data-stays-in-our-own-system posture is shipped
The features that lean on this — an AI that can only state facts it can back up, plus read-aloud, photo descriptions, and private translation — turn on as our own in-house models come online. We mark those coming, never available, so you always know what runs today. The in-house AI features are coming
What this page is — and isn’t
Every wall above is live today, and several are proven against a real database or held by an automatic structural test. This page describes what the platform does; it is not a regulator’s certification or an attestation report. The binding artifacts — the data-flow and subprocessor map, the security-questionnaire responses, and the privacy policy — are the compliance documents of record, and we’ll walk your security team through them directly. We’d rather show you the mechanism than wave a badge.