Homeroom Management · the district-operations face of the platform

One district. Forty buildings. One place to decide who may do what — and one record of what was done.

Every district that runs software across many schools ends up asking the same four questions, usually too late: who in my organisation can do what, in which building, to which class of data; what happens when the person who set it up leaves; what does an action leave behind; and what can the vendor see. This page answers those four, in that order, and states where the answer runs out.

It is not a pitch for adopting a platform — that argument lives elsewhere and this page assumes it is over. It is the administration layer above any single school: authority, consent policy, module posture, credentials, and the record. No price appears anywhere on it.

What we can see How scope works For a procurement office

Figure 1 District, school, classroom. Each level is anchored by a real column, named on the connector -- the hierarchy is in the schema, not only in application code.

On this page

This page is long on purpose. A district office does not read a product page front to back; it arrives with one question and needs to land on the paragraph that answers it. The list above is that index, and every entry resolves to a section on this page.

Four figures, each with its denominator

Numbers that say what they are a count of.

18coarse roles in the platform role union. Counted from the transcribed list further down this page, not typed as a headline -- so the number and the table cannot disagree.

3 of 5capability domains that the minor-staff wall can actually deny. The other two are not holes; they are governed by a different mechanism, and the type system now refuses a call that confuses the two.

2roles a platform operator may act as. Both are studio-owner tier holding no school membership. Every school-scoped role is refused before a session mints.

10columns on one row of the action record, including the prior state, the resulting state, and the human operator behind an acted-as session.

There are no adoption figures on this page — no district count, no customer name, no time saved, no percentage. Not because they would be unflattering but because none of them has been measured, and a marketing number without an instrument behind it is the thing this estate keeps having to withdraw. What is here instead is 696 database migrations behind the platform this page administers. That is a count of migration directories that exist in the repository at its current tip (packages/db/prisma/migrations), taken by a generator with a drift check, and printed here with the same bound the generator itself carries. It is NOT a query against any live database and NOT a claim that every one of them is applied to a particular one.

The same two numbers, as proportions

A fraction is harder to misread than a bare count.

Two of the figures above are ratios, and a ratio drawn as a bar shows the thing a number alone hides: that it is a part of something. Both are computed from the tables on this page rather than typed, and each prints its own value as text, so nothing here is carried by colour or by length alone.

Roles a child can hold3 of 18

Student, student ambassador, student author. Classified individually rather than inferred, and an unrecognised role is treated as one of them.

Capability domains that can be denied3 of 5

Roster identity, biometric, commerce. Content and governance are held by role and scope instead.

The gap this page is about

A district does not have a software problem. It has an authority problem, and software is where it becomes visible.

Consider a district with forty buildings. It is a scenario, not a customer; the number is doing the work of showing the shape of the problem. Somewhere in that district there is a person who can answer “who can see a student home address” for one building, because they set that building up. Nobody can answer it for all forty at once, and nobody has ever been asked to.

That is not negligence. It is what happens when authority is configured one building at a time by whoever happened to be available, in a tool that had no place to express “the district decided this.” Every individual decision was reasonable. The aggregate is a map that exists in nobody’s head.

The visible symptoms are familiar. A staff member changes buildings and keeps an access nobody remembers granting. A program runs in twelve schools with twelve slightly different consent postures. An auditor asks who approved something and the honest answer takes three days and four people. A vendor questionnaire arrives and the technology office answers it from memory, because the alternative is reading forty configurations.

None of those is solved by a dashboard. They are solved by having a LAYER where a district decision can be expressed once and inherited, and by that layer leaving a record. That layer is what this page is about, and the rest of this page is what it actually contains rather than what it would be nice for it to contain.

Definition, and four things it is not

A management plane is the layer where a district decision is expressible once, inherited downward, and left in a record.

Three properties, and all three have to hold. Expressible once: the decision has a place to live that is not forty places. Inherited downward: a building gets the district decision by default and diverges only where someone deliberately makes it a building decision. Left in a record: the decision, and every action taken under it, produces a row somebody can read later.

Take any one of those three away and you have something else. Expressible-once without inheritance is a settings page nobody reads. Inheritance without a record is a policy you cannot audit. A record without either is a log.

The reason this is worth naming as its own thing is that most platforms have the first property and stop. There is a settings screen at the top of the hierarchy, it holds nine switches, and everything that actually matters is configured per building because that is where the real objects are. The district level exists as a label rather than as a level.

What makes a level real rather than nominal is whether it is anchored in the data model. On this platform, a district is its own table, and a school carries a required district identifier as a foreign key with a restricted delete and its own index. That is a small, boring fact and it is the load-bearing one on this whole page: a level enforced only by application code is a level that one missing filter can skip, and the interesting question about any hierarchy is what happens when somebody forgets to write the WHERE clause.

It is not a separate product

There is no district edition to buy, no second login, and no separate contract for the administration layer. It is a facet of one platform in the same sense that the roster is a facet.

It is not a reporting tool

A report tells you what happened to students. This layer governs what may happen at all, and keeps the record of what did. Those are different jobs and conflating them is how a governance surface becomes a data-export surface.

It is not a building home base

The place a staff member signs into and finds their tools is a different surface with a different audience. That is homeroom.center, and this page does not restate it.

It is not one program run centrally

Running picture day across many buildings is a real, distinct job with its own console. This page is every program administration -- authority, posture, record -- and never describes a season.

The cascade

District, school, classroom — and the column that makes each level real.

Scope on this platform is a cascade of three levels, and each one is anchored by something a query cannot forget. The district is a first-class table rather than a text field on a school row. Every school carries the district identifier as a required foreign key, with a delete rule that refuses to orphan the buildings under it, and an index so the lookup is a lookup rather than a scan. Below that, the school is the tenancy leaf that almost everything else hangs from.

