Yearbook Press · Advisers & student staff · Free for schools · 2026

From roster to press-ready PDF — the production editor for school yearbooks that have to be right the first time

Yearbook Press is the production platform for school advisers and student editors who build the book properly. A multi-surface editor with layers, masking, and version history. Roster-driven portrait placement matched by roster and filename — not by comparing faces — with a consent gate that withholds non-consented students automatically. An adviser proof-approval workflow that is fail-closed — no spread reaches the press-ready export until the adviser approves it. An automated pre-flight that flags the problem before the file goes to the lab, not after. Free for the school. No per-student fee, no annual contract to start.

Start your book How it works

Press-ready outputautomated pre-flight check — flags the problem before the file goes to the lab

Fail-closed approvalno spread reaches the export until the adviser approves it, enforced at the engine

No per-student feefree for the school — families who want a printed copy pay for it

Consent-gated portraitsnon-consented students withheld from shared spreads — automatically, at the data layer

The production editor — not a consumer photo-book wizard

The book is built on a production surface — it does not need to be adjusted to survive a consumer export

A consumer photo-book service is designed for a family making a holiday album: a wizard of template choices, a drag-and-drop interface, and an order button at the end. That design is wrong for a school yearbook with several hundred portrait entries, a student staff of 20, an adviser who must approve every spread before it ships, a consent requirement for every student’s portrait, and a press-ready file that a commercial lab can print on schedule. Those are editorial production problems, not photo-book problems.

The Yearbook Press editor is a full layout surface: layers with independent opacity and blend, object masking, spread-level undo, and a version history that lets an adviser roll back to any saved state. Typography controls go to the spread level, not a global template setting. The multi-surface model handles the yearbook, the newspaper, the literary magazine, and the memory book on the same editor the staff already knows — one platform, not four licensed tools.

The production editor is built and live. The platform is free for the school — no per-student fee, no annual contract to start. Families who want a printed copy pay for it; the charge rail for those orders is honest-off today.

Start your book Full platform

How it works

The yearbook year in four stages

Yearbook Press runs on the production calendar: roster and template setup before the first spread, content build and photography through the year, adviser review and proof-approval, and then press-ready export and delivery. Every stage is described as it is built today.

Step 1 · Pre-production — roster import, staff roles, and template foundation

The adviser imports the school roster at the start of the year and assigns sections: seniors, juniors, clubs, sports, faculty, and the index. Staff editors are assigned roles — section editor, photo editor, copy editor — with access scoped to their section so a student editor cannot touch sections outside their assignment. A template foundation — grid, type style, and colour palette — establishes the book’s visual language before a single spread is laid out. Portrait slots populate from the roster: the section editor sees a grid of unfilled portrait positions that correspond to every name on the roster. Pre-production is where coverage gaps and consent gaps are identified, not at the proof stage.

Step 2 · Content build — spreads, photography, and portrait placement

The student staff builds the book on the production editor: laying out spreads, placing photography from picture day and candid coverage, writing captions, and dropping portraits into the roster-matched grid. Photo editors work from the platform’s photo library, which holds picture-day portraits and candid uploads in the same place — no external file-sharing folder required. The editor’s version history means a spread can be revised without losing the previous layout: the adviser can roll back to any saved state. A student working on the athletics section cannot overwrite the adviser’s locked senior section. Coverage tracking shows which clubs, teams, and staff are represented and which are not yet on any spread.

Step 3 · Adviser review — proof-approval and version locking

The adviser works through the proof-approval queue: each spread is reviewed in the production editor, not as a flat PDF. Spread-level comments attach to specific objects — a wrong portrait name, an out-of-focus candid, a caption that names a non-consented student. A commented spread returns to the section editor; a corrected spread returns to the adviser’s queue as a new version. When the adviser approves a spread, it locks. The approval gate is fail-closed: no spread reaches the press-ready export until every spread in the book carries the adviser’s approval. Version history preserves the approved state alongside any re-opens. The adviser’s approval is the editorial record.

Step 4 · Press and delivery — export, lab submission, and delivery tracking

When every spread is approved, the press-ready PDF export runs the automated pre-flight check: resolution, margins, fonts, and colour space. Any pre-flight failure is flagged with the specific spread and object before the export completes. The final PDF includes printer marks and ICC profile embed. The school submits the PDF to whichever print lab it uses — the platform places no restriction on that choice. The delivery tracking engine logs proof shipment and print-run fulfillment. Digital distribution of the finished book is included for every student regardless of whether their family orders a printed copy. Families who want a printed copy order one through the platform; the charge rail for those orders is honest-off today.

The full platform

Five engines — honest about what is built and what is coming

Every feature is labelled honestly: Built means the underlying engine is production-ready and live. In development means the surface or payment integration is in active build. We do not claim otherwise.

