Homeroom Gallery
A school’s photographs are student records that happen to be images
Picture day, events, athletics, publications, and video in one library, on the same roster and behind the same consent gate as the student record. That is what makes a withdrawn publication consent able to reach the yearbook, the online reader, and the print run — instead of reaching a person who has to remember.
The whole argument, in one chain
An outside photo host splits a school’s consent model in two. The publication permission is enforced in one system; the image sits in another system that has never heard of it. Nothing about that arrangement is malicious — it is just two products that were never introduced — but it means the school’s promise to a family is only as good as somebody’s memory on the day the print run goes out.
The chain below is the alternative, and every link in it is a thing that already exists rather than a diagram of an intention. The load-bearing part is the third arrow: the publications editor composes from the library rather than importing copies out of it. A copy is where a consent model goes to die.
What the library holds
Six collections, one library. Several of the school’s owned addresses point at this same thing on purpose — a school looking for its athletics photography and a school looking for its yearbook imagery are looking for two doors onto one shelf, not two products to buy.
Picture day
Built
The portrait run, from the cockpit to the record
Picture day is a scheduled operation, not a delivery of a box of prints. The cockpit covers the session, the roster it runs against, retakes, and the match back to the student record. Because the match is a roster lookup on a name and an id, a portrait lands against the right student without any face scanning being involved at all.
Cockpit and roster match built · the family store is early access
Also reachable at homeroom.pics, which is a door onto this library rather than a separate product.
Yearbook & publications
Built
The images the yearbook is actually built from
The publications editor reads the same library. That is what makes a consent withdrawal able to reach a print run: the editor is not importing copies from somewhere else, it is composing from the library where the permission lives. A student removed by a withdrawn consent leaves the digital edition, the online reader, and the print run together.
Editor and every publication type built
Also reachable at homeroom.pictures, which is a door onto this library rather than a separate product.
Events
Built
Concerts, plays, ceremonies, and the ordinary days
Event imagery is where a school's photo library usually fragments into staff phones and a shared drive nobody audits. Held in the library, an event collection carries the same per-student consent state as everything else, so the question “can this one be posted?” has an answer the system can give rather than one a person has to remember.
Collections and consent state built
Also reachable at homeroom.gallery, which is a door onto this library rather than a separate product.
Athletics
Built
Team and action photography on the activity roster
Athletics has its own rosters, its own seasons, and its own publication habits, and it is the collection most likely to be handled by a volunteer. Sitting on the activity roster means an image is attached to a real participant list rather than a caption typed from memory.
Activity rosters and collections built
Also reachable at homeroom.photography, which is a door onto this library rather than a separate product.
Video
Built
Moving image, under the same gate as the still
A consent model that governs photographs and quietly ignores video is not a consent model. Video is held as a first-class item in the same library with the same per-student state, so a family's decision does not depend on which format someone happened to shoot in.
Library support built · editing surfaces are outside this page's claim
Also reachable at homeroom.video, which is a door onto this library rather than a separate product.
Family delivery
Early access
Getting images to the families entitled to them
Delivery is a permission-checked read against the roster: a family sees the students attached to that family, and nothing else. There is no public gallery link that works for anyone who has it, because a link that works for anyone who has it is not a permission model.
Delivery built · the purchase side is early access, live payment not turned on
Also reachable at homeroom.vision, which is a door onto this library rather than a separate product.
What is built, counted honestly
These bars are counted from this page’s own collection list at render time, so they cannot drift away from the descriptions above them. They measure build state, not customers — there is no adoption number anywhere on this page.
How a photo gets attached to a student
The everyday answer is boring, and that is the point. A photo 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.
Face matching is off by default, and the capability behind it is not wired and cannot be switched on from this product. No face template is computed from a child’s photo in the shipping configuration. 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 photo 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 here, 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.
An image library versus a photo host
This compares two arrangements, not two companies. The left column is what a school ends up with by accident when imagery is solved one vendor at a time.
| The question a school gets asked | An outside photo host | Homeroom Gallery |
|---|---|---|
| Does a withdrawn consent reach the print run? | Only if someone remembers to go and fix it | Yes -- the editor composes from the gated library |
| Is a photo tied to a real roster entry? | Usually a filename or a typed caption | A permission-checked roster lookup on name and id |
| Does the consent model cover video too? | Often a separate tool with separate rules | Same library, same per-student state |
| Is facial recognition on by default? | Varies; frequently opt-out rather than opt-in | Off, and not wired to be switched on |
| Who enforces the cross-school wall? | The application, per feature | The database, re-checked on every build |
| Can the school take everything with it? | One export per vendor, where offered | One export and one wipe |
How money works here, and what is switched off
The core platform is free to the school. There is no per-student fee and no seat license for holding the image library, so nothing about a school’s photographs sits behind a payment.
The picture-day store is early access and live payment is not turned on. This page runs no checkout, quotes no price, and has nothing on it that takes money. We are describing a product a school will be able to run, not one a family can use this afternoon.
When it does open: families buy prints and downloads, the school earns from those sales above a cost floor enforced in code, payouts route to each party’s own connected account, and a fundraiser gift is never skimmed on the way through. Raw card data never touches our servers. That is the model, stated as the thing it will be.
Questions this page should answer
How is this different from putting the school's photos in a photo-sharing service?
A photo service holds files. This holds records. The difference shows up the day a family withdraws a publication consent: a photo service has never heard of that permission, so somebody has to remember which albums and which print jobs to go fix. Here the permission and the image are in the same system, so the digital edition, the online reader, and the print run all resolve the same answer without anyone remembering anything.
Do you use facial recognition to sort the photos?
Not by default, and not unless a parent opts in. The everyday way a photo is attached to a student is a permission-checked roster lookup on a name and an id -- the school's own list, not a face scan. Face matching is not wired in the shipping product and cannot be switched on from it: it holds no face-recognition model weights, and no face template is computed from a photo. Photo finding uses a permission-checked roster lookup instead.
Is there anything about that you have not finished?
Yes, and we would rather you read it here than discover it. The face-matching capability itself is not built: there is no model to load and no way to switch it on from this product, so we do not describe it as something a parent can turn on today. What does work is the part the gallery rests on -- the permission-checked roster lookup, the consent gate, and the suppression that keeps a do-not-publish child out of the library. When face matching is real and can be shown from one end to the other, this answer will say so, and not before.
Can a family buy prints through this?
Not today. The picture-day store is in early access -- built, opening gradually, not open -- and live payment is not turned on. This page runs no checkout and quotes no price. When it does open, a purchase routes to the parties the school controls above a cost floor enforced in code, and a fundraiser gift is never skimmed on the way through.
Who can see a given image?
Reads are permission-checked against the roster, and the wall is in the database rather than in the app -- a read that comes from another school returns zero student rows because the database itself refuses it, which is re-checked on every build. A family sees the students attached to that family. A minor's photo is never made public, never indexed by a search engine, and never sold.
What happens to the library if the school leaves?
It comes with them. Because the images live in the same system as the records rather than with a separate vendor, leaving is an export and a wipe rather than one negotiation per vendor. That is the other side of a single home: easier to hold, and easier to hand back.
Does the school own the photographs?
This page describes mechanism, not entitlement: the images are held in the school's own tenancy, they are never sold, and they are never handed to an outside company as a data set to be mined. Who holds copyright in a given photograph depends on how it was taken and by whom, and that is a question for the school and the photographer's agreement -- not something marketing copy should answer for you.
The rest of the platform this sits in
The image library is one part of a platform a school runs on. The whole-platform answer is at homeroom.software; where the data physically lives is at homeroom.cloud; and the same consent story written for the family rather than the school is at homeroom.family.
If you take one thing from this page, take the third arrow in the chain: compose from the library, never from a copy. Almost every broken photo-consent promise in a school is a copy that outlived the permission it was made under.