Why write the anchor down instead of just saying “multi-district support”? Because the phrase is compatible with an implementation that stores the district as a string on each school and filters in application code, and those two implementations behave identically right up until the moment somebody adds a route that forgets the filter. The failure mode of the weak version is not an error message. It is a page that shows one district data to another one and looks perfectly normal.

The three scope levels, what each holds, and what anchors it. The anchor column is the point: it names the mechanism rather than asserting the property.
Level	What it holds	What anchors it
District	Policy, module posture, credential ownership, the boundary a key may never cross.	district, a first-class table -- not a text field on a school row
School	The tenancy leaf almost everything hangs from: staff, roster, calendar, publications, the building's own record.	school.district_id, a required uuid foreign key with a restricted delete
Classroom and section	The teaching surface: a section, its roster, its work, and the staff attached to it.	the school leaf every section-level row carries with it

The bound on this claim. A cascade in the schema tells you the hierarchy cannot be skipped by a forgotten join. It does not by itself tell you that every route in a large application asks the right question of it. Those are two different assurances and a district office should ask for both separately — the first is a structural property you can read, the second is a review practice you should ask us to describe.

The role inventory

18 coarse roles, grouped by the tier a district actually thinks in.

A coarse role is the anchor a session carries: it is the first question every gate asks and the thing tenant isolation is keyed on. It is not the whole permission model — there is a finer capability tier on top of it, and publication mastheads are independent of it again — but it is the layer a district office needs to be able to name, because it is the layer that decides what a person is before anything asks what they may do.

Two of these deserve a district reader attention before the rest. The district administrator is a first-class member of the union rather than a school administrator with a wider filter, which is what makes district-level authority a real thing rather than a report parameter. And the student ambassador is deliberately kept distinct from the commissioned adult representative, because those two roles look adjacent on an org chart and are not adjacent at all: one is a child.

District tier

District tier — the roles in this tier, what a district office needs to know about each, and whether the platform classifies it as a role a child can hold.
Role	What it is for	Classification
District administrator `district_admin`	The district tier, and a first-class member of the role union in its own right -- not a school administrator with a wider filter bolted on. It is one of exactly two roles admitted as an eligibility official for protected meal-benefit status.	Adult tier

School staff and students

School staff and students — the roles in this tier, what a district office needs to know about each, and whether the platform classifies it as a role a child can hold.
Role	What it is for	Classification
School administrator `school_admin`	The building tier. The second of the two roles admitted as an eligibility official. Most day-to-day authority a district thinks it needs to hold centrally is in fact exercised here, one building at a time, which is the point of the cascade.	Adult tier
Teacher `teacher`	School staff. Deliberately NOT an eligibility official: a teacher operating a cafeteria point of sale or an athletics registration is staff, and staff is not the same as an authorized official for a protected status.	Adult tier
Student `student`	The core minor-held role. A student who carries a publication masthead title is still minor-held: the classifier answers a question about the ROLE, not about a birthday.	Minor-held
Student ambassador `senior_rep`	A STUDENT ambassador, and minor-held. Deliberately distinct from the commissioned account representative: a minor ambassador must never inherit an adult representative capability, and any reward routes through a guardian escrow flow rather than through the capability wall.	Minor-held
School coordinator `school_coordinator`	The building-side counterpart to a partner engagement -- the named person in a school who coordinates an operation running in that building.	Adult tier

Family tier

Family tier — the roles in this tier, what a district office needs to know about each, and whether the platform classifies it as a role a child can hold.
Role	What it is for	Classification
Parent or guardian `parent`	The family tier. What a guardian controls -- and the consent lifecycle behind it -- is the subject of homeroom.family, not of this page.	Adult tier
Alumni `alumni`	A graduate. The reunion and archive surfaces treat it as an adult tier, which is what makes it distinct from the student role it succeeds.	Adult tier
Booster or PTA operator `booster_pta`	A booster-club or parent-association operator: school-scoped, and walled off student records. It reaches consent-cleared directory and fundraiser surfaces, never a raw roster.	Adult tier

Partner and studio tier

Partner and studio tier — the roles in this tier, what a district office needs to know about each, and whether the platform classifies it as a role a child can hold.
Role	What it is for	Classification
Photography organisation `photographer_org`	A studio-owner tier whose membership is a partner organisation, never a school. One of exactly two roles a platform operator may act as.	Adult tier
Photography staff member `photographer_user`	A person inside a partner studio. Partner tier, not school tier: it holds no school membership by virtue of the role.	Adult tier
Partner administrator `partner_admin`	The white-label partner owner. The second of the two roles a platform operator may act as, and it reaches partner overviews with no student rows in them.	Adult tier
Account representative `account_manager`	The commissioned adult representative. Its reach is pre-expanded to an assignment list rather than a whole territory, and it is walled off the student census -- it is the one session denied that grant outright.	Adult tier

Platform tier

Platform tier — the roles in this tier, what a district office needs to know about each, and whether the platform classifies it as a role a child can hold.
Role	What it is for	Classification
Platform support `support_admin`	Us. Read the vendor-access section on this page before you decide what that means; it is the section most vendors write as a reassurance and we have written as a bound.	Adult tier

Field operations tier

Field operations tier — the roles in this tier, what a district office needs to know about each, and whether the platform classifies it as a role a child can hold.
Role	What it is for	Classification
Field crew `crew`	A dispatch-scoped field session, pre-expanded to its own assignment list rather than to the studio that dispatched it.	Adult tier
Scheduler `scheduler`	The operations role that builds and moves the dispatch calendar. Distinct from an administrator: scheduling authority is not records authority.	Adult tier

