Bulletin · the school daily bulletin · a first-class publication
The daily bulletin, run as a real publication — dated editions, a roster-scoped audience, a print-ready page and an online edition.
A bulletin is not a memo taped to a door. It is a publication that recurs on a schedule — today’s edition, this week’s edition — carrying the day’s items in sections, assembled by an editor from what staff contribute. Bulletin runs that ritual on the same publications engine that sets report cards, newsletters, and yearbook pages: compose the edition once, and the engine sets it to a print-ready page for the office board and the morning read, posts it as an online edition anyone can open from a link, and keeps it in a running archive at its own dated URL. Who an edition is for resolves off the one imported roster, scoped to the right school, grade, or homeroom and walled to one tenant. Any item that names a student routes through the consent gate at the moment it is emitted. The composition, the print-ready page, the online edition, and the archive are built and running. The live outbound send — the inbox blast, the text, the automated read-aloud call — is honest early-access, and we name that plainly.
- A recurring, dated edition on the shipped publications engine — print-ready page and online edition.
- Audience scoped off the one imported roster, walled to a single tenant.
- Student-coupled items consent-gated at emit; the live send is honest early-access.
This is the daily-bulletin product page — deep on the recurring edition, the archive, the roster-scoped audience, and the consent-gated disclosure boundary. The whole front-office-as-publisher umbrella (announcements, newsletters, the community bulletin) is at frontoffice.press. The plain-language catalog of all K–12 modules is at schoolsoftware.app.
What Bulletin is
At the centre is one plain idea: a school’s daily announcements are a publication, and a publication deserves to be run like one. Bulletin treats each day’s bulletin as a dated edition — a first-class object with its own date, its own sections, its own contributors, and its own stable URL — rather than a fresh document retyped from scratch each morning. The recurring cadence is the point: a daily bulletin, a weekly bulletin, a Monday-only sports bulletin, each an edition in a series.
An edition rides the shipped publications engine — the same publications pipeline and VDP flat-paper rail that generate report cards, newsletters, and yearbook pages. The editor does not learn a separate tool for the bulletin; the platform already runs its printed output on this engine, and a bulletin is a publication like any other on it. The edition sets to a print-ready page for the office board and the morning-announcements read, posts as an online edition a family opens from a link, and drops into a running archive that is the school’s record of what was announced and when.
To draw the boundary honestly: Bulletin is the publication and its distribution surfaces that are built — composition, the print-ready page, the online edition, the roster-scoped audience, the consent gate, and the archive. The live outbound send that pushes an edition into inboxes, texts, and automated calls is honest early-access, and it defers to the platform’s communications arm and to mailing.software for a mailed printed edition. This page says which is which.
What is built and what is in early access
Bulletin has seven surfaces. The first five are shipped and running: the recurring bulletin engine, the dated editions and archive, the print-ready page and online edition, the roster-scoped audience, and the consent-gated disclosure boundary. The last two — the live outbound send, and two-way replies with per-family auto-translate — are honest early-access. Each is marked plainly.
The recurring bulletin engine
An editor composes the day’s edition and the publications pipeline sets it to a print-ready page through the VDP flat-paper rail — the same production path that generates report cards, newsletters, and yearbook pages. A bulletin is a publication like any other on the engine; it simply recurs on a schedule. The office does not adopt a separate tool for the daily read; it uses the one the platform already runs its printed output on. Shipped
Dated editions and a running archive
Each edition carries its own date and its own stable URL, and past editions stay readable as the school’s record of what was announced and when. Nothing is re-keyed edition to edition — yesterday’s bulletin does not overwrite; it is filed. The archive is the honest history of the announcements, not a single document that is edited in place until its past is lost. Shipped
Print-ready page and online edition
An edition sets to a print-ready page — for the front-office board and the morning-announcements read — AND posts as an online edition that opens on any phone from a link, with no app to install. The online edition rides the same read surface the yearbook online edition uses: a stable URL, a responsive reading page, nothing to download. The read path is always available, separate from the outbound push named below. Shipped
Roster-scoped audience
Who an edition is for resolves off the one imported roster and the school’s single-tenant isolation. A school-wide bulletin, a grade edition, a single homeroom’s edition — each is a projection of the roster the office already maintains, not a second list kept in a spreadsheet. Tenant isolation is enforced at the data layer: an edition scoped to one school is never resolvable against another school’s roster. Shipped
Consent-gated student-coupled items
Any item that names a student — a celebration, a photo, an award tied to a person — routes through the consent substrate at the emit boundary, the same FERPA posture the grade and report-card surfaces enforce. A student-coupled detail without consent on file is not emitted into the published edition. The bulletin is loud, but it is gated: never public without opt-in. Shipped
Live outbound send
Pushing an edition into family inboxes, firing an SMS, or placing an automated read-aloud phone call is the outbound send leg — and it is honest early-access. The composition, the print-ready page, the online edition, and the archive are built; the live delivery is the early-access step, and it defers to the communications arm and to mailing.software for a mailed edition. This page never claims a live send and never paints a fabricated “delivered” state. Early access (live send)
Two-way replies and per-family auto-translate
A family reads an edition in the language it is written in and can translate it with the tools already built into their device or browser — and because every edition is clean, accessible HTML, that translation works well. What is not built yet is a two-way reply lane and per-family auto-translate that picks a language per household. Those are early-access and named plainly, not buried. Early access
A recurring edition, in sections, from contributors
The daily bulletin is a workflow that repeats. Bulletin makes the repeat cheap: an edition inherits the last one’s shape, contributors drop items into sections, and an editor assembles and publishes. The archive keeps every edition that ran.
The day’s items, organised in sections
An edition carries its items in sections a school recognises — schedule changes, club and activity meetings, athletics, the lunch menu, celebrations and recognitions, reminders for families. Sections give the morning read a shape and let a family scan straight to what they need. The section set is the school’s to shape; the edition is the container that holds them for the day.
Contributors add items; an editor assembles
Staff and advisers contribute items into the day’s edition; an editor reviews, orders, and publishes. A minor is never the publisher of record — an adult owns and emits the edition. Contribution is authoring into a shared draft, not a broadcast that anyone can fire; the edition emits once, when the editor publishes it.
Editions inherit; nothing is retyped
A new edition starts from the shape of the last one — the same sections, the school’s template, the standing footer — so the editor fills the day rather than rebuilding the document each morning. The recurring cadence is a first-class feature, not a copy-paste ritual that drifts a little further from the template every week.
The archive is the school’s record
Every edition that runs is filed at its own dated URL and stays readable. The archive answers a real question — what did we announce on that day? — without a search through inbox history. It is the school’s honest record of the bulletin, kept by the engine, not reconstructed from memory.
The publications engine: one production path for everything the school prints
A bulletin is not a special case. It is a publication, and the platform already has a publication engine — the same pipeline and VDP flat-paper rail that produce report cards, newsletters, and yearbook pages. Bulletin points that engine at the daily read.
The same pipeline as report cards and the yearbook
An edition sets through the same publications pipeline and VDP flat-paper rail that generate report cards, newsletters, and yearbook pages. The production path is shared: one engine, one flat-paper rail, one template posture. What changes is the content the editor writes for the day, not the machine that sets it. A bulletin is a publication like any other on the engine.
Print-ready generation is built; the send is not
Setting the composed edition to a print-ready page through the rail is built and runs today — the page for the office board and the morning read is real. The outbound send leg, where a digital edition pushes to an inbox or a printed edition goes into the mail, is early-access. The line between the two is drawn deliberately: generation is available, delivery is named plainly as the next step.
The online edition rides the yearbook read surface
A posted edition opens from a link on any phone, no app to install, on the same read surface the yearbook online edition uses. The read path is separate from the push: a family can always open the online edition and browse the archive at their URLs, whether or not the early-access outbound send has fired. The engine sets the page; the online edition is where it is read.
Accessible by construction, not as a step
Every edition is real, accessible HTML — real headings, real links, required alt text on images — so a screen reader can read it aloud and it stays legible when a parent enlarges the font or reads it on a phone. Names render the way families spell them: diacritics and non-Latin scripts come through intact, not flattened into question marks. Accessibility is a property of the engine, not a checkbox at the end.
Consent and FERPA: a loud daily voice, gated at emit
The bulletin is a public daily voice — that is the point. But a daily read brushes against student-coupled information constantly: a student’s name in a celebration, a photo in a spotlight, an award tied to a person, a team roster in the athletics section. Bulletin treats that boundary as the same FERPA boundary the rest of the platform enforces, not a lighter one because the surface is a quick daily note.
The disclosure check happens at the emit boundary. An item sitting in a draft edition 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 edition 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 published edition. Never public without opt-in.
The audience is roster-scoped and tenant-isolated. An edition is scoped to the families on one school’s imported roster, and tenant isolation at the data layer means an edition for one school is never resolvable against another school’s roster. The daily voice does not become a cross-tenant broadcast; it stays one school’s message to its own community.
And to be plain about the data: this is not a “we hold no data” claim. A bulletin that names a student is data — sensitive minors data. The honest claim is that a student-coupled item is private minors data: consent-gated at emit, kept in our own private system behind the school’s row-level walls, never sold, and never made public without the family’s opt-in. Consent is the family’s to give and to withdraw.
Distribution: the live send leg, named plainly as early-access
An edition, once composed and set, has two honest destinations that are built today: the print-ready page for the office board and the morning-announcements read, and the online edition a family opens from a link. Both are available now. The third destination — the live outbound send that pushes the edition to a family where they are — is honest early-access, and we describe it the same way the mailed-report-card postal send is described on mailing.software.
Be specific about what is early-access. The inbox blast that emails the edition to families, the SMS blast that texts it, and the automated read-aloud call that phones it are the outbound send leg — not shipped, on the roadmap, and deferred to the platform’s communications arm where the managed sending address, the law-required unsubscribe footer, and the emergency-only call scope already live. Until that leg lands and is labelled real, the page shows the composed edition, the print-ready page, and the online edition — never a fabricated “delivered” badge, and never a read receipt no honest sender can promise.
Two more capabilities are early-access on purpose. A two-way reply lane and per-family auto-translate that picks a language per household are not built yet; a family reads the edition in the language it is written in and translates it with the tools on their own device, and we say so rather than implying a per-family translation that is not there. A hollow two-way inbox that did not honour the same consent and do-not-contact rules as the rest of the platform would be worse than none, so we hold the line until it can land honest.
Money is honest-off. There is no pricing, no checkout, and no card is charged on this surface — the product does not process payments. A bulletin is the school’s daily voice, not a storefront. If a paid service is ever offered, it will be a separate, consent-first decision, said plainly. Live send & two-way / translate in early access
Common questions
Can Bulletin publish our daily bulletin today?
Yes. An editor can compose the day’s edition in sections, scope its audience off the roster, clear any student-coupled item through the consent gate, set it to a print-ready page on the publications engine for the office board and the morning read, post an online edition families open from a link, and file it in the running archive. What is not available today is the live outbound send — the inbox blast, the text, the automated read-aloud call. That is honest early-access and the page says so plainly.
How is this different from frontoffice.press?
frontoffice.press is the whole front-office-as-publisher umbrella — announcements, newsletters, the community bulletin, the school press surface. Bulletin narrows to the one recurring daily or weekly bulletin as a first-class publication: its cadence, its dated editions, its running archive, its sections and contributors, and its morning read. They share the same publications engine, roster, and consent substrate. Bulletin cross-links the umbrella; it does not rebuild it.
What makes a bulletin a “publication” here?
Each edition is a first-class dated object — its own date, its own sections, its own contributors, and its own stable URL — set through the same publications pipeline and VDP flat-paper rail that generate report cards, newsletters, and yearbook pages. It is not a single document edited in place until its past is lost; each day’s edition is filed, and the archive keeps the history.
Can families get the bulletin pushed to them — email, text, a call?
That live outbound send is honest early-access. Pushing an edition to inboxes, an SMS blast, or an automated read-aloud call is the delivery leg, and it defers to the platform’s communications arm and to mailing.software for a mailed printed edition. Today the built destinations are the print-ready page and the online edition a family opens from a link. The page never claims a live send and never paints a “delivered” state it cannot stand behind.
How is the audience for an edition decided?
It resolves off the one imported roster and the school’s single-tenant isolation. A school-wide edition, a grade edition, or a single homeroom’s edition is a projection of the roster the office already maintains — not a second list. Tenant isolation at the data layer means an edition scoped to one school is never resolvable against another school’s roster.
What stops a bulletin from exposing a student’s information?
The consent gate at the emit boundary. Any item that would disclose student-coupled information — a name, a photo, an award tied to a student — routes through the consent substrate at the moment the detail would be emitted. A coupled detail without consent on file is not emitted into the published edition, and it is never public without the family’s opt-in. The check is at emit, not in a reviewer’s memory and not in the database.
Is a student’s bulletin data private, or do you claim to hold none?
It is private, and we do not make a “no data” claim. A bulletin that names a student is data — sensitive minors data. The honest posture is that a student-coupled item is consent-gated at emit, kept in our own private system behind the school’s row-level walls, never sold, and never made public without opt-in. Consent is the family’s to give and withdraw.
Do two-way replies or per-family translation work yet?
Not yet, and we name it plainly. A family reads the edition in the language it is written in and can translate it with the tools already on their device or browser; because every edition is clean, accessible HTML, that works well. A two-way reply lane and per-family auto-translate that picks a language per household are early-access, not shipped. We hold the line until they can land on the same consent and do-not-contact rules as the rest of the platform.
Is Bulletin a student information system?
No. Bulletin is SIS-adjacent: the editor reads the imported roster and publishes against it. The school keeps its authoritative enrollment record in whatever SIS it already uses. This surface does not replace the SIS and does not own the authoritative roster; a family that leaves the roster leaves the audience on the next import cycle.
How much does it cost?
There is no pricing on this page. Money is honest-off — no checkout, no card charged — and the product does not process payments. A bulletin is the school’s daily voice, not a storefront. The honest next step is to book a conversation about what your office needs, not to check out.
Related surfaces
Bulletin connects to the rest of the platform through the shared publications engine, the shared roster, and the shared consent substrate. These destinations cover the adjacent surfaces.
frontoffice.press
The whole front-office-as-publisher umbrella — announcements, newsletters, and the community bulletin under one publishing roof. The recurring daily bulletin is one publication under that umbrella; this page is its full home, and the two share the engine, the roster, and the consent substrate.
yearbook.press
The publications surface the engine is shared with. A bulletin edition and a yearbook page set through the same publications pipeline and VDP flat-paper rail; the online edition rides the same read surface.
mailing.software
The school print-and-mail operations home. A mailed printed edition routes through here for the postal-send leg, which is honest early-access — the same posture the live send carries on this page.
schoolsoftware.app
The plain-language K–12 module catalog front door, where an administrator scans every built school-software module with honest per-module status. The daily bulletin is one line item there; this page is its full home.
homeroom.software
The flagship platform brand home: the full product story and the complete picture of the publications engine, the shared roster, and the consent substrate that Bulletin builds on.
What this page is and is not claiming
The recurring bulletin engine — composing a dated edition in sections and setting it to a print-ready page through the same publications pipeline and VDP flat-paper rail that generate report cards, newsletters, and yearbook pages — is built and running today. The dated editions and the running archive, the online edition that opens on any phone from a link, the roster-scoped audience with single-tenant isolation, and the consent-gated disclosure boundary that checks any student-coupled item at the emit call are built and running today. The live outbound send — the inbox blast, the SMS, the automated read-aloud call, and a mailed printed edition through mailing.software — is honest early-access, deferred to the communications arm, and the page never renders a fabricated “delivered” state or a read receipt. Two-way replies and per-family auto-translate are early-access too, named plainly. A student-coupled item is private minors data — consent-gated at emit, kept behind the school’s walls, never sold, and never public without opt-in — not a claim that no data exists. The editor reads the imported roster; this surface is SIS-adjacent and does not own the authoritative record. There are no invented stats, testimonials, or user counts on this page, and no competitor brand names. Money is honest-off: no pricing, no checkout, and the product does not process payments. The honest next step is to book a conversation.