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. The guardian-authority and consent governance the roster already holds is the substrate a postal run would read from — the same directory that drives picture day and family communication. No print-and-mail lane exists in this platform: there is no household record and no postal-address field in the data model, and no print-and-mail vendor is integrated. This page is a published design. It says which parts are built and which parts are documents.
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 do not exist in this platform. No mailing is dispatched by this platform and no code path that could dispatch one exists. This page is a published design, not a product description.
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 does not exist in the platform’s data model:
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, and it is not built. Not built — design only
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 a document. No vendor agreement is executed and no vendor integration exists in this platform. Not built — design only
How the print-and-mail pipeline is designed to work
This is a published design document for the pipeline. Nothing described below is implemented in this platform, and none of it is 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 built and what is only a design
None of the items below is available. 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 documents, not code. They are named here so a school or district evaluating this platform can see exactly where the line between built and designed falls.
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 would target -- guardian authority and consent -- is built; the household mailing-address substrate and the merge surface itself are not. Neither a household record nor a postal-address field is present in the data model, and no such operator surface exists. Not built
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 described in a design document. No vendor client, no executed data agreement and no dispatch path exist in this platform. Not built — design only
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. No persistence layer records it, because no mailing run can be created in this platform. Not built
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. It is designed to prevent a report card going to a stale address silently. No address record exists to change and no run can be queued, so nothing performs this check today. Not built
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. Neither the roster-spine change it needs nor the pipeline it would sit on exists. Not built
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. No pipeline exists to configure. Not built
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 and it is the basis for the design. No vendor data agreement is executed, because there is no pipeline for one to govern.
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 designed campaign layer is a single surface to authorize a district-wide run, review the scope and address list, and track dispatch confirmation by school, and the roster-level household deduplication it depends on would keep a district notice from double-mailing a household with students at two schools. None of it is built: there is no household record in the data model and no campaign surface in this platform.
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 split is structural and neither sends the other’s traffic. The shared household address record the two lanes are designed around is not built in either of them today.
Can we send a report card through this platform today?
No. The guardian-authority and consent governance the mailing lane is designed to target recipients with is built. The household mailing-address substrate is not: there is no household record and no postal-address field in the data model. There is no mail-merge surface, no print-and-mail vendor integration and no dispatch path in this platform. Nothing on this page can send a report card, and there is no switch that would turn one on.
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?
It does not, because it holds no address. The design places the household address record in the shared roster the platform already maintains, so that a guardian updating their address through the family portal would update the same record the mailing lane reads from, with no second field to keep in sync. That record is not in the data model today — contact records carry email and phone, not a postal address — so there is nothing to pull and no run to pull it for.
What happens if two students at the same address are both in the mailing scope?
Nothing happens, because no mailing scope can be built today. The design answers it with household deduplication in the roster data model, at the address-pull step rather than as a manual cleanup after export, so a household with two students in scope would receive one piece and not two; for a report-card mailing whose pieces are per-student, an operator would be able to keep per-student content inside one envelope to a shared address. There is no household record in the data model, so nothing deduplicates.
Does the print-and-mail vendor see student records?
No vendor sees anything, because no print-and-mail vendor is integrated with this platform. The design gives a vendor the minimum data required to fulfill a 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 design requires a written agreement restricting the vendor’s use to fulfilling the specific run. No such agreement is executed and no data leaves this platform for a printer.
Can we use this for a district-wide mailing to all households?
Not through this platform. The designed household mailing campaign is a single authorized dispatch to all households at a school or across a district, with a consistent template and a defined scope, and the roster-level household deduplication it depends on would keep a district notice from double-mailing a household with students at two schools. Neither the campaign layer nor the household record it depends on exists here.
What do “built” and “a design” mean on this page?
“Built” means the thing exists in the platform’s code and data model and runs: the guardian-authority graph and the purpose-scoped consent lanes on the shared roster are built in that sense. “A design” means a written document and nothing else — no schema, no code, no switch. The household mailing-address substrate, the mail-merge surface, the print-and-mail vendor integration and the campaign layer are designs. This page uses no status word that points at a future date, because a date is not a thing it can measure; it states only what is true of the platform today.
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 not built: no household record and no postal-address field exist in the data model. The FERPA-aware data posture for the print-and-mail lane is researched and documented; it is the design basis for a vendor agreement, and no such agreement is executed. The mail-merge surface, the print-and-mail vendor pipeline integration, the dispatch confirmation audit log, the address-update notification before dispatch, household mailing campaigns and return-address management are designs and nothing more — documents written against the built governance substrate. No mailing dispatch exists in this platform and there is no switch that would create one.
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.