Authorship tier

Authorship tier — the roles in this tier, what a district office needs to know about each, and whether the platform classifies it as a role a child can hold.
Role	What it is for	Classification
Script author (adult) `playwright`	An adult script author on the playscript surfaces. Adult authorship and minor authorship are separate roles on purpose, because the submission gate differs.	Adult tier
Script author (student) `minor_playwright`	A student author, and minor-held. Minor authorship is consent-gated at the submission gate itself, separately from the capability wall -- two mechanisms, not one doing double duty.	Minor-held

Grouping is this page’s editorial choice for a district reader; the platform’s own union is a flat list of 18 literals and does not carry these tier names. The list, the notes and the classifications here are a DESCRIPTION transcribed from the platform role module — they are not the enforcement, and if the two ever disagree the enforcement is what runs.

Capability domains

5 domains. 3 of them can be denied — and the other 2 are not holes.

On top of the coarse role sits a finer question: which class of capability is this action in? There are five classes. The wall that keeps a minor-held role away from adult data can deny three of them.

The two it does not deny are not gaps. Content is the domain a student staffer is supposed to be in — a student editor making a page is the whole point. Governance is held by role and scope rather than by that wall, because “is this person a child” is the wrong question to keep somebody out of an administration screen; “is this person an administrator” is the right one.

The five capability domains, what each covers, and whether the minor-staff wall is the mechanism that governs it.
Domain	What it covers	Minor wall
Content `content`	Making and publishing the school's own work -- pages, stories, spreads, editions. This is the domain a student staffer is SUPPOSED to be in, which is exactly why the minor wall does not deny it.	Held elsewhere
Roster identity `roster_pii`	Identity fields beyond a name. Denied to every minor-held role, on every surface, without a route having to remember.	Deniable
Biometric `biometric`	The most tightly held class on the platform. Denied to every minor-held role by the same predicate, in the same call.	Deniable
Commerce `commerce`	Money surfaces. Denied to every minor-held role. Note the separate posture on this page: live payment capture is not something this page claims at all.	Deniable
Governance `governance`	The administrative surfaces themselves -- who is in what role, what is turned on. It is not in the deny set because the minor wall is not the mechanism that keeps a student out of governance; role and scope are.	Held elsewhere

Why this section exists at all. The predicate that denies those three used to accept any of the five as an argument. So a call naming one of the other two was type-correct, read as correct in review, and could only ever return false — a permanent no-op that quietly reduced its gate to nothing. Three such dead calls were live before anyone noticed.

The fix was not to correct the three call sites. It was to narrow the argument type to the three domains the predicate can actually deny, which turns a wrong-domain call into a compile error. That is the difference between fixing an instance and making the class impossible, and it is the standard a district office should hold any vendor to when they describe a security fix: after it, is the wrong thing still possible?

Delegated authority

What a district hands down, and the rung that does not move.

Delegation is the part districts get wrong in both directions. Delegate too little and the district office becomes a ticket queue for account changes in forty buildings. Delegate too much and the district has, in practice, forty policies and one letterhead.

The shape that works is boring: policy and posture set once at the district and inherited; operational authority delegated to the building; teaching authority delegated to the section. What matters is which rungs are actually available to move, and whether there is anything on the ladder that is not a setting at all.

There is. The wall that keeps a minor-held role away from roster identity, biometric and commerce data is not a permission somebody can grant. It is a predicate that runs on every one of its call sites, it is keyed on the role rather than on a per-person exception, and it fails closed for a role it does not recognise. No district administrator can turn it off for a student who is also an editor, because there is no switch for it — and there is no switch for it on purpose.

One concrete example of a delegation that is written down rather than assumed. Protected meal-benefit eligibility — who may read or set whether a student qualifies — has an admit set of exactly two roles: the school administrator and the district administrator. A teacher operating the cafeteria point of sale is school staff and is deliberately NOT an authorized official. Platform support is deliberately not one either.

That rule lives in one place and every lane that needs it calls it. It got there because it did not: it was an eleven-line closure inside one route, correct but unimportable, so a second lane that needed the same rule did not have it and emitted the protected field to a teacher. The same protected fact was walled on one lane and open on the other because the rule had no shared home.

Figure 2 The delegation ladder. The top two rungs are district decisions a building inherits. The middle two move. The bottom one is not a setting and cannot be granted.

Vendor access — the section most vendors write as a reassurance

What we can see, stated without flattery.

Every district security questionnaire contains a version of this question, and almost every vendor answer is a sentence with a load-bearing word doing quiet work in it. Here is ours, split into the part that is a hard wall, the part that is a logged and bounded reach, and the part that is not built yet. All three are true at once and leaving out the third would make the first two dishonest.

What is a hard wall

Platform support staff cannot ACT AS a school-scoped user. The allow list for acting-as holds exactly two roles, both studio-owner tier whose membership is a partner organisation rather than a school, and the check additionally refuses any target that carries a non-empty school or district membership even if its role is on the list. Both conditions must hold; either failing denies; an unrecognised role denies.

This closes a specific and serious vector: without it, stepping into a school user account would let an operator read student records UNDER THAT USER NAME, which does not merely widen access — it corrupts the audit trail by attributing an operator read to a school employee. The acted-as session carries the target’s own role and scope and is never elevated, and the record carries a separate column naming the human operator behind it.

What is a bounded, logged reach — not zero

We will not tell you that nobody here can ever reach a student record. That sentence is false for a direct support session and it must never be quoted as a compliance claim. By deliberate design, a platform support session resolves an administrative platform scope and reaches the student census across tenants for support work.