The production editor — layers, masking, version history, and multi-surface on one canvas

The yearbook editor is a full layout surface: layers with independent opacity and blend, object masking, spread-level undo, and a version history that lets an adviser roll back to any saved state without losing work done after that point. A student editor can work on the senior section while an adviser reviews the faculty pages on the same book, on the same canvas, with neither overwriting the other’s work. Typography controls include custom headline styles, caption sizing, and column count per spread — not a preset template that forces a student staff into one of three font choices. The multi-surface model means the same editor handles the yearbook spread, the newspaper layout, the literary magazine folio, and the class memory book, so a school does not license four separate tools. The production editor is built and production-ready.

Production editor built · live

Roster-driven portrait placement — every student on the page, no name left off

Portrait placement starts with a roster import, not a pile of image files. The roster establishes who belongs on each section of the book and in what sequence — alphabetical by homeroom, by grade, by teacher, or in a custom sort the adviser controls. Photos from picture day are matched to roster entries by the naming convention from the picture-day shoot — a filename/roster match, not a face comparison — no manual drag-and-drop sorting through hundreds of headshots. An unmatched roster entry flags as a gap on the spread so the adviser sees it before proofing, not after the book ships. A student whose family has not consented to publication is withheld from shared spreads automatically — consent is enforced at the data layer, not left to manual exclusion. Portrait flow is not a feature in a consumer book-builder; it is an editorial production tool built for schools that run a real namecheck. The roster-driven portrait flow is built and production-ready. Portraits are matched by roster and filename, not by comparing faces; facial recognition is off by default and is never part of the portrait-matching pipeline.

Portrait flow built · consent-gated · matched by roster + filename · live

Adviser proof-approval — spread-level review, version locking, and no corrections discovered at press

The proof-approval workflow puts the adviser at the gate before any spread is marked ready. Spread-level comments let an adviser mark a caption wrong, a headline too large, or a portrait name incorrect — each comment is attached to the specific object on the spread, not to a flat PDF annotation nobody sees until the file is already submitted to the lab. When an adviser approves a spread, that version is locked: student editors can work on other spreads, but a locked spread cannot be changed without the adviser re-opening it. The approval gate is fail-closed: a spread that has not been approved by the designated adviser account cannot move to the press-ready export stage. This is enforced at the engine, not by a checklist email. Version history preserves every locked state alongside any subsequent re-opens. The proof-approval workflow is built and production-ready.

Proof-approval built · fail-closed · live

Press-ready PDF export — the automated pre-flight check and the final deliverable

The press-ready PDF export runs an automated pre-flight check on the book before producing the output file: image resolution at the required PPI for the target trim size, bleed and safety margins on every spread, embedded fonts, and colour-space consistency across all placed images. A spread that fails a pre-flight check is flagged with the specific issue — a low-resolution photo on page 14, a text box running past the safety margin on page 22 — so the student can correct it rather than receiving a reject from the print lab. The final export includes printer marks, ICC profile embed, and per-spread PDF pages in the format major commercial book labs accept. The PDF is the deliverable: the school takes it to whichever print lab it uses. The press-ready PDF export and automated pre-flight are built and production-ready.

Press-PDF export built · automated pre-flight built · live

Delivery tracking and print-anywhere freedom — the school keeps its own print lab relationship

The delivery tracking engine logs proof status, print-order status, and fulfillment events in a single timeline the adviser can check without calling the lab. When a proof copy ships, the tracking record updates. When the print run ships, quantity and destination are recorded against the order. The school is free to choose its own print lab and submit the press-ready PDF directly: the platform does not require purchasing printing through any single vendor. Printed-copy revenue is the model: families who want a physical book pay for it, and a share stays with the school. The charge rail for print orders is honest-off — present in the platform, not enabled for live print-order transactions today. The delivery tracking engine is built and production-ready. Print-order checkout is honest-off.

Delivery tracking built · print-order checkout honest-off

Who uses it

Built for the adviser and the student staff — different roles, one surface, one approval chain

Yearbook advisers

The adviser’s role is editorial control: approving spreads, catching errors before they print, enforcing the consent gate, and keeping the student staff on the production calendar. The proof-approval queue puts every spread in front of the adviser before it moves. Spread-level comments let the adviser mark a specific object wrong — a wrong caption, an out-of-focus photo, a portrait name error — without a separate annotation tool. The approval gate is fail-closed: no spread reaches the press-ready export without adviser approval, enforced at the data layer, not by a reminder checklist. Version history preserves every approved state so the adviser can see what changed after a re-open.

Student editors and section staff

