allschool.technology · For operators of more than one school · One instance, hard tenant walls
A diocese, a charter network, or a multi-campus private group already runs more than one school — a preschool, an elementary campus, a middle school, a high school — and today that usually means signing into a separate account for each one, re-entering a staff member twice when they move between campuses, and exporting five spreadsheets by hand to see the whole network at once. This page is about the technology underneath that: one operator sign-in, a roll-up view across every campus, and a hard wall so a family or staffer at one campus never sees another campus’s roster, records, or consent state — even though both run on the same instance.
Per-campus tenant isolation, roster sync, ID cards, and a branded page per campus are live today. The cross-campus roll-up dashboard is in early access, and money is honest-off — allschool.technology does not process payments yet.
Why a portfolio needs its own technology
This is not the single-school pitch. An operator with more than one campus has a portfolio problem: one identity across many schools, staff who cross campus lines, and a need to see the whole network without merging any one campus’s private data into another’s.
An operator running three, five, or a dozen campuses today typically holds a separate login for each one, because each school signed up for its own account on its own timeline. Checking enrollment across the network means opening every account in turn and adding the numbers up by hand.
A teacher who transfers from the elementary campus to the middle campus, or an administrator who covers two buildings, gets re-entered as a brand-new person in a second account if the two campuses are not on one platform -- a second directory row, a second ID card system, a second everything.
An aggregate view across a network is only correct if it reads the SAME roster data the individual campus pages read. A roll-up built on top of five separately-exported spreadsheets is a snapshot the moment it is built and wrong the moment a roster changes.
Every read and every write on this platform is scoped to a school. That scope is enforced server-side, on every route, not left to a client to honor voluntarily. A session authenticated at one campus cannot query another campus’s roster, records, or consent state — the query itself is bounded to the campus the session belongs to, so there is nothing to accidentally leak because there is no code path that reaches across the boundary in the first place.
Be precise about what that wall is and is not: it is a school-scoped query boundary, enforced in the application’s request handling. It is not a claim of separate physical databases per campus, and it is not a claim about encryption — neither is made here, and neither should be inferred. What is guaranteed is narrower and, we think, the thing that actually matters: a family or staffer signed into one campus never sees another campus’s data through this platform.
An operator-level account sits above the wall on purpose: it is the one identity that is granted a bounded, explicit view across the campuses it administers, so the wall protects campus-to-campus visibility without also blocking the roll-up the operator is here for.
The cross-campus roll-up is where an operator sees enrollment, records completeness, and roster activity added up across every campus in the portfolio, in one screen, instead of five separately-exported spreadsheets reconciled by hand. It reads the same tenant-scoped roster data each individual campus page already reads, so the numbers in the roll-up are never a stale snapshot built from a manual export.
This surface is early access today. It is named that way on purpose: the aggregate view is built on the per-campus data model that is already live, but the roll-up screen itself is still rolling out to operators. Nothing else on this page is dressed up as more finished than it is.
Underneath the operator view, each campus runs on its own roster, synced from that campus’s own student system or imported once and kept current. That campus’s ID cards and branded page come off that same tenant-scoped roster — a new student enrolling at the middle campus gets a card and a directory entry from the middle campus’s own list, never mixed with the high school campus a mile away.
A campus decides which pieces it uses — records, a directory, publications, picture day, family communication — the same way a single school does on the sibling platform. What is different here is that a whole set of campuses can make that choice independently while still rolling up to one operator account above them.
Every campus’s records and photos run on our own private systems. They are owned by the campus that holds them and are never sold to or shared with advertisers, data brokers, or any outside company. A minor’s photos are never made public, never handed to an outside search engine to index, and never sold, at any campus in the portfolio.
Find-my-photo is a permission-checked roster lookup, not a face match. It finds a student’s pictures by the roster tag a person with permission applied — the same tenant-scoped lookup the campus directory uses — not by scanning a crowd for a face. Face matching is a capability we are building and is not turned on today at every campus; it is not wired; it is not turned on today — we are building it. No face template is created. Photos stay inside our own private system, are never sent to an outside AI service, is kept for a limited window of about a school year, and is never sold. Withdrawing the opt-in stops the matching, on the spot, at that campus.
What already works, end to end, at every campus: mark a student do-not-publish and their pictures and their name drop out of that campus’s digital edition, online reader, and print run.
Live today: per-campus tenant isolation (a school-scoped query boundary enforced on every read and write), roster sync per campus, one operator sign-in across the portfolio, and ID cards plus a branded page for each campus off that campus’s own roster.
Early access: the cross-campus roll-up dashboard. It is named early access on purpose, and nothing else on this page is dressed up as more finished than it is.
Money is honest-off. allschool.technology does not process payments yet. Any funding tool a campus uses — ad sales, fundraisers, or the picture-day store where it exists — is a description of a tool the campus controls, not a live charge on this page; the platform never skims a campus’s fundraiser, and there is no live checkout here.
What this is: allschool.technology is a for-profit software vendor serving operators of more than one school. It is not a school, not a district, and not a nonprofit — even where the operator itself is a nonprofit diocese or charter network, the platform remains a for-profit vendor to it. There is no charity or donation framing here, and none would be honest. There are no invented adoption numbers, testimonials, or named networks on this page; the anchors are what the tenancy technology actually does. A conversation shows the current state honestly — what is built, what is early access, and what is honest-off.
FAQ
They are two views of the same underlying platform. allschool.software is written for a single school deciding whether one platform can carry records, a directory, publications, picture day, and family communication for that school alone. allschool.technology (this page) is written for an operator that already runs more than one school — a diocese, a charter network, a multi-campus private group — and covers the tenancy technology that lets those campuses share one platform instance without their data mixing. If you run one school, start with the umbrella page; if you run several, this page describes the wall between them.
Neither. The wall is a school-scoped query boundary enforced server-side on every read and write: a session authenticated at one campus is bounded to that campus's data at the query layer, so there is no code path that reaches across into another campus's roster, records, or consent state. We do not claim separate physical databases per campus and we do not claim encryption as the mechanism -- the guarantee we make is narrower and precise: campus-to-campus data does not leak through this platform.
An operator-level account is deliberately granted a bounded, explicit view across the campuses it administers -- that is the one identity allowed to see the roll-up. A staff member or family account at an individual campus does not get that broader view; they see only their own campus, the same as if that campus ran the platform alone.
It is early access. The per-campus data the dashboard reads is live and tenant-scoped today; the aggregate roll-up screen itself is still rolling out to operators. We say early access rather than implying it is fully built everywhere.
Because every campus runs on the same platform instance, a staffer who transfers between campuses in the portfolio is not automatically re-entered as a stranger in a second system the way they would be across two unrelated platforms -- but each campus's roster remains that campus's own record, and the tenant wall means a staffer's record at one campus is not visible from another campus's session without the operator-level view. The point is not automatic merging; it is that a network no longer needs a fully separate account per campus to operate day to day.
Find-my-photo is a permission-checked roster lookup, not a face match, and it is tenant-scoped the same as every other lookup: it finds a student's pictures by the roster tag a person with permission applied, within that student's own campus. Face matching is a capability we are building and is not turned on today at every campus; it is not wired; it is not turned on today — we are building it. No face template is created. Photos stay on our own private systems, are never sent to an outside AI service, is kept for a limited window of about a school year, and is never sold. Withdrawing consent stops the matching, at that campus, on the spot.
Not yet on this site. Money is honest-off — allschool.technology does not process payments yet. Funding tools like ad sales and fundraisers are tools a campus controls; the platform never skims the proceeds. There is no live checkout here.
Per-campus roster sync, ID cards, and the branded campus page are free to start and settle no money. allschool.technology is a for-profit software vendor — not a school, district, or nonprofit — and there are no invented adoption numbers or testimonials on this page. The honest next step is a conversation that shows the current state plainly: what is built, what is early access, and what is honest-off.
One operator sign-in, a roll-up across the portfolio (early access), and a school-scoped query boundary underneath every read and write — so a family at one campus never sees another campus’s roster, records, or consent state. Per-campus roster sync, ID cards, and the branded campus page are live and free to start, and money is honest-off — the platform does not process payments yet. A conversation walks the whole thing honestly.