What is true today: entering that scope is itself logged — who, what level, which route, when — and is protected by a second authentication factor. It is an attributed elevation, not an anonymous bypass. It is not zero and it is not invisible.

What is not built yet

Two controls over that reach are designed and are not live. A per-access log of individual student reads and writes on a support session, immutable and visible to the customer. And a reason-bound, time-boxed break-glass gate over it, so each access is not merely attributable but justified and expiring.

Until those land, individual student reads on a direct support session are NOT individually logged. Do not read this paragraph as a present-tense capability and do not let anyone quote it into a data-processing agreement as one. It is on this page because a district office deserves to learn it here rather than discover it in month seven.

We are aware that publishing the third paragraph costs us something with a reader who is comparing vendors on a checklist. It buys the only thing that matters more, which is that the first two paragraphs are worth believing. A vendor whose honest limits never appear anywhere has not run out of limits; they have run out of places to put them.

The record

An action leaves 10 columns behind, and two of them are the ones that matter.

Most systems that claim an audit trail keep a line of text. A line of text tells you that something was changed. It does not tell you what it was before, which means the only thing you can reconstruct from it is that somebody was there.

The action record here keeps the prior state and the resulting state as structured data in the same row. That is what makes a difference computable rather than eyeballed, and it is the difference between a log and a record. The other column worth naming is the one that holds the human operator behind an acted-as session, so an act-as can never launder into somebody else’s name.

It is indexed for the three questions people actually ask: what happened in this building over this period, what happened to this object over its life, and what did this operator do. An audit surface that is only indexed by time answers the first question and makes the other two a table scan, which in practice means they do not get asked.

One row of the action record, column by column, and the question each column answers.
Column	What it answers
`at`	When, to the microsecond, with a time zone -- not a local clock string.
`school_id`	Which building the action belonged to. Nullable, because not every action belongs to one.
`actor_user_id`	Whose scope the action ran with.
`impersonated_by`	The human operator behind an acted-as session, when there was one. This is the column that keeps an act-as from laundering into someone else's name.
`action`	What was done.
`object_type`	What kind of thing it was done to.
`object_id`	Which one.
`before`	The prior state, as structured data rather than a rendered sentence.
`after`	The resulting state, in the same shape, so a difference is computable rather than eyeballed.
`ip`	The network address the action arrived from, stored as an address rather than a string.

Figure 3 One action, one row. The three highlighted columns are the ones a log usually leaves out: the operator behind an acted-as session, and the state on both sides of the change.

The bound, and it is a real one. The general action record is a RECORD. It is not a tamper-evident ledger and this page will not call it one.

A separately named set of compliance ledgers IS a different thing: those are declared append-only and refuse an update or a delete with a database trigger rather than by application convention — a life-safety alert audit, a consent ledger, a grade-change log. A correction to an issued grade becomes a new row with an amended status rather than an edit to what a family already received.

Knowing which of those two you are being sold is the whole question, so this page separates them rather than letting the stronger word cover both. If your auditor needs a specific table to be in the stronger class, ask about that table by name.

Module posture

Off until somebody turns it on — and the turning-on is a thing that happened.

“Secure by default” is worth nothing as a phrase. What is worth something is naming the column that carries the default, because then a reader can check it. Here are five defaults with the mechanism attached to each.

The pattern underneath them is the same: registering a capability and enabling it are two separate acts. That sounds like friction and it is the point. A district that has to make the second decision explicitly is a district where somebody’s name is attached to it, and the enabling of a module is itself a normalized event in the platform rather than a state that was simply always true.

Five defaults, each with its mechanism named. A default with no mechanism beside it is an assurance, not a fact.
Capability	Default	The mechanism
A registered single-sign-on service provider	Registered, disabled	The per-school service-provider registry carries an enabled flag that defaults to false. Registering a provider and turning it on are two acts, done by two decisions, and the second one is somebody's name.
A per-client consent interstitial	Off, opt-in per client	The consent gate on a sign-on client is a per-row boolean defaulting to false, precisely because a single environment variable cannot express client A requires consent and client B does not. A first-party surface stays consent-free; a third-party client opts in.
A platform module	Entitlement-gated	A module surfaces only where the tenant is entitled to it. Turning one on is a normalized cross-module event in its own right, which means the enabling is itself a thing that happened rather than a state that was always so.
Face matching	Off	Off by default across the estate. This page administers a platform and does not itself operate any imagery surface; the sibling pages that do own that account, and this page does not restate or soften it.
Live payment capture	Not claimed on this page	No money is claimed here. There is no price, no plan, no tier figure and no checkout anywhere on this page, and nothing on it can turn a charge on.

Why per-row rather than per-environment. The consent gate on a sign-on client is a boolean on the client row, not an environment setting, and the reason is stated in the schema itself: a single global switch cannot express “client A requires consent, client B does not.” A district with forty buildings and a mixed estate of first-party and third-party integrations needs to be able to say exactly that. A design that could only hold one answer per deployment would force the district into the loosest one.

Keys, sign-on, and boundaries

The boundary a credential cannot cross is the one worth checking.

Districts inherit integrations. A student information system, an assessment vendor, a transportation tool, three things somebody built in a scripting language in 2019. Each of those needs a credential, and each credential is a decision about blast radius that usually gets made once, quickly, by whoever was on the ticket.

Six facts about how credentials work here, each of which a technology director can check rather than take on trust.

A key carries a district anchor, and it is a wall

An interface key is anchored to a district and pinned to a school. The district column is described in the schema as the single-district boundary -- a key may never reach across districts -- and the school is the key's primary blast radius. Two organisations sharing an operator do not share a key surface.

The secret is never stored

