School Photo Cloud · where your school’s photos live and how they are shared securely
Your school’s photos live in a private, school-owned store — not a public photo cloud.
School Photo Cloud is the storage-and-sharing layer for K–12 school photography: the honest answer to where your school’s portraits and any face data actually live, and how families reach them securely. Photos are stored and processed on our own private systems — never sent to an outside AI or photo company, never sold, never shared with outside companies, never placed in a public index. Each school’s photos sit inside their own walled tenant, so one school’s galleries are never visible to another school. Families reach a consent-gated online gallery and find their child by roster name — a roster lookup, not a face match. Access windows and retention are configured per school, and a one-click, school-owned export takes every record with it.
This is the storage-and-sharing home — deep on residency, per-school isolation, access windows, and retention. The operator toolchain is at schoolphoto.software; the app surface is at schoolphoto.app; where we operate is at schoolphotos.us. The full platform story is at homeroom.software. Order rails are in early access; no card is charged today.
What the store is: built, and honest about what is early access
School Photo Cloud has a clear shape: a private per-school store, consent-gated galleries families reach by roster name, per-school access windows and retention, and a one-click school-owned export. The storage-and-sharing layer is shipped and running. The order rails are built with the live payment leg honest-off. Each surface is marked plainly.
A private, per-school store — not a shared photo cloud
Every school’s photos sit inside their own walled tenant. Isolation is a RESTRICTIVE policy at the data layer that ANDs with every read — not a WHERE clause a route could forget. A session scoped to one school reads zero rows from another school’s photos: not filtered rows, zero rows, enforced by the database engine before any application code runs. One school’s galleries, rosters, and orders are never visible to another school, by construction. The photos and any face data are stored and processed on our own private systems — never sent to an outside AI or photo company. Shipped
Consent-gated online galleries
A student without a completed consent record does not appear in the shared gallery — not because a reminder asks the family to opt in, but because the data layer refuses to serve the portrait. The consent gate is enforced in code at the gallery layer: the store checks the student’s roster record for a completed consent status before admitting the portrait to any family-accessible view. A school administrator can see which students are consent-confirmed and which are pending before the gallery opens. Consent is revocable at any time; a withdrawal revokes access for that student’s record. Shipped
Families find their child by roster name — a lookup, not a face match
A family reaches the online gallery securely and finds their child’s photos by entering the child’s name against the school’s roster; the store confirms the family is the one attached to that roster record. This is a roster lookup, not a face match — there is no face scan and no facial recognition in the way a family finds photos. Facial recognition is off by default and plays no part in gallery access. A portrait is never visible to another family, never indexed in a public view, and never searchable by anyone outside the family and the school. Shipped
Access windows and retention, configured per school
The school sets when a gallery opens, how long it stays open, and when it closes. Photo and gallery data is retained for the configured access window and then purged on a defined schedule. If a family withdraws consent, the consent gate denies from that moment and no new photo link is issued — though a link already handed out can keep working until it expires, which we explain plainly in the withdrawal section below. Face data, in the one place it can exist at all, is a separate opt-in feature that is off by default; when it is on, the face template is held only inside our own private system, and the school’s face-data retention window (about 365 days by default) — or a withdrawal, that same night — is what marks it due for destruction. The destruction step itself is the one part of this that is not finished, and we describe exactly where it stands in the retention section below. Shipped
School-owned export — every record leaves with the school
The school owns its roster data, consent records, galleries, and order history from the first import. A one-click export of all records is available at any time, and PSPA/SPOA export delivers the structured portrait file the school’s student information system expects. If a school ever leaves, every record leaves with it — there is no lock-in and no residency in some outside company’s account. Running the store is free. Shipped · free
Order rails and parent store
The parent store — browsing, product selection, proofing, and order management — is built on the store’s commerce layer. The payment rail that would accept live family transactions is honest-off: present in the platform, not enabled for live purchases. There is no live checkout today, and no card is charged today. Texted family reminders and outside-lab fulfillment routing are in active development on the same layer. We name that plainly rather than presenting the live legs as available. Early access -- live payment rails
How a photo moves from picture day into the private store
The store has a clear data flow. Every step is gated: a photo is placed inside the school’s own tenant, matched to a roster record, and served to a family only after consent passes and the access window opens.
- The roster is imported into the school’s own tenant. A school’s roster lands in a walled tenant scoped to that school. From the first import, the roster, the consent records, the galleries, and the order history belong to the school. Nothing in this tenant is visible to another school’s session — the isolation is a RESTRICTIVE data-layer policy, not an application filter.
- Consent is collected per student, tracked per roster record. The school collects consent through its own channels; the store tracks the consent status against each roster record. A student without a completed consent record is flagged, and the administrator sees the consent-confirmed count before any gallery opens.
- Portraits are uploaded and matched to roster records. Each portrait is assigned to a student’s roster record explicitly during the upload workflow; that assignment is the access key. There is no face scan in this step — the match is the studio’s explicit roster assignment, auditable by the school.
- The photos are stored on our own private systems. The bytes live inside the school’s tenant on our own private systems, encrypted in transit. They are never sent to an outside AI or photo company, never sold, never shared with outside companies, and never placed in a public index.
- The gallery opens inside its configured access window. The school sets when the gallery opens and how long it stays open. No portrait is served to any family before the window opens and the consent check passes. A consent-confirmed family reaches the online gallery securely and finds their child by roster name — a lookup, not a face match.
- Families reach only their own child’s photos. Access is restricted to the family attached to the roster record. A portrait is never visible to another family and never searchable in a public index. Facial recognition plays no part in how a family finds photos.
- PSPA/SPOA export delivers to the school’s SIS. After gallery assembly, the PSPA/SPOA export produces the structured delivery file the school’s student information system expects, so the portrait the family sees and the portrait the school files are the same record from the same shoot.
- The access window closes; data is retained then purged. When the window closes, family access is revoked. Photo and gallery data is retained for the configured window and then purged on a defined schedule. A one-click, school-owned export of all records is available at any point — if the school leaves, every record leaves with it.
Where the photos live: residency and isolation
The whole point of School Photo Cloud is an honest answer to a plain question: where do our school’s photos actually live? The store is built around residency and per-school isolation, not treated as an afterthought.
Stored on our own private systems
Photos and any face data are stored and processed on our own private systems. They are never sent to an outside AI or photo company for processing, never sold, and never shared with outside companies. There is no public gallery, no social feed, and no advertising network reading the images. The store is a private vault, not a public photo-sharing service.
Per-school tenant isolation at the data layer
Each school’s photos sit inside their own tenant. Isolation is a RESTRICTIVE Row Level Security policy that ANDs with every read at the database engine, before any application code runs. A session scoped to one school reads zero rows from another school’s photos — not filtered rows, zero rows. It is not a WHERE clause a route could omit; it is a wall the engine enforces.
School-owned, no lock-in
The school owns its roster data, consent records, galleries, and order history from the first import. A one-click export of all records is available at any time. If a school ever leaves the platform, every record leaves with it. Nothing is stranded in an outside company’s account, because the photos were never sent to one.
Encrypted in transit, private by construction
Portraits are encrypted in transit into the school’s tenant. A portrait is never indexed in a public view and never searchable by anyone outside the family and the school. Access is gated by the consent record and the access window; a portrait outside its window or without a completed consent record is not served at all.
Access control: consent-gated, roster-keyed, withdrawable
Access to a portrait is controlled by two things: a completed consent record and an open access window. Neither is a policy reminder; both are enforced at the data layer.
The consent gate is enforced in code. A student without a completed consent record does not appear in the shared gallery — the store checks the roster record for a completed consent status before admitting the portrait to any family-accessible view. A school administrator sees the consent-confirmed count before the gallery opens. Consent is collected per student, tracked per roster record, and revocable at any time; a withdrawal revokes access for that student’s record and, where face data was ever created, stops the matching at the gate that same moment and marks the template due for destruction.
The gallery key is the roster, not a face. A family reaches the gallery securely and finds their child by entering the child’s name against the school’s roster; the store confirms the family is the one attached to that roster record. This is a roster lookup, not a face match. There is no face scan and no facial recognition in the way a family finds photos. Facial recognition is off by default and plays no part in gallery access.
Face data, in the one place it can exist at all, is a separate opt-in convenience that is off by default. Turning it on takes an explicit affirmative opt-in on file — an older blanket permission is not enough to enroll a student. Where a family opts in, a secure face template is created and held only inside our own private system — never an outside company, never handed back to anyone, never public, never sold. A parent reviewing the record sees an opaque handle, not the template itself. Withdrawing consent denies it at the gate immediately, so the template stops being used to match anything, and it is marked for destruction that night. We will not tell you it has already been erased — the step that carries out the destruction is not finished, and the section below says so plainly.
Retention: how long photos stay, and when they are purged
Storage is not forever. The store retains photo and gallery data for exactly the window the school configures, then purges on a defined schedule. Retention is a setting the school controls, not a default that accumulates quietly.
Photo and gallery data: the access window
Photo and gallery data is retained for the gallery access window configured by the school. After the window closes, family access to the gallery is revoked, and the data is purged on a defined schedule. The school sets the window; the store honors it.
Face data: about a 365-day window, if it exists at all
Face data exists only where a family opted in to face-assisted photo-finding, which is off by default. Where it exists, the face template is held only inside our own private system and is never sent to an outside AI or photo company. The school’s face-data window — about 365 days by default — is what marks a template due for destruction, and a withdrawal marks it due that same night instead of waiting out the window. Carrying that destruction out is the part that is not finished. The nightly job is built to refuse: rather than record a deletion it cannot complete, it stops, raises an alert, and writes a failed entry to the audit log. We would rather show a school the alarm than a checkmark we cannot stand behind.
Withdrawal: what is immediate, and the one part that is not
If a family withdraws consent, the consent gate denies from that moment. No new photo link is issued for that student, face matching stops, and suppression runs the whole way through: the student’s images and name drop out of the digital edition, the online reader, and the print belt.
One thing withdrawal is not, and we would rather say it than let you assume it: it is not an instant recall of a link we already handed out. A photo link is signed in advance and carries its own expiry, and the file server honours that signature without asking us again — so a link issued shortly before a withdrawal can keep working until it expires, and a copy already downloaded or sitting in a browser cache is beyond our reach entirely. We are deliberately not putting a number on that window here: the expiry is a setting, and we have not measured what a delivery network in front of it does to the real figure. When we have measured it, we will say it.
The part that is not finished is the destruction of the face template itself. A withdrawal marks it for destruction that night rather than leaving it to the scheduled purge — but the job that would carry the destruction out is not yet wired to the secure enclave that holds the template. So it does the only honest thing available to it: it halts, raises an alert, and records a failed entry in the audit log instead of a deletion that did not happen. That refusal is deliberate, and quieting the alarm to make the job look clean is forbidden in our own code. A school or family who wants to know where this stands can ask us and get the real answer.
Export before purge
A one-click, school-owned export of all records — roster data, consent records, galleries, and order history — is available at any time before the retention window closes. If a school leaves the platform, every record leaves with it. The school is never forced to choose between a scheduled purge and keeping its own records.
Order rails: built, with the live payment leg honest-off
Families who reach the gallery can browse products and assemble an order through the parent store. The store infrastructure — browsing, product selection, proofing, and order management — is built on the commerce layer. What is not enabled is the payment rail that would accept a live family transaction.
The payment rail is honest-off: present in the platform, not enabled for live purchases. There is no live checkout today, and no card is charged today. Early access — live payment rails When the payment rail is enabled, families and schools will be notified. We say so plainly rather than presenting a live checkout that does not exist.
Two adjacent legs are in active development on the same layer: texted family reminders (picture-day alerts, gallery-ready notifications, and order reminders sent to the family contact on the roster record) and outside-lab fulfillment routing (the ability to route fulfillment to a print lab of the school’s or studio’s own choosing). The reminder and lab-routing seams are designed; the production wire-up is in progress and not yet live. Both are honest-off for live use today.
Common questions
Where do our school's photos actually live?
Inside your school’s own walled tenant on our own private systems. Photos and any face data are stored and processed on our own private systems — never sent to an outside AI or photo company, never sold, never shared with outside companies, and never placed in a public index. The store is a private, school-owned vault, not a public photo-sharing cloud.
Can another school see our photos?
No. Each school’s photos sit inside their own tenant, isolated by a RESTRICTIVE Row Level Security policy at the data layer. A session scoped to one school reads zero rows from another school’s photos — not filtered rows, zero rows — enforced by the database engine before any application code runs. One school’s galleries, rosters, and orders are never visible to another school, by construction. It is not a WHERE clause a route could forget.
How do families find their child's photos?
A family reaches the online gallery securely and finds their child by entering the child’s name against the school’s roster; the store confirms the family is the one attached to that roster record. This is a roster lookup, not a face match. There is no face scan and no facial recognition in the way a family finds photos. Facial recognition is off by default and plays no part in gallery access.
Do you use facial recognition?
Not to find photos. Gallery access is a roster lookup, and facial recognition is off by default. The one place face data can exist at all is a separate, opt-in photo-finding convenience — off by default, and enrolling a student takes an explicit affirmative opt-in on file rather than an older blanket permission. Where a family opts in, a secure face template is created and held only inside our own private system, never an outside company, never handed back to anyone, never public, never sold. Withdrawing denies it at the gate immediately, so matching stops, and the template is marked for destruction that night. The destruction step itself is not finished yet — see “How long are photos kept?” below, where we spell out exactly where that stands.
How does consent gate the gallery?
A student without a completed consent record does not appear in the shared gallery — enforced at the data layer, not by a policy reminder that could be overlooked. The store checks the roster record for a completed consent status before admitting a portrait to any family-accessible view. A school administrator sees the consent-confirmed count before the gallery opens. Consent is collected per student, tracked per roster record, and revocable at any time; a withdrawal revokes access for that student’s record.
How long are photos kept?
Photo and gallery data is retained for the gallery access window the school configures, then purged on a defined schedule after the window closes. Face data, where it exists at all under an opt-in, is bounded by about a 365-day window by default; that window, or a withdrawal, is what marks a template due for destruction. We want to be straight about the last step: carrying the destruction out is not finished. The nightly job is not yet wired to the enclave holding the template, so it halts and raises an alert rather than record a deletion it cannot complete. Retention is a setting the school controls, not a default that accumulates.
What happens if we leave the platform?
Every record leaves with you. The school owns its roster data, consent records, galleries, and order history from the first import. A one-click export of all records is available at any time, and PSPA/SPOA export delivers the structured portrait file the school’s student information system expects. Because the photos were never sent to an outside company, nothing is stranded in someone else’s account.
Can families order prints today?
Not for live orders yet. The parent store — browsing, product selection, proofing, and order management — is built on the commerce layer. The payment rail that would accept a live family transaction is honest-off: present in the platform, not enabled for live purchases. There is no live checkout today, and no card is charged today. When the payment rail is enabled, families and schools will be notified.
Are texted reminders and outside-lab routing available?
Not yet. Texted family reminders (picture-day alerts, gallery-ready notifications, and order reminders) and outside-lab fulfillment routing (routing fulfillment to a print lab of the school’s or studio’s own choosing) are in active development on the same layer. The reminder and lab-routing seams are designed; the production wire-up is in progress and not yet live. Both are honest-off for live use today.
Is School Photo Cloud a public photo-sharing site?
No. It is the opposite: a private, per-school, school-owned store. There is no public gallery, no social feed, and no advertising network reading the images. A portrait is never indexed in a public view and never searchable by anyone outside the family and the school. The cloud here means a private, walled, school-owned vault, not a public photo-sharing cloud.
What does it cost to run the store?
Running the store is free. The storage-and-sharing layer — the private per-school tenant, the consent-gated galleries, the access windows and retention, and the one-click school-owned export — is free to the school. The order rails carry the future commerce leg, and that payment rail is honest-off today. There is no subscription and no pricing commitment on this page.
Related surfaces
School Photo Cloud is the storage-and-sharing layer under the rest of the photography fleet. These destinations cover the adjacent surfaces — the toolchain, the app, the jurisdiction framing, the network, and the flagship platform.
schoolphoto.software
The operator toolchain: how the picture-day work gets done. School Photo Cloud is the storage-and-sharing layer the toolchain writes into — where the bytes live and who can reach them.
schoolphoto.app
The app surface for running school photography. This page is the private store that surface stores into — the residency, isolation, and retention view for the school administrator.
schoolphotos.us
The where-we-operate framing. School Photo Cloud answers where the photos live at the system level — a private, school-owned tenant — rather than the jurisdiction level.
schoolphoto.network
The two-sided studio-and-school network. This page is the school administrator’s view of the private store the network’s photos sit in, with the same consent-gated, roster-matched posture.
homeroom.software
The flagship platform brand home: the full product story, and the complete picture of the storage substrate and every other surface on the platform.
What is built and what is honest-off
The private per-school store — tenant isolation as a RESTRICTIVE data-layer wall, so one school’s photos are never visible to another school — is built and running today. The consent-gated online galleries, where a student without a completed consent record does not appear, enforced at the data layer, are built and running today. Roster-matched private galleries, where families find their child by roster name (a lookup, not a face match), are built and running today. Per-school access windows and retention, plus PSPA/SPOA export to the school’s SIS and a one-click, school-owned export of all records, are built and running today, and the store is free to run. Photos and any face data are stored and processed on our own private systems and are never sent to an outside AI or photo company, never sold, never shared with outside companies, and never placed in a public index. Facial recognition is off by default; where a family opts in to face-assisted finding, the face template is held only inside our own private system with no outside recognition service connected, and withdrawing the opt-in stops the matching. The school’s face-data window — 365 days by default — is what marks a template due for destruction, and carrying that destruction out is the part that is not finished: the nightly job halts, alerts, and writes a failed audit entry rather than record a deletion it cannot complete. The order rails and parent store are built, but the live payment rail is honest-off — no live checkout, and no card is charged today. Texted reminders and outside-lab routing are in active development. No competitor brand names appear here. Money, pricing, and checkout are not live on this page.