“Do you hold SOC 2 or ISO 27001?”

No. We do not carry a third-party security certification today, and we would rather say that plainly than dress the page in a badge we have not earned. What we can show instead is the actual tenant model above and a named security contact who will walk your review team through it directly.

“What happens at a tenant boundary if something goes wrong?”

A bug that reached across tenants would be a sev-1 incident, not a quiet patch -- the same severity class as data loss. We have not published a formal incident-disclosure SLA number, and we say that rather than invent one; a district asking for one gets a direct answer in the same conversation as the review.

“Is our data ever used to train anything?”

No product on this network trains a model on customer data, and no AI feature reads across a tenant boundary -- there is no AI feature live on this network today for us to make that claim about in the first place.

“Who else is on this network?”

Every Homeroom-family and Stanley Studios property -- schools, districts, and independent photography studios -- runs behind the same perimeter, each on its own tenant key. A studio's client list and a district's student roster are never the same tenant, and neither can query the other.

Network & tenant isolation

Castra is the perimeter every Homeroom-family site runs behind.

A district technology director asking to see our privacy PROMISES belongs on fides.network. This page is for the person asking a sharper question: how is a school's roster actually kept apart from another school's, and another studio's client list, on the same shared network?

The four zones a request actually crosses

Every Homeroom-family and Stanley Studios request passes through the same four zones, in order, and no zone below the application layer knows which zone a request originated in was reached without the tenant key attached to it. If your worry is "what if a bug lets one tenant's request read another tenant's row," that worry is exactly what the tenant-key check on every query below is built to close -- not a promise, a mechanism.

Edge

Public traffic terminates at the edge network in front of every Homeroom-family host over TLS 1.2+ only; nothing at the edge holds a database credential, an API key, or a student record, and no plaintext HTTP path exists on any owned domain.

Application

Each request carries the tenant (school or studio) it belongs to; every query the application layer issues against Postgres is scoped to that one tenant's rows via a tenant-key column checked on every query -- there is no query shape, no admin flag, and no SQL path that reads across tenants.

Data

A school's roster, a family's order history, and a student's photo proofs -- data covered by FERPA and, for families under 13, COPPA -- live under that school's own tenant key; a second school's staff account has no path to read them, not even through an admin console. We do not publish a FERPA or COPPA compliance attestation; we describe the actual isolation instead.

Operator

Engineers who can reach production are a named, small set with individual OAuth-backed accounts, never a shared credential; a production access event is not a silent one -- it is the kind of event this page describes honestly below, not a claim we duck.

What actually runs behind this perimeter today

This is not an abstract diagram, and if you're wondering whether "the perimeter" is a real running system or just a page, here is what it actually is right now:

homeroom.software (the K-12 operating platform, Postgres-backed)
k12.photos (family picture-day ordering, JPEG/PNG proof delivery)
pholio.software (the photographer-side platform, CSV/SFTP roster import)
castra.email and pholio.email (staff mailboxes, SAML-ready sign-in where a district provides an IdP)

A school on homeroom.software and a photography studio on pholio.software are two different tenants on the same perimeter -- neither can see the other's data, and neither knows the other exists at the database layer.

Compliance context, not a compliance claim

A reviewer's checklist usually asks about FERPA, COPPA, SSO, and integration formats in the same breath as certification. We answer each one honestly and separately rather than folding them into one badge we don't hold:

Roster import accepts CSV today; Clever and ClassLink SSO/rostering are integration targets, not a live claim on this page -- we say so rather than imply either is wired.
No SQL injection surface at the tenant boundary: every application query is parameterized, never string-built from request input.
Webhook and cron-triggered background jobs (nightly roster sync, order-status callbacks) run inside the same tenant-scoped boundary as a live request -- a scheduled job gets no more reach than a user session.
iCal/ICS calendar exports and PDF order receipts are generated per tenant and never cached across tenants.

Every one of these is a statement about what the system actually does, never a claim that a document exists to back it -- if you need the document, ask, and we'll tell you honestly if we have one.

What we do not claim

We would rather a security reviewer read a short honest list here than find a gap on a call later:

No SOC 2, ISO 27001, or FedRAMP certification -- none is held today.
No published uptime SLA percentage.
No named third-party penetration-test firm or public pen-test report.
No AI model trains on, or reads across, tenant data -- because no AI feature runs on this network today.

Where a claim isn't backed by a document we can hand over, this page says so instead of implying it.

What a security review actually asks

“Do you hold SOC 2 or ISO 27001?”: No. We do not carry a third-party security certification today, and we would rather say that plainly than dress the page in a badge we have not earned. What we can show instead is the actual tenant model above and a named security contact who will walk your review team through it directly.
“What happens at a tenant boundary if something goes wrong?”: A bug that reached across tenants would be a sev-1 incident, not a quiet patch -- the same severity class as data loss. We have not published a formal incident-disclosure SLA number, and we say that rather than invent one; a district asking for one gets a direct answer in the same conversation as the review.
“Is our data ever used to train anything?”: No product on this network trains a model on customer data, and no AI feature reads across a tenant boundary -- there is no AI feature live on this network today for us to make that claim about in the first place.
“Who else is on this network?”: Every Homeroom-family and Stanley Studios property -- schools, districts, and independent photography studios -- runs behind the same perimeter, each on its own tenant key. A studio's client list and a district's student roster are never the same tenant, and neither can query the other.

Talk to the person who owns this

A vendor security review is a conversation, not a form, and there's no fee or lock-in to ask a question before you buy anything. Email [email protected] and describe what your review needs -- the tenant model above, a specific zone, or an honest answer to a question this page didn't cover -- and you'll hear back from the person who actually runs this perimeter, not a ticket queue.