What is kept is an argon2id hash of the secret half, plus a public non-secret identifier so verification is a single indexed lookup rather than a scan of every key. A display-only last four exists so a person can recognise a key in a list without the list being a list of secrets.

Revocation is a state, not a delete

A revoked key keeps its row and gains a revocation timestamp. The uniqueness constraint applies to LIVE keys only, so revoking one does not erase the fact that it existed, and reissuing does not collide with the history.

Scopes and a rate tier ride on the key itself

Each key carries its own scope list and its own rate tier. That is what makes least privilege expressible for a machine as well as for a person: an integration gets the calls it needs and no others.

Sign-on codes are single-use and short-lived

An authorization code is bound to the client, the user, the redirect target, the requested scope, a proof-key challenge and a nonce, expires in under a minute, and is stamped the instant it is exchanged. A second exchange of the same code is rejected rather than honoured.

Signing keys do not live in the configuration table

The per-school service-provider registry holds the entity identifier and the assertion consumer target -- configuration a school administrator can be trusted with. It has no certificate column and no private-key column; signing material stays in the key lane, which is a different lane on purpose.

What this section does not claim. It does not claim that every integration your district already owns will connect. Rostering and interchange formats are a real and separate conversation and this page will not turn a schema column into a shipped connector by describing it warmly.

Ask us about your specific identity provider and your specific rostering source by name, before you plan a rollout around either. An answer you get in a call and can hold us to is worth more than a logo grid on a web page.

The district view

A district view is aggregates. It is not a back door into a student record.

This is the section where a product page normally promises a district dashboard with drill-down, and it is the section where this one does not.

Holding a district role is not a general grant to open any record in the district. What a district role reaches is governed by the same role-and-domain checks every other session goes through, plus the consent chokepoint on any surface that names a student. Where the district tier IS admitted to a protected class of data, it is by a named admit set for a named purpose — protected meal-benefit eligibility is the worked example on this page — and the admit set is short and written down.

The reason to be strict about this in marketing copy and not only in code is that district-level drill-down is the single most requested feature in this category and the single most common way a records wall gets negotiated away. A vendor who advertises it has already made the decision. We would rather have the conversation about what your district actually needs to see, which in our experience is usually counts, coverage and exceptions rather than records.

What a district office usually needs, and can have without a records wall coming down: whether a building has completed a step, how many records are missing a required consent, which buildings have a module enabled, which credentials are live and who created them, and what actions an operator took. None of those requires opening a student record and all of them are the questions that actually come up in a district office.

Rollout

Forty buildings do not go live on a Monday, and a vendor who says otherwise is describing an installer.

This is not a schedule and it is not a services pitch. It is the order the decisions have to happen in, which is the part districts most often discover backwards — usually in month nine, when a policy question turns out to require revisiting every record created before it was answered.

One building, on purpose
The first building is not a pilot in the marketing sense. It is the building where the district finds out what its own data actually looks like -- which name fields are populated, which staff list is stale, which consent record was never captured because the paper form lived in a filing cabinet. Every district discovers something here, and discovering it in one building is the whole point.
The authority map, written down
Before the second building, somebody writes down who holds which role and at what level. Not as a diagram for a slide -- as the thing that gets entered. A district that skips this step does not avoid the decision; it defers the decision to whoever happens to provision an account first.
Module posture set at the district, not per building
Which modules are on is a district decision that a building inherits, and it stays that way unless the district deliberately makes it a building decision. This is the difference between forty buildings running one platform and forty buildings running one platform each.
Consent policy before consent volume
The consent posture is decided before the second building goes live, because retrofitting a consent decision across a district is not a configuration change -- it is a conversation with every family whose record was created under the old posture.
Buildings in waves, by calendar not by count
Buildings go in waves shaped by the school calendar, not by an even split of the total. A high school in the month before its yearbook deadline and an elementary school in the week before picture day are not interchangeable slots in a rollout plan.
The record, read once, early
Somebody in the district office reads the action record for the first building before the fifth building goes live. Not because anything is wrong -- because the first time anyone reads an audit trail should not be the day they need it.

The claim being made here is narrow and worth stating exactly: this ordering does not make a district rollout fast. It makes the surprises early. That is the only version of this promise anyone can keep, and it is the version this page is willing to make.

For a procurement office

The packet, its status column, and the two documents that are not in it.

A procurement office does not evaluate a product page. It evaluates a packet, and the most important column in that packet is not what each document is — it is what state each document is in.

There is a real procurement index in our repository. It is headed as a draft pending counsel review, it marks individual items as needing verification, and its own reading guide puts the gap list at the FRONT of a reviewer attention rather than in an appendix. The table below is that index, including the two rows that say a document does not exist yet.

The compliance artifact index and its honest status column. Two rows are gaps rather than deliverables, and they are the reason this table is on a marketing page at all.
Artifact	What it is	Status
Privacy policy	What student, staff and buyer data is collected, the purpose-bound consent model, the retention and deletion posture, and the sub-processors.	Draft Draft, pending counsel review
Data processing agreement	The processor agreement, structured against the national data-privacy agreement shape, carrying the technical and organisational measures as an exhibit.	Draft Draft, pending counsel review, then signature before any paid pilot
Under-13 disclosure	How under-13 data is handled, the school-consent basis for the educational core, and the deny-by-default exclusion of under-13 and unknown-date-of-birth students from every non-educational lane.	Draft Draft, pending counsel review
Sub-processor list	Which vendors may process data, what each receives, and the configuration seam that gates each one on or off. Several lanes are configuration-gated OFF by default.	Draft Draft, pending counsel review
Security overview	Tenant isolation, the student-records wall over privileged platform roles, encryption posture, sign-on, the deny-by-default consent and boot gates, and audit logging.	Draft Draft, pending counsel review
Accessibility conformance report	A published conformance report scored PER SURFACE rather than as one grade for a whole product, against the current success criteria.	Gap Draft, self-attested by code review. No automated scan and no assistive-technology user testing has been run. An independent published audit is open.
Security questionnaire response	A reusable answer set mapped onto the standard forms a district security office sends.	Gap DOES NOT YET EXIST as a standalone document. The substantive answers exist across the security overview and the agreement exhibit; the mapping onto a standard form has not been done.
Data-flow and inventory diagram	One page: what data classes flow where, the residency, and the trust boundaries.	Gap DOES NOT YET EXIST as a standalone document. The underlying flows are written down in the sub-processor list and the security overview; a single diagram artifact has not been produced.

