Mailing Software · school physical-mail operations
Report cards, notices, and household letters by postal mail — the print-and-mail side of school communication.
Schools send paper. Report cards, absence notices, progress letters, and district-wide household mailings all require an address, a merge, a print run, and a stamp. Today that work is usually a spreadsheet export, a mail-merge template the office staff maintain manually, and an envelope-stuffing session in the copy room. This platform is designing the print-and-mail lane on top of the same guardian-authority and consent governance the roster already holds — so the same directory that drives picture day and family communication also governs who a postal run reaches. The pipeline is researched and in early access; this page says exactly what is built, what is designed-but-not-wired, and what is on the roadmap.
The guardian-authority graph and the consent-lane model on the shared roster — who holds authority over a student, and which communication purposes a guardian has opted into — are built and running. The household mailing-address substrate, the mail-merge surface, the print-and-mail dispatch pipeline, and household mailing campaigns are researched and planned, not yet built. No live mailing is wired today; this page says so plainly rather than presenting in-progress work as finished.
Physical mail — not electronic email
This is the postal-mail lane: paper that goes into an envelope, gets a stamp, and travels to a household by post. It covers report cards sent home by first-class mail, absence and tardy notices mailed to a guardian address, district-wide household letters, and the mailing-campaign side of school communication where a physical piece lands in a family’s mailbox.
It is not the electronic email lane. Electronic mailboxes, digital message delivery, and email-based family communication belong to emailing.software — the sibling domain whose job is the digital channel. The two share one household address record underneath; they do not overlap in what they send or how.
The distinction is structural. A school secretary who clicks “send” on a report card through this platform is authorizing a print run and a postal drop, not an email blast. The two channels live on separate surfaces by design so the school can manage them, audit them, and govern them independently.
What is built today
The mailing lane is designed to sit on the roster’s recipient-governance substrate — who has authority to receive what, and what a guardian has consented to. That governance layer is built and running. The household mailing-address substrate the print-and-mail pipeline itself would read from is researched and planned, not yet built:
Guardian-authority graph
Each guardian-of-record carries an authority kind — custodial, court-granted, foster, or self — with a court effect and a valid-from/valid-until window, as a first-class edge on the student’s contact record rather than a flat yes/no flag. A district that must honor a custody order or an expiring foster placement has a real field to check, not a note in a spreadsheet. Substrate built
Consent-lane model
A guardian’s communication consent is tracked per purpose, not as one blanket flag: general family communication and life-safety emergency notification are separate opt-ins. A guardian who opted out of routine mailings is not thereby excluded from an emergency notice, and the reverse never happens by accident. This purpose-scoped consent model is built and is what a mailing recipient list would be governed by. Substrate built
Household mailing-address substrate
A physical print-and-mail run needs a street/city/state/zip mailing address for each household, deduplicated so a household with two students in the same school receives one piece, not two. That address substrate does not exist in the platform’s data model today — student contact records carry email and phone, not a postal address, and there is no household record. Building it is the first step of the print-and-mail pipeline. Researched — planned
FERPA-aware data posture (researched)
A school that sends a report card by mail to a household is disclosing an education record — specifically a student’s academic performance — to a household address under the FERPA school-official exception or the parental-disclosure right. The platform’s data posture for the print-and-mail lane has been researched with this framing: the household address is disclosed only to a postal carrier and a printing vendor acting as school officials, under a written agreement that restricts their use. The research is done; the integration that enforces it in a live vendor agreement is part of the early-access build. Researched — early access
How the print-and-mail pipeline is designed to work
This is the researched design for the pipeline — the architecture the early-access build is implementing. It is not a description of a live system. It is published here so a school administrator or district coordinator evaluating this platform can understand what the approach will be and why the design choices were made.
- The address pull. When a mailing run is initiated — for a report-card batch, a notice, or a household campaign — the platform pulls the household mailing address for each student in scope from the shared roster. Households are deduplicated at pull time: if three students at the same address are in scope, one address record is included, not three. The scope is defined by the operator: a single classroom, a grade, a school, or the full district.
- Mail-merge field shaping. The content of the mail piece can include merged fields from the student or household record: the student name, grade, homeroom, or any other field the school has elected to include. The merge runs against the same canonical record the gradebook and the directory use. No separate CSV export, no manual field mapping in a desktop application. The merge template is authored in the platform; the fields are drawn from the live record at run time.
- Print-and-mail vendor handoff. The merged, addressed print run is handed to a print-and-mail vendor pipeline: a service that accepts a print-ready PDF and an addressed recipient list, prints the piece, and drops it with the postal carrier. The vendor operates under a written agreement that restricts their use of the address data to fulfilling the specific print run — the FERPA-aware posture researched for this lane. The vendor receives the minimum data required: the name, the address, and the print content for each household in the run. No student ID numbers, no academic record beyond what appears in the printed piece itself, and no retention beyond the fulfillment window.
- Dispatch confirmation and audit log. When the vendor confirms a run as accepted, the platform logs the confirmation against the mailing event: which records were included, which template was used, and when the confirmation was received. The audit log gives the school a record of every postal mailing it has authorized through the platform, with enough detail to respond to a guardian who asks when a report card was mailed and to which address.
- Address update handling. If a guardian updates their household address after a mailing run has been queued but before it is dispatched, the platform surfaces the update to the authorized operator before confirming dispatch. A mailing that was queued to an address that has since changed does not dispatch silently to the old address; the updated record takes precedence and the operator is notified.
What is in early access and what is planned
These are not presented as available today. The guardian-authority and consent governance the mailing lane is designed to sit on is built; the household mailing-address substrate and the mailing pipeline on top of it are researched and planned, not wired. These items are named so a school or district evaluating this platform can see the honest build trajectory.
Mail-merge surface for report cards and notices
The operator-facing surface where a school administrator selects a template, chooses the student scope, previews the merged output, and queues a print run. The recipient-governance layer it will target -- guardian authority and consent -- is built; the household mailing-address substrate and the merge surface itself are planned and in active design. This is the primary early-access item for the print-and-mail lane. Early access
Print-and-mail vendor pipeline integration
The integration with a print-and-mail vendor that accepts a print-ready PDF and an addressed recipient list, prints the piece, and drops it with the postal carrier. The vendor selection, the data agreement, and the API handoff are researched and designed. The live wiring is the build item that makes the pipeline operational. No live mailing dispatch exists today. Early access — researched, not wired
Dispatch confirmation and mailing audit log
The audit record for each mailing run: which household records were included, which template was used, the dispatch confirmation from the vendor, and the timestamp. The data model for the audit log is designed; the persistence layer that records it is part of the pipeline build. Early access
Address update notification before dispatch
The workflow that surfaces a household address change to an operator when an address update arrives after a run has been queued but before it is dispatched. Prevents a report card from going to a stale address silently. Part of the early-access pipeline build. Early access
Household mailing campaigns
The campaign layer on top of the print-and-mail pipeline: a school or district runs a targeted household mailing to a defined scope — all households in a grade, all households at a school, a district-wide notice — with a consistent template and a single authorized dispatch. Planned on the same roster spine and pipeline as the report-card lane. Planned
Return-address management
Storing and selecting the school or district return address that appears on each outbound piece, with per-school overrides for a district-wide mailing. A district-run report-card mailing from ten schools uses the correct return address for each school’s piece, not a generic district address. Planned as a configuration item in the pipeline. Planned
The FERPA posture for physical mail
Sending a report card or academic notice to a household is a disclosure of an education record. The Family Educational Rights and Privacy Act governs that disclosure. A school that uses this platform to conduct a postal mailing is making a decision to share student information with a print-and-mail vendor and, ultimately, with the household at the other end of the delivery.
The platform’s researched posture for this lane treats the print-and-mail vendor as a contractor operating under the school-official exception: a party acting for the school under a written agreement that limits the vendor’s use of student data to fulfilling the specific print run, prohibits re-use or retention beyond the fulfillment window, and requires the vendor to maintain appropriate safeguards. This is the standard posture for service providers handling education records under contract — the same framework a school uses when it contracts with a photo lab, a printing vendor, or a document storage service.
What the vendor receives is the minimum data required to print and address the piece: the household name, the mailing address, and the content of the printed piece. If the content includes a student’s name and grade — as a report card envelope or a mailing label would — that data travels to the vendor. If the content is a generic notice that does not include the student’s name, only the address travels to the vendor. The operator controls what the template contains.
The FERPA analysis for this design is researched and documented. It is not a legal opinion and it is not advice specific to any school district. A school’s own legal counsel should review the data-sharing arrangement before a live mailing run is authorized. This is the platform’s researched framing; it is the basis for the design; the live vendor data agreement that enforces it has not been executed because the live pipeline is not yet built.
Who this is for
The mailing lane is primarily a tool for a school secretary, an office manager, or a district communications coordinator: the person who is responsible for getting paper out the door to household addresses. That person today is usually working from a data export, a word-processor mail merge, a printer in the copy room, and a stack of envelopes. The goal of this platform is to replace that workflow with a single authorized action from the roster that already exists.
For a building principal or assistant principal, the mailing lane is an audit tool as much as a send tool: a record of what was mailed, when, and to which addresses. A guardian who calls the office to ask whether their report card was sent can get a confirmed answer from the audit log — not a best guess from whoever was working the copier that afternoon.
For a district coordinator managing household mailings across multiple schools, the campaign layer (on the roadmap) will provide a single surface to authorize a district-wide run, review the scope and address list, and track dispatch confirmation by school. The household deduplication that runs at the roster level means a district notice to all households does not double-mail to a household that has students at two different schools in the district.
This surface is not the right tool for a parent or guardian. Guardians receive the physical mail at their household address; they manage their address record and their consent preferences through parentsoftware.app, the family-facing side of the platform. A guardian who wants to confirm or update the address the school holds for them does it there, not here.
Common questions
Is this the same as the electronic email tool?
No. This platform handles physical postal mail: printed pieces that go into envelopes and travel to household addresses by post. Electronic email — digital messages, mailboxes, and email delivery — is the job of emailing.software, the sibling domain. The two share the household address record underneath; they do not overlap in what they send.
Can we send a report card through this platform today?
Not yet. The guardian-authority and consent governance the mailing lane will use to target recipients is built; the household mailing-address substrate is researched and planned, and the pipeline, mail-merge surface, and print-and-mail vendor integration are in early access — meaning they are being designed and built, not live. No mailing dispatch is wired today. This page says so plainly rather than describing early work as available.
Does sending a report card by mail through this platform comply with FERPA?
The platform’s researched posture treats the print-and-mail vendor as a contractor under the school-official exception, operating under a written agreement that limits their use of student data to fulfilling the specific print run. That is the standard framework for service providers handling education records under contract. The platform’s legal team has researched and documented the approach; a school should have its own legal counsel review the data-sharing arrangement before authorizing a live run. This is the design basis; it is not legal advice.
How does the platform know which address to use for each household?
The household address record lives in the shared roster the platform already maintains. A guardian who updates their address through the family portal updates the same record the mailing lane reads from — there is no second address field to keep in sync. When a mailing run is initiated, the platform pulls the current mailing address for each household in scope. If an address changes after a run is queued but before it is dispatched, the platform surfaces the update to the authorized operator before confirming dispatch.
What happens if two students at the same address are both in the mailing scope?
The household deduplication in the roster data model handles this. A household that has two students in scope receives one piece of mail at the address, not two. The deduplication runs at the address-pull step, not as a manual cleanup after export. For a report-card mailing where each piece is specific to one student, the operator can configure per-student pieces with per-student content while still sending one envelope to a shared address — that configuration is part of the early-access build.
Does the print-and-mail vendor see student records?
The vendor receives the minimum data required to fulfill the print run: the household name, the mailing address, and the content of the printed piece. If the printed piece includes a student name and grade — as a report-card mailer would — that data is in the content handed to the vendor. If the piece is a generic notice without student-identifying content, only the address travels to the vendor. The vendor operates under a written agreement that restricts their use to fulfilling the specific run. The live vendor agreement has not been executed because the live pipeline is not yet built; this is the researched design that will govern it.
Can we use this for a district-wide mailing to all households?
That is the planned household mailing campaign feature: a single authorized dispatch to all households at a school or across a district, with a consistent template and a defined scope. The household deduplication that runs at the roster level means a district notice to all households does not double-mail to a household with students at two different schools. The campaign layer is planned on the roadmap; it is not available today.
What does “early access” mean here?
It means the feature is designed and being built — the architecture is documented and active development is under way — but it is not yet wired to a live dispatch. “Early access” is a precise status on this platform: it is not a marketing term for “coming soon”; it means the foundational work is done and the surface on top of it is in active completion. The print-and-mail dispatch is early access in this sense: the recipient-governance substrate it will target (guardian authority and consent) is built; the household mailing-address substrate, the merge surface, and the vendor pipeline are researched and being designed on top of it.
Related tools and surfaces
emailing.software
The electronic email side: digital mailboxes, email delivery, and message-based family communication. This is the sibling this platform is not — the two share a household address record and serve separate channels.
homeroom.software
The K-12 platform whose shared roster and household records the mailing operations read from. Student records, family communication, yearbook, picture day, and school management on one shared data model.
parentsoftware.app
The family-facing portal where guardians manage their household address, consent preferences, and their connection to the school record. Guardians who want to confirm or update their mailing address do it here.
Student Records
The official student and household record the whole platform reads from: roster, guardians, household addresses, terms, and the single-school FERPA privacy wall that the mailing lane inherits.
What is built and what is honest-off
The guardian-authority graph and the purpose-scoped consent-lane model on the shared roster are built and running as part of the platform’s shared data model — the recipient-governance layer the mailing lane is designed to sit on. The household mailing-address substrate, the household deduplication it would need, and the guardian-to-household address link are researched and planned, not yet built. The FERPA-aware data posture for the print-and-mail lane is researched and documented; it is the design basis for the vendor agreement that will govern a live mailing run. The mail-merge surface, the print-and-mail vendor pipeline integration, the dispatch confirmation audit log, and the address-update notification before dispatch are early access — in active design on top of the built governance substrate, not yet live. Household mailing campaigns and return-address management are planned. No live mailing dispatch is wired today and this page says so plainly.
This platform does not handle electronic email. The emailing.software domain is the correct destination for electronic mailboxes and digital message delivery. The distinction is structural, not cosmetic: physical mail and digital messages are separate channels, governed by different workflows, different compliance questions, and different vendor relationships.
Mailing Software is the postal-mail operations layer of the Homeroom K-12 platform — report cards, notices, and household letters by post, built on the same shared household record the rest of the platform uses.