The front office writes it once — the publication engine sets it, prints it, and posts it.

How a piece moves from the office to the family

The publishing flow is deliberately short. The office writes; the engine sets and posts; the send leg is named honestly as early-access. Nothing is re-keyed at the output stage.

1. The front office composes the piece. An announcement, a weekly newsletter, a bulletin — the office writes it once in the composition surface. This is authoring, not a mail merge against a separate contact list. The content is the school’s public message in the office’s own voice.
2. The audience resolves off the roster. Who the piece is for — a grade, a homeroom, the whole school — is scoped from the one imported roster and the school’s single-tenant isolation. The office does not keep a parallel mailing list; the audience is a projection of the roster it already maintains. A piece scoped to one school is never resolvable against another school’s families.
3. Any student-coupled disclosure is checked at emit. If the piece surfaces a student’s coupled information — a name, a photo, an award tied to a student — the consent substrate is checked at the emit boundary. The check happens at the moment the detail would be emitted, not in a reviewer’s memory and not in the database. A coupled detail without consent on file is not emitted.
4. The engine sets it to a print-ready page. The publications pipeline sets the piece through the VDP flat-paper rail — the same production path that generates report cards and yearbook pages. The output is a print-ready file assembled from what the office wrote, respecting the school’s template. A newsletter is a publication like any other on the engine.
5. The online edition is posted. The published piece opens on any phone from a link, with no app to install — the same read-side surface the yearbook online edition uses. This is the always-available read path: a stable URL a family can open where they are.
6. The live send is named as early-access. The outbound push — the email blast, the SMS or notification, the mailed printed edition through mailing.software — is honest early-access. We say so plainly rather than presenting the send as available today. The composition and the print-ready generation and the online edition are built; the live delivery is the early-access step.

FERPA and consent: a loud public voice, gated at emit

The front office speaks to families and community — that is the point of a public voice. But a school’s public voice can brush against student-coupled information: a student’s name in an honor roll, a photo in a spotlight, an award tied to a person. Front Office Press treats that boundary as the same FERPA boundary the rest of the platform enforces, not a lighter one because the surface is public.

The disclosure check happens at the emit boundary. A piece stored in the composition surface is not a disclosure — it is internal draft content. The disclosure event is the moment a student-coupled detail would be emitted into a published piece or an outbound send. That emission routes through the consent substrate: the consent record for the student is checked at the emit call, not in the database and not in a reviewer’s memory. A coupled detail without consent on file is not emitted into the public piece.

The audience is roster-scoped and tenant-isolated. A communication is scoped to the families on one school’s imported roster, and tenant isolation at the data layer means a piece for one school is never resolvable against another school’s roster. The public voice does not become a cross-tenant broadcast; it stays a single school’s message to its own community.

The platform is SIS-adjacent. The office reads the imported roster; it does not own the authoritative enrollment record. Front Office Press does not replace the school’s student information system and does not claim to. It publishes against the roster the office already maintains, and reflects roster changes on the next import cycle.

SIS-adjacent, not a system of record

Front Office Press sits alongside the school’s existing student information system; it does not replace it and does not own the authoritative roster. The office reads the roster the platform imports from whatever SIS the school already runs, and scopes a communication’s audience against that imported roster. The authoritative enrollment record stays in the school’s existing system.

This matters for the public voice specifically. Because the audience is a projection of the imported roster rather than a mailing list kept by hand, a family that leaves the roster leaves the audience on the next import cycle, and a family that joins is scoped in the same way. The office is not maintaining a second copy of the school’s community; it is publishing against the one roster the platform already holds.

The publications engine, the roster, and the consent substrate are shared modules. A term or a homeroom the front office scopes a piece to is the same roster structure the grade and report-card surfaces read. The modules share the data model; they do not each keep a separate list of families.