3 of these are gaps, and here is what that means for your timeline. A mapped security-questionnaire response and a one-page data-flow diagram are the two artifacts a thorough district security office asks for that do not exist as standalone documents today. The substantive answers exist — they are written across the security overview and the agreement exhibit — and the remaining work is rendering them onto your form and onto one page.

The accessibility conformance report is a third qualified row: it is real, it is scored per surface rather than as one grade for a whole product, and it is self-attested by code review. No automated scan and no assistive-technology user testing has been run, and an independent published audit is an open item.

If those are blockers for your board packet, they are blockers, and you should plan for them rather than find out. If they are work items, tell us which form your office sends and it becomes a piece of work with a date on it.

On money, this page says nothing, and that is deliberate rather than coy. There is no price, no plan, no tier figure and no checkout anywhere on this site. What a district pays is a conversation with a person who has seen your building count and your requirements, and any figure printed here without that conversation would be a number invented for a web page.

On the vendor role: the district or school is the data controller and we are the processor. That framing belongs in the executed agreement where your counsel can hold us to it, not only in a sentence on a marketing page. Ask for the clause.

Three ways a district runs this today

The honest comparison is against the status quo, not against a company.

No vendor is named on this site, on this page or anywhere else, and the comparison below names none. The three columns are the three SHAPES a district operation takes: a shared drive and a spreadsheet and somebody’s memory; a good console per program, each excellent inside its own boundary and blind outside it; and a management plane.

The second column is the interesting one, because it is where most well-run districts actually are. Nothing in it is bad. A per-program console can be genuinely better at its program than a general platform is. What it cannot do is answer a question that spans programs — and “who can see a student home address” spans every program at once.

Three shapes a district operation takes. The verdict in every cell is written as words as well as a mark, so the table reads correctly with the stylesheet removed and with colour ignored.
The question	Spreadsheet and shared inbox	A good console per program	A management plane
A district decision expressible in one place	One spreadsheet per program	One console per program	District tier is a real level
A building inherits the district default	By memory and reminder	Within one program only	Anchored by a required key
One record of who did what	Sent items and file history	Per tool, per format	One row, before and after; not tamper-evident
A wall a local administrator cannot switch off	Nothing to switch	Usually a setting	A predicate, not a setting
A credential that cannot cross a district	A shared password	Scoped by convention	Anchored on the row
One place to answer a questionnaire from	Answered from memory	One vendor at a time	Packet exists, two artifacts missing
Survives the administrator who set it up leaving	The map leaves with them	Per tool, if documented	Configuration, not memory

2 of the 7 cells in our own column are NOT full marks, and they are printed that way on purpose — the action record is not tamper-evident, and the compliance packet is missing two artifacts. Both of those are said at length in their own sections above, so a table that quietly awarded itself a full mark here would be contradicting this page two screens later. A comparison table where the final column wins every row is an advertisement wearing the grammar of an analysis, and a procurement reader can tell the difference at a glance. That count is computed from the rows, not typed: the first draft of this sentence said “the last two rows” when only one was short.

The standard this page holds itself to

What this page claims, and what it does not.

A claim without a scope on it is the most common way a true sentence becomes a false one. Every line below carries its own scope, and the second half of the list is longer than the first half on purpose.

CLAIMS
That the district level is real in the data modelA district is its own table and every school carries a required district foreign key with a restricted delete and an index. That is a structural property a reader can check rather than an assurance.
CLAIMS
That the role and capability model is as describedEighteen coarse roles, three of them classified as roles a child can hold, five capability domains of which three can be denied by the minor wall, with the deny set lifted into the type system so a wrong-domain call is a compile error.
CLAIMS
That acting-as a school-scoped user is refusedThe act-as allow list holds two studio-owner roles and additionally refuses any target carrying school or district scope. Both conditions must hold. An unknown role denies.
CLAIMS
That an action leaves a record with both sides of the change in itThe action record carries the actor, the operator behind an acted-as session, the object, the prior and resulting state as structured data, the address and the time, indexed three ways.
DOES NOT
Claim that nobody at the vendor can reach a student recordThat is false for a direct support session and must never be quoted as a compliance claim. What is true is that the elevation is logged and second-factor protected, and that a per-access read log and a break-glass gate are designed and not live.
DOES NOT
Claim the general action record is a tamper-evident ledgerIt is a record. A separately named set of compliance ledgers is trigger-refused against update and delete at the database; the general record is not in that set and this page does not blur the two.
DOES NOT
Claim a price, a plan, a tier or a live chargeNo money is named here. No figure, no checkout, no card. Nothing on this page can turn a charge on, and nothing on it is for sale.
DOES NOT
Claim any automated or model-driven featureNone is described on this page, favourably or otherwise, because none is being offered here. If a questionnaire asks the question specifically, ask us directly.
DOES NOT
Claim a completed compliance packetTwo artifacts a district security office asks for do not exist as standalone documents today, and the accessibility report is self-attested with no independent audit and no assistive-technology testing yet. All three are named in the procurement section above rather than left out of it.
DOES NOT
Claim a legal conclusion or a compliance promiseMechanism only. What the system does is ours to state. What any law entitles a family to, or requires of your district, is your counsel and not a web page.
DOES NOT
Claim an adoption number of any kindNo district count, no customer name, no testimonial, no percentage, no time saved. Every figure on this page is a count of something in this repository, printed with the sentence that says how it was taken.
NOTE
This page is a description, not the enforcementThe marketing site is deliberately isolated from the platform packages, so the roles, domains and record fields here are transcribed with their sources cited rather than imported. If the description and the enforcement ever disagree, the enforcement is what runs and this page is what is wrong.