The student editor works on a scoped canvas: their section, their spreads, within the template foundation the adviser established. The production editor gives students real layout tools: layers, masking, typography controls, and a photo library that holds picture-day portraits and candid uploads in the same place. Version history means a misstep is recoverable: the previous spread is always there. Coverage tracking shows which clubs, teams, and staff are on a spread and which are not yet covered. The photo editor works from the same library as the section editor; no external shared folder or separate photo-management tool is required.

Student photographers

Candid photography feeds directly into the platform’s photo library, alongside the picture-day portraits. A student photographer uploads from the event; the section editor sees the photos immediately, tagged by event and date, ready to place on the relevant spread. No external folder, no email attachment, no “did you get my photos” message. The photo library is the single source: portrait and candid, indexed and searchable by the staff.

Portrait placement and consent — every name on the page, the right way

Roster-driven, consent-enforced, matched by name not by face — the portrait namecheck that runs before proofing, not after

The portrait section of the yearbook is a namecheck. Every student on the roster belongs on a spread in the right sequence, with their name matched to their photo. A consumer tool treats portraits as images to be placed. Yearbook Press treats them as roster entries that generate portrait slots — each slot corresponds to a name, a class, a section, and a consent record. An unmatched entry shows as a gap on the spread so the adviser sees it before proofing, not after the book ships.

Portraits are matched to roster entries by filename, not by comparing faces; facial recognition is off by default and is never used to place a portrait. Photos are matched to roster entries by the naming convention from the picture-day shoot — a convention the school controls and the adviser verifies. A student whose family has not consented to publication is withheld from shared spreads automatically, enforced at the data layer: not a manual exclusion list, not a reminder to check before export. Consent is opt-in, revocable, and recorded. Student portraits are access-controlled: they are never public and never sold.

The portrait flow and consent gate are built and production-ready. For schools running picture day through the connected platform, the same consent record that gates the family’s picture-day access also gates whether the portrait appears in the yearbook — one opt-in, enforced in both places. Schools not running picture day through the connected platform can import the portrait files and the consent list from their existing process.

What is built and what is coming — plainly

The production engine is built. The print-order checkout is not live yet.

Built and production-ready today: the multi-surface production editor (layers, masking, version history, typography controls, multi-surface model); the roster-driven portrait flow (import, match, sequence, consent gate, no face scan); the adviser proof-approval workflow (spread-level comments, version locking, fail-closed approval gate); the press-ready PDF export with automated pre-flight check (resolution, margins, fonts, colour space, printer marks, ICC profile); the delivery tracking engine (proof status, print-run status, fulfillment log).

Not yet enabled for live use: the charge rail that processes a family’s print order, the live print-order checkout interface, and the revenue-share payout engine. These are honest-off — present in the platform, not enabled for live transactions. There is no live checkout here. No billing. No subscription. We say so directly because advisers and school offices deserve to know what is production-ready and what is still being wired.

Connected to the school platform

The yearbook covers every student. Seen puts every student’s recognition on the page. Assembly captures the moments the yearbook archives.

Seen is the recognition layer: the programme that ensures every student athlete, performer, and academic achiever lands on a real named page in the yearbook — adviser-approved, consent-verified, driven by the school’s own roster and activity records. The yearbook’s coverage gap problem and Seen’s recognition gap problem are the same problem. Assembly is the moment layer: live school events captured, ticketed, and archived. The moments the yearbook covers — the game, the performance, the ceremony — are the moments Assembly records; wiring them together is the natural connection. Yearbook Ad Network is the ad sales platform: local businesses and families buying ad pages in the book, giving the adviser a revenue line that does not depend on selling subscriptions.

seen.school assembly.school yearbookad.network homeroom.software

Start your book · Yearbook advisers and student editors

Book a conversation to see the current state — or start the book now

Yearbook Press is in active development. In a demo we walk through the current state honestly: the production editor on a real spread, how roster-driven portrait placement fills a senior section from an import, how the proof-approval queue works from submission to lock, and how the automated pre-flight flags a resolution issue before the PDF is produced. There is no pricing commitment, no signup, and no live payment. If it looks right for your school year, we discuss what starting looks like.

To start or to book: email [email protected].

FAQ

Common questions

What does “multi-surface editor” mean?

The same production editor handles the yearbook, the school newspaper layout, the literary magazine, and the class memory book — not as separate products, but as surfaces inside the same editor the adviser and student staff already know. A school does not license four separate tools. Each surface has its own grid and type conventions; they share the same photo library, the same roster, and the same proof-approval workflow. For schools that produce more than a yearbook, multi-surface is the reason to consolidate onto one publishing platform.

Is the platform really free for schools?

