One district. Many schools. One accountable operating layer.

District work breaks at the seams between products.

The yearbook team sees one roster. The photographer receives another. Communications keeps a third set of contacts. Finance reconstructs the transaction after the fact. District IT is then asked to explain who had access, which consent decision controlled publication, and why two schools followed different workflows -- usually after something has already gone wrong, not before.

Schooldistrict.software is the district-tier view of one vertically integrated platform, not a fourth system bolted alongside the other three. The direction is simple: keep school operations close to the people doing the work, while giving district leaders a shared identity and policy substrate, bounded cross-school views, and an inspectable route from rule to result.

That last phrase carries weight on purpose. 'Inspectable route from rule to result' means a district IT lead can trace a specific access decision back to the grant that produced it -- not a promise that every workflow is unified today; the boundary matrix below states plainly which parts are built and which remain planned.

Five jobs, five different views of the same platform.

A superintendent, a district IT lead, a procurement officer, a building principal, and a publication adviser do not need the same screen -- they need the same underlying facts, scoped to what their job actually touches. The tabs below state, per role, what is usable today and what the district workspace still has to add. Neither list is aspirational marketing copy: both are drawn from the same status labels the topic sections below carry.

One does not mean one giant permission.

The platform is designed around shared foundations, not universal access. District context and school context are distinct scopes, not two views over the same unrestricted query. Cross-school work must be explicitly district-scoped; school-level work remains school-scoped by default, with no implicit escalation.

Server-side district and school scopes exist today. The diagram below states the shape in one picture: three school boxes inside a district boundary, with the only path between them drawn as a gated line, because that is the actual mechanism -- a grant, not a shared password or a superuser flag.

A unified console that makes those boundaries visible and reviewable -- so a district IT lead can see the grant list instead of trusting this paragraph -- is planned as part of early access, and is listed as planned, not as shipped.

The district layer adds scope. It does not erase a school's own wall.

A school that already runs Homeroom on its own does not lose its boundary when its district adopts the district tier. The table below states, row by row, what changes and what does not -- including the two rows that read identically on both sides, because the security wall and the certification posture are not tier-dependent.

Roll out in waves. Keep the acceptance criteria visible.

The planned rollout workspace starts with an inventory: schools, school years, roster sources, publication programs, photo workflows, communication channels, and the district owner for each decision. The district chooses a pilot cohort, defines acceptance checks, and advances only the schools that meet them -- a school that fails a check stays on its prior workflow rather than being forced forward on a date.

The interface should answer practical questions before advancing a school: Did the roster reconcile? Are guardian relationships represented? Can district IT identify the system of record and export path? Does each school know who owns an exception?

A district edition without a district content free-for-all.

The platform contains a district-edition flow that lets a district administrator invite a school's publication adviser to contribute. Participation is grant-based. A school without a contribution grant contributes nothing -- there is no default-on visibility a district administrator has to remember to turn off.

Preview and compile share the same synthesis path, and contributed sections pass through a consent-clearing step before becoming district-edition content. That shared-path detail matters: it is what stops a preview from showing a family a page the compile step would have refused to publish.

This is a scoped claim about that one path, not a claim that every media egress across the estate is comprehensively hardened. Broader egress coverage remains in progress and is not represented as complete here.

Rollups should say what they know -- and what they estimate.

The district economics route builds per-school and consolidated school-year views from stored commerce records. Paid book-order lines, advertising records, confirmed donations, and other paid order lanes remain distinct line items -- they are not folded into one undifferentiated 'revenue' number that hides which part is actually collected.

Print costs appear only when the economics engine can calculate them from the stored inputs for that job; a cell it cannot calculate keeps its uncertainty visible rather than being filled with a plausible-looking estimate rendered the same way as a confirmed figure.

District reach should come with district restraint.

The planned governance workspace will separate district defaults, school-level execution, documented exceptions, and approval ownership -- four distinct concepts that a single 'district admin' checkbox tends to collapse into one.

Communications work will make audience purpose and exclusion reasons visible before delivery, rather than equating district authority with an unrestricted recipient list. Purpose-aware consent and audience components exist in the estate today; end-to-end district campaign authoring and sending are not claimed here.

The privacy wall belongs below the screen.

Student-coupled data is protected at the database-engine layer with restrictive row-level security. A database session without an explicit student-data grant reads zero protected rows -- not a filtered result set an application bug could widen, a hard floor enforced where the data lives.

A build-time check is designed to fail when a new student-coupled table is introduced without the required wall, so the protection is not something a future migration can silently skip.

On verified paths, public photo publication requires an affirmative grant and a do-not-publish override downstream of it. Classroom guest sessions can operate without student accounts, third-party advertising identifiers, or a behavioral profile. Basic short-lived operational logs may record requests needed to run and protect the service.

A date-of-birth/COPPA gate blocks under-age self-admission. These are specific engineering controls, not FERPA or COPPA certification, guaranteed compliance, or a claim that the system is fully minor-safe.

A requisition can be real before a payment rail is live.

The platform contains requisition, approval-ceiling, rejection, and budget-encumbrance logic. It intentionally does not disburse funds, transmit a live purchase order, or expose a pay endpoint. An unprovisioned environment reports that state rather than pretending a record was stored.

The planned district workspace adds requester intake, approval routing, contract references, vendor review, receipt acknowledgement, and exportable decision history. There is no live vendor marketplace, checkout, card capture, renewal, or public pricing on this page.

1. Draft -- a requester creates a requisition against a stated budget line.
2. Submitted -- the requisition enters approval routing at the ceiling appropriate to its amount.
3. Approved or rejected -- the decision and the approver are recorded; a rejection returns a reason, not a silent drop.
4. Encumbered -- an approved requisition reserves budget against the encumbrance ledger.
5. Disbursement -- deliberately NOT built on this surface. No payment is transmitted from this workflow.

Prove the boundary before promising the connector.

A district migration needs a source map for identity, enrollment, school year, guardian relationship, publication, consent, and finance. Each source needs an owner, refresh cadence, failure policy, and export path -- a spreadsheet of good intentions is not a migration plan.

The estate contains roster, OneRoster-related, and reporting components. This page does not claim certification or a completed district integration without an observed end-to-end implementation. Ed-Fi-class exchange remains planned unless specifically proven.

Give reviewers evidence, not a trust badge.

The planned evaluation room will organize data flows, subprocessor disclosures, retention and expunge behavior, integration boundaries, accessibility notes, incident contacts, and observed verification artifacts. Missing evidence will be marked open rather than inferred from marketing copy.

Child-safety guards use mutation-proof discipline: a test is expected to show that removing a guard revives the attack case and restoring it blocks the case while preserving a legitimate control. That discipline does not replace an independent audit or certification.