If any line here stops being true, the line changes rather than quietly softening. That is the standard, and it is the only part of this page a district office can hold us to before there is a signature on anything.

The hard questions

What a district office actually asks in the third meeting.

These are objections rather than features. A page that has not answered them is a page that wasted the first two meetings, so they are here, in the order they usually arrive, with the uncomfortable parts left in.

Our superintendent will not sign anything that gives a vendor a way into student records. What is your actual answer?

The honest one, which is longer than a reassurance. Platform support staff can be blocked from ACTING AS any school-scoped user: the act-as allow list holds exactly two roles, both studio-owner tier holding no school membership, and a target carrying any school or district scope is refused before a session mints -- so an acted-as session cannot surface a student row under a school user name. That is a real wall and it is the vector most people mean. It is NOT the same as saying nobody at the vendor can ever reach a student record: a support session that enters platform scope reaches the census cross-tenant for support work, that elevation is itself logged with who, what level, which route and when, and it is protected by a second authentication factor. What is not yet shipped is a per-access log of individual student reads on that direct session, and a reason-bound, time-boxed break-glass gate over it. Both are designed and neither is live. We would rather you read that here than find it in a questionnaire.

Can a district administrator open any student record in the district?

A district role is not a skeleton key, and this page will not describe it as one. The scope model is a cascade with real anchors: a district is a table, and a school carries a required district identifier with a restricted delete, so the hierarchy is enforced where a missing filter cannot skip it. What a district role can reach is governed by the same role-and-domain checks every other session goes through, plus the consent chokepoint on any surface that names a student. There are places where the district tier is deliberately admitted -- protected meal-benefit eligibility is one, where the admit set is exactly the school administrator and the district administrator and explicitly excludes staff and platform support. Those are decisions with names on them, not a general grant.

We have been burned by a rollout that took a year. What is different?

Nothing about the calendar. A district-wide rollout takes as long as a district takes, and any vendor telling you otherwise is describing their own installer, not your buildings. What is different is where the work lands: the decisions that usually surface in month nine -- who holds which role, which modules are on, what the consent posture is -- are the ones this platform makes you take in the first building, because they are configuration rather than custom work. That does not make the rollout short. It makes the surprises early, which is the only version of this anyone can promise honestly.

Our privacy office will want a completed security questionnaire and a data-flow diagram before we go to the board.

Neither exists as a standalone document today, and the procurement index in our own repository says so in those words rather than implying otherwise. The substantive answers exist -- they are written across the security overview and the agreement exhibit -- and the remaining work is mapping them onto the form your office sends and drawing the flows onto one page. If your office sends its form, that mapping is work we do rather than a document we already hold. Saying that plainly costs us a checkbox and saves you a month.

What happens to our data if we leave?

The right question, and one worth asking before signature rather than after. This page will not print a retention or export figure it has not verified end to end, because a wrong number in that answer is worse than no number. What it will say: the district is the data controller and we are the processor, that framing is in the agreement rather than only in a marketing sentence, and the exit terms belong in the executed agreement where your counsel can hold us to them. Ask for that clause specifically. If a vendor answers this question only on a web page, the answer is not binding.

Is this a separate product we have to buy on top of the platform?

No. This address is a facet of one platform, in the same sense that the roster and the consent module are facets. There is no separate district product, no separate login, and no separate contract for the administration layer. There is also no price on this page for any of it, because no money is named here: what a district pays is a conversation, not a table.

Who can turn a module on, and would we find out?

Enabling a module is an entitlement change at the tenant, and it emits a normalized cross-module event of its own -- the enabling is a thing that happened, with a time, rather than a state that was always true. The general action record captures the actor, the object, the prior state and the resulting state as structured data. So the question is answerable. Whether your district office has decided WHO may answer it is the part we cannot configure for you.

Our buildings are wildly different. Will one policy fit an elementary school and a comprehensive high school?

No, and the platform does not assume it does. That is precisely why the sign-on consent gate is a per-client row rather than a global setting, why the service-provider registry is per school, and why module entitlement is per tenant. The district decision is the DEFAULT and the boundary, not a uniform. A design that could only express one policy per district would be the wrong shape for a district with forty buildings in it.

How do we prove any of this to an auditor?

By reading the record and by reading the schema, in that order. The action record carries the actor, the acted-as operator when there was one, the object, the before and after state, the address and the time, indexed by building and time, by object and time, and by operator and time -- the three questions an auditor asks. Beyond that: a named set of compliance ledgers is declared append-only and refuses an update or a delete at the database rather than by convention. The general action record is not in that set, and this page calls it a record rather than a tamper-evident ledger for exactly that reason.

Do you sell student data, or use it to train anything?

No. Minors data is consent-gated and is never public. This page makes no claim about any automated or model-driven feature at all -- not a favourable one and not an unfavourable one -- because none is being offered here. If your questionnaire asks the question in a specific form, ask it of us directly and you will get the specific answer rather than a slogan.

What if the person who set all this up leaves the district?

