Concepts
How one school stays its own
Why a school's records are not a filter over a shared pool, and what that means for the people who operate the platform.
A school's records are the school's. This page describes what that means in practice, because "isolated" is a word that usually hides a mechanism rather than explaining a boundary.
The boundary is structural
One deployment serves many schools, and each school's record is its own rather than a set of rows distinguished by a column. A request names the school it is for and is answered from that school's records; there is no query that returns two schools' marks.
The practical consequence: a bug in one screen cannot become a leak between schools, because the screen never had access to a second school's data to leak.
The people who operate the platform
The console that operates the service holds the platform's records: which schools exist, their platform state, their subscription. That is a different kind of fact from a school's year, and the console is a different application with its own sign-in.
Reaching a school's records is a deliberate, recorded act rather than a capability that comes with the job. It is not impersonation: the school's own audit trail records what happened and who did it.
What this page will not claim
It will not claim a certification, an uptime figure, or a recovery target. Those are facts about a deployment rather than about the product, and security and data handling states what the product does and what it does not.