Skip to content

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.