Then the configuration outlives them, which is the actual argument for putting policy in a platform rather than in a person. Roles are rows, module posture is state, credentials are revocable individually and keep their history when revoked. The failure mode this replaces is the one where the only complete map of who can do what lived in one administrator's head and left the building with them.

You are describing your own product. Why should we believe the honest bits are complete?

You should not, on this page alone. What you can do is check the shape of the claim. Every number here is a count of something in this repository and prints with the sentence saying how it was taken. Every limit here is stated as a limit rather than softened into a feature. And the two documents your privacy office will ask for are named as missing on the vendor's own marketing page, which is not a thing a vendor writes unless the discipline is real. Then ask us the hard version in a call and see whether the answers hold.

Questions and answers

Shorter answers to the ones that come up most.

Is homeroom.management a separate product from Homeroom?

No. It is the district-operations face of one platform -- the administration layer above any single school. Same platform, same roster, same record. There is no separate district login and no separate contract for it.

How is this different from homeroom.center?

Altitude. homeroom.center is one school home base -- the place a staff member signs into and finds the tools for their building. This page is the layer above the buildings: authority, consent policy, module posture, and the record of what was done, across all of them at once.

How is this different from campus.management?

Scope of subject. campus.management runs ONE program -- picture day -- across many buildings: the season calendar, the assignments, the retakes, the order rollup. This page administers the PLATFORM across many buildings, and never describes a picture-day season at all.

Is a district a real thing in the data model, or a label on a school?

A real thing. It is its own table, and a school carries a required district identifier as a foreign key with a restricted delete plus its own index. The hierarchy is enforced in the schema, which is the layer a missing filter in application code cannot skip.

How many roles are there?

Eighteen in the coarse role union, of which three are classified as roles a child can hold. Those counts are derived on this page from the transcribed list rather than typed as a headline, so the sentence and the table cannot disagree.

What happens when a new role is added?

The build fails until somebody classifies it. The minor-held map is keyed on the full role union, so an appended role is a compile error rather than a silent default. And an unrecognised role at runtime is treated as minor-held -- deny, never admit, on the case nobody anticipated.

Can we bring our own single sign-on?

The registry for it is per school and its enabled flag defaults to off: a provider is registered and then separately turned on, which are two decisions with two names on them. Sign-on codes are single-use, short-lived, bound to a proof-key challenge, and stamped when exchanged so a replay is rejected. Talk to us about your specific identity provider before you plan around it.

Can an interface key issued for one district reach another one?

No. The district column on a key is described in the schema as the single-district boundary, and a key is additionally pinned to one school as its primary blast radius. Two districts sharing an operator do not share a key surface.

Is the audit log immutable?

The general action record is a record, and this page will not call it a tamper-evident ledger. A specific NAMED set of compliance ledgers is a different thing: those are declared append-only and refuse an update or a delete at the database rather than by application convention. Knowing which of the two you are being sold matters, so the page separates them.

Is there a price?

Not on this page. No money is named here: no price, no plan, no tier figure, no checkout, nothing sold. What a district pays is a conversation with a person, and this page is the part before that conversation, not a substitute for it.

Do you offer a district dashboard with student-level detail?

A district view is aggregates. This page does not claim that holding a district role opens any student record in the district, and it will not add that claim later without the mechanism to back it. Where the district tier is deliberately admitted to a protected class of data, it is by a named admit set for a named purpose, not by a general grant.

What can platform support see?

Read the vendor-access section above rather than this answer, because the short version leaves out the part that matters. In brief: acting-as any school-scoped user is refused outright, entering platform scope is logged and second-factor protected, and a per-access log of individual student reads on a support session is designed and not yet live. The full statement, including that last sentence, is on the page.

Does this page describe an artificial-intelligence feature?

No. It describes none, favourably or otherwise, because none is being offered here. If a district questionnaire asks about model-driven processing specifically, ask us directly rather than reading an inference into a marketing page.

Where do we start?

One building, a written authority map, and a conversation. Not a form, not a card, not a trial that quietly becomes a contract. Write to the address at the bottom of this page and say how many buildings you have and what your privacy office needs; that is enough to start.

The rest of the platform

The surfaces this page sits above, beside, and below.

Each of these is its own address with its own page and its own reader. None of them is this one, and this page does not restate any of them — where a subject belongs to a sibling, this page names the sibling and stops.

homeroom.softwareThe whole platform: student records, publications, picture day, the health office, communications and commerce, on one roster. homeroom.centerOne school home base -- what a staff member signs into inside a single building. The layer below this one. homeroom.familyThe parent side of the consent gate this page administers from the district side. The lifecycle of a family decision lives there. homeroom.digitalThe delivery facet: how a finished publication and an issued record reach the people they are for. homeroom.directoryThe people side of a school -- who is who, and who is reachable, under the same consent posture. campus.managementOne program across many buildings: the picture-day operations console, a different subject at a similar altitude. campus.softwareThe institutional platform argument to a district -- the adoption case this page assumes has already been made. apikey.softwareThe credential plane in its own right: the full account of keys, scopes and revocation summarized here in six lines.

Next step

A conversation, not a checkout.

There is no trial to start on this page, no form that turns into a contract, and no price to compare. What is useful at this stage is a short message with three things in it: how many buildings you have, what your privacy office needs to see, and which of the limits on this page is the one that worries you.

That last one is the useful part. A district that arrives having read the vendor-access section and the gap list is a district we can have a real conversation with on the first call rather than the fourth.

Write to [email protected] Book a conversation

Minors data is consent-gated and is never public. Nothing on this page is for sale and no figure on it is a price. Every count on it is a count of something in this repository and prints with the sentence that says how it was taken.