The platform is free to the school: no per-student fee, no annual contract required to start the book. The model is straightforward — the digital yearbook is included for every student whose family opts in; families who want a printed copy pay for it, and a share of that revenue stays with the school. The charge rail for print orders is honest-off today — present in the platform, not enabled for live transactions. There is no subscription and no pricing commitment in this conversation. The CTA here is “start your book” or “book a conversation,” not “pay now.”

How does the proof-approval flow work in practice?

The adviser works through a queue of spreads submitted by the student section editors. Each spread is reviewed in the production editor, not as a flat PDF. The adviser can comment on a specific object on the spread — a wrong portrait name, a caption that runs too long, a photo that should be replaced — and return it to the student. The student sees the comment attached to the object, corrects it, and re-submits. When the adviser approves a spread, it locks: no student editor can change it without the adviser re-opening it. The approval gate is fail-closed: the press-ready export cannot run until every spread in the book has an approval. The adviser’s name and timestamp are recorded on every approval action.

Can we use our own print lab?

Yes. The platform exports a press-ready PDF with printer marks and ICC profile embed that major commercial book labs accept. The school submits the PDF to whichever lab it uses. The platform does not require purchasing printing through any specific vendor. The delivery tracking engine logs fulfillment events from the lab; the detail it receives depends on what the lab provides. Print-anywhere is not a marketing phrase — it is what the file format means: your PDF, your lab, your timeline.

How does roster-driven portrait placement work?

The adviser imports the roster at the start of the year — a CSV or a direct import from the school’s student information system. The portrait section of the book is built from the roster: every name generates a portrait slot in the sequence the adviser sets (alphabetical by grade, by homeroom, by teacher, or a custom sort). Photos from picture day are matched to roster entries by the naming convention from the picture-day shoot — no face scan, no manual sort through hundreds of headshots. An unmatched entry shows as an empty slot on the spread so the adviser can see the gap before proofing, not after the book ships. A student whose family has not consented to publication is withheld from the shared spread automatically, enforced at the data layer.

What does “press-ready PDF” mean in practice?

A press-ready PDF is the file a commercial book lab expects: the correct trim size with bleed and safety margins on every spread, image resolution at the PPI the lab requires for the print size, embedded fonts, and an ICC colour profile that tells the printer how to reproduce the colours in the file. The platform’s automated pre-flight check runs those tests before the export completes and flags any issue with the specific spread and the specific object — not a generic “file failed,” but “the photo on page 14 is 72 PPI and requires 300 PPI at this trim size.” The student corrects the issue, the pre-flight passes, and the PDF is produced. The school submits that file to the lab.

How does version history work? Can we roll back?

Every save to the production editor creates a version record. The adviser can view the history of any spread, compare two versions side by side, and restore any previous version as the current working state — without losing the versions in between. If a student overwrites a spread that was close to approval, the adviser rolls back to the version before the change. If an approved spread needs a correction after it was locked, the adviser re-opens it (creating a new version record), the student applies the correction, and the spread returns to the approval queue as a new version. The prior approved version is preserved alongside it.

What is the delivery tracking engine?

The delivery tracking engine records proof and print-run events in a single timeline: when the proof copy shipped, when it was marked received, when the print run was submitted to the lab, and when the lab confirmed shipment. The adviser sees the status without calling the lab. The tracking engine logs fulfillment data that the lab provides — not all labs provide the same level of event detail, but the engine records what it receives. The charge rail that processes a family’s printed-copy order is honest-off today: present in the platform, not enabled for live transactions.

Who has final approval on the book?

The designated adviser account. The approval gate is fail-closed at the data layer: the press-ready export cannot run until every spread in the book carries an approval from the adviser account for that section. An adviser can assign section editors and photo editors with scoped access, but the approval authority stays with the adviser account. If a school uses both a faculty adviser and a student editor-in-chief, both can be granted approval authority for their respective sections — but the gate enforces whoever holds the approval role, not an honour system.

How is this different from a consumer photo-book service?

A consumer photo-book service is designed for a family making a holiday album: a wizard of template choices, a drag-and-drop interface, and an order button at the end. Yearbook Press is designed for a school publication with several hundred portrait entries, a student staff of 20, an adviser who must approve every spread before it ships, a consent requirement for every student portrait, a coverage gap that must be caught before the book closes, and a press-ready file that a commercial lab can actually print on schedule. Those are editorial production problems, not photo-book problems. The production editor, the roster-driven portrait flow, the adviser proof-approval gate, and the automated pre-flight exist because consumer tools do not solve them.

When can we start?

The platform is in active development. In a demo we walk through the production editor, a roster-driven portrait section, the proof-approval queue, and the press-ready export with an automated pre-flight result. None of that involves a payment or a contract. A conversation is the honest next step — we show what is built and in production, you see whether it fits your programme, and we discuss what starting the current school year’s book looks like. To start: email [email protected] or use the “start your book” link.