Book a demo

Yearbook Lab Software · yearbook production toolchain

Build the book, prove it is producible, hand a print-ready file to any capable press.

Yearbook Lab Software is the production side of yearbooks: composition spread by spread, Book QA and preflight, and a single server-side render that validates the finished book against a specific printer’s declared capability profile before producing the print-ready file. The builder, Theme Studio, Cover Studio, fail-closed consent and preflight gating, and PSPA-world subject intake are built and run today. The live plant send to a press is the early-access leg — composition, Book QA, and print-ready render are not. This page names each honestly.

Get in touch See the shared preflight layer →

Production toolchain for yearbook programs that print elsewhere: we output a print-ready book for any capable vendor. Distinct from the consumer/school front doors (schoolyearbook.software, myyearbook.software) and from general press/print capability software (printlab.software). Portrait intake from the photographic/package-lab side is at photolab.software. Plant send and pricing are honest-off.

What is built and what is early access

The five production pillars below are the core of the yearbook production toolchain. The first five are built and running today. The live plant send is early access: the print-ready file is produced by built code; the transmission to a press is the step that is honest-off. We mark each honestly.

Book builder and layout engine

The production core is a spread-by-spread composition surface built across two packages: the composite package (authoring, customer-builder, scene-template, design-lock, consent-placement) and the layout package (auto-layout, draft-spread, block-group, book-front-matter, endsheet, colophon, coverage). An adviser or production team builds the yearbook spread by spread inside the builder; auto-layout proposes block arrangements; the coverage-projection module tracks who is and is not yet in the book. A portrait placed in a spread carries its consent record; the design-lock step is one of two gates the render facade re-runs before it ever produces a print-ready file. Shipped

Theme Studio and Cover Studio

Theme Studio is the school-level design-system workbench where an adviser defines the typographic palette, color scheme, and visual language that runs across the whole book. Cover Studio is the cover-design surface where the production team builds the front cover, spine, and back cover. Both are built routes in the platform. The buildable cover options — cover stock, spine width, finishing, board weight — derive directly from the assigned printer’s capability profile at the time of design: a cover treatment the printer does not declare is not offered. There is no risk of designing a cover the press cannot run. Shipped

Fail-closed Book QA and preflight

The book preflight is fail-closed: it refuses to proceed with a missing portrait, an unsigned release, or a consent gap anywhere in the book. A spread with an unfilled portrait placeholder cannot pass preflight. A student whose consent is withdrawn is removed from every placement that referenced their portrait before the preflight step runs. Producibility defers to the central @homeroom/print-delivery gate, which resolves the printer’s capability profile fail-closed to empty when no profile is declared — meaning a book against an unknown vendor is denied, not allowed. The print manifest is validated by the ssy-manifest-validator before the book is considered print-ready. Shipped

Print-ready render for any capable vendor

The single server-side render facade (packages/composite/src/render-facade.ts) is the one place in the codebase that maps a finished book’s scene data to the raw PDF render primitive. No other module calls the render primitive. Before rendering, the facade re-runs the render gate (the second of two design-lock gates) to catch any print-spec violation that occurred after the spread was last saved. The resulting file is validated against the assigned printer’s specific capability profile — binding, trim, stock, finishing — before it is stamped print-ready. A book that passes is a book that specific printer can produce. A book that does not fails with a plain-language reason. Shipped

PSPA-world subject intake

Production teams work with school package data in the industry-standard PSPA format. The lab-routing volume/rpl-xml rails ingest subject and portrait data in stable PSPA order (the PonySortRow model: student, grade, teacher, homeRoom). A production team drops a PSPA manifest, and the subjects are tied to roster entries, placed in the coverage tracker, and available in the builder without a manual re-entry step. The prior-book-import path brings a previous year’s book forward as a starting composition: section structure, front matter, colophon placeholders, and endsheet carry over; the new year’s portrait data populates the roster slots. Shipped

Live plant send

The composition, Book QA, and print-ready render steps are built and run today. The live plant send — the step that transmits the validated print-ready file and manifest to a press partner — is honest-off pending enablement. No file is transmitted to a press through this system today. Pricing, checkout, and any order-tracking flow tied to a press submission are also honest-off. We name the gap plainly: a production team can build, proof, run Book QA, and produce a print-ready file today; the act of handing that file to a press through the platform is early access. Early access

How a book moves from composition to print-ready

The production arc follows a clear sequence. Each step has a defined gate. No step is skipped on the way to a print-ready file.

  1. Subject intake. A production team ingests the school’s subject data from a PSPA manifest via the lab-routing volume/rpl-xml rails. Students are tied to roster entries in stable PSPA order (PonySortRow: student, grade, teacher, homeRoom). The coverage-projection module immediately shows who is and is not yet placed in the book. Prior-book-import can bring last year’s composition forward as a structural starting point.
  2. Design system setup in Theme Studio. The adviser opens Theme Studio and defines the school’s typographic palette, color scheme, section templates, and the visual language that runs through the book. The theme is the source of truth the builder applies to every spread — a change to the theme propagates to every section that inherits it without manual re-application.
  3. Cover design in Cover Studio. The Cover Studio surface lets the production team build the cover, spine, and back cover. The options available — cover material, board weight, lamination, finishing — are drawn directly from the assigned printer’s capability profile. A treatment the printer does not declare is not shown; there is no path to designing a cover the press cannot run.
  4. Spread-by-spread composition in the builder. The team builds the yearbook spread by spread in the composite builder. Auto-layout proposes block arrangements from the coverage-projection roster and the section’s template. Portrait consent is checked at placement: a student without a valid consent record cannot be placed. The design-lock gate prevents a print-spec violation from reaching the render step.
  5. Book QA. Before the book proceeds to preflight, the Book QA step scans the full composition for unfilled portrait placeholders, missing releases, consent gaps, and coverage mismatches. A book with any open issue does not pass Book QA. The issues are listed with plain-language descriptions so the team can resolve each one before advancing.
  6. Preflight and producibility check. Once Book QA passes, preflight runs the full producibility check against the assigned printer’s capability profile: binding type, trim size, page count range, stock, finishing, and cover capability must all be within the printer’s declared supported range. A dimension outside the range produces a typed rejection with a plain-language reason. A printer with no capability data resolves to the empty profile (no upgrades, no confirmation). Only a book that passes every dimension is stamped producible.
  7. Print-ready render. The single server-side render facade re-runs the render gate (the second design-lock pass) and then calls the PDF render primitive to produce the print-ready file. The manifest is validated by the ssy-manifest-validator. The resulting file and manifest are the deliverables. At this point the book is print-ready for any press that matches the declared capability profile.
  8. Plant send (early access). The step that transmits the validated file and manifest to a press is honest-off. A production team that wants to send the print-ready file to their own press relationship can take the file directly. The live plant-send path through the platform is early access, named plainly.

The capability-profile honesty: print-ready for any capable vendor means what it says

The phrase "print-ready for any capable vendor" is a built truth, not a slogan. Here is what makes it honest.

The @homeroom/print-delivery capability profile is a closed-world model: every dimension of a printer’s production capability — binding types, trim sizes, page-count ranges, interior stocks, cover materials, finishing treatments, lamination options, endsheet types, tip-in support, personalization, variable-data, and the publication types the vendor will print — is declared explicitly. Anything not declared is denied. The default is not permissive; it is deny.

The assertProducible gate consults this profile before a print-ready file is produced. A book whose binding type is not in the vendor’s declared set is rejected with a typed ProducibilityDeniedError that carries a plain-language reason the UI can surface to the production team. A book whose page count falls outside the vendor’s supported range is rejected. A cover treatment the vendor does not run is rejected. There is no silent pass-through for a dimension that is close but outside the declared limits.

A vendor with no capability data in the system resolves to the empty capability profile. The empty profile declares nothing; assertProducible against the empty profile denies every dimension. A book does not receive a print-ready stamp against an unknown or unconfigured vendor.

The consequence is that "any capable vendor" is honest: the capability-profile model supports declaring any vendor whose profile is entered into the system, and the assertProducible gate validates a book against the specific vendor’s specific declared limits. We do not claim to partner with any press or to have relationships with specific vendors. We claim to produce a validated print-ready file against the capability profile of whichever vendor the production team assigns. That claim is built.

The builder and layout engine in detail

The composite and layout packages together cover the full authoring arc from a blank book to a spread-complete composition.

Spread-by-spread authoring

Each spread in the book is an authored composition: a scene that places blocks (portrait, text, background, graphic) onto a grid within the spread’s physical size and bleed. The scene-template layer defines the layout vocabulary for a spread type — a portrait-grid spread uses different block constraints than a feature spread or a section opener. The builder applies the template rules at authoring time; a block that violates the template’s constraints is not placed. The composition is stored as structured scene data, not a flat image, so a later change to a student’s portrait (a retake, a consent update) can be applied to the placed block without rebuilding the spread from scratch.

Auto-layout

The layout package’s auto-layout engine proposes block arrangements for a spread from a roster slice and a spread template. A production team assigns a homeroom or a grade band to a spread; auto-layout places the portraits in stable PSPA order (last name, first name, within grade-teacher grouping), respects the block-size constraints of the template, handles partial fills at the section boundary, and flags overflow when more subjects exist than the spread can hold. The proposal is editable: the production team can reorder placements, swap a portrait for a different block type, or override the auto-arrangement. The layout is a starting point, not a final output.

Front matter, endsheet, and colophon

The layout package includes built surfaces for the structural parts of a yearbook that are not portrait spreads. The book-front-matter module handles the title page, table of contents, and opening spread. The endsheet module handles front and back endsheets with the school-year and school-identity metadata. The colophon module handles the credits and production information required at the back of a yearbook. All three derive from the theme set in Theme Studio and are subject to the same design-lock and preflight gates as portrait spreads. The prior-book-import path carries these structural elements forward from the previous year’s book as starting points.

Coverage projection

The coverage-projection module answers the question the production team asks throughout the year: who is in the book and who is not yet placed? It tracks every student in the roster, matches them against placed portraits in the current composition, and surfaces a per-section and whole-book coverage report. A student who appears in a spread but whose portrait has since been updated (a retake) is flagged as needing a placement refresh. A student who was withdrawn from enrollment is flagged for removal from any spread where they appear. The report is available at any point in the production cycle, not only at preflight.

PSPA-world intake: how subject data enters production

The photo-industry standard for transferring school package data is the PSPA format: a roster of subjects with grade, teacher, and homeroom, presented in a defined sort order (PSPA order), matched with portrait assets keyed on the subject record. Yearbook Lab Software ingests this data natively.

The lab-routing volume/rpl-xml rails handle the intake. A production team drops a PSPA manifest; the rails parse the subject records in stable PSPA order and tie each to the school’s roster by the PonySortRow key fields (student identifier, last name, first name, grade, teacher, homeRoom). The coverage-projection module is updated immediately: every ingested subject appears in the coverage tracker, placed or unplaced, without a manual association step.

The pony-sort model also defines how a bulk-to-school photo lab physically sorts a crate of printed packages by classroom. The same PonySortRow data that feeds the coverage tracker is the data the lab-routing volume/rpl-xml layer uses for Rail B (bulk-to-school, volume manifest + SFTP) fulfillment of photo products. Portrait data and package-routing data share a single source of truth: the roster intake. There is no second import to reconcile them.

Prior-book-import is a distinct intake path: a production team uploads a previous year’s book as a starting composition. The import extracts the structural shell — section sequence, spread templates, front matter, colophon, endsheets — and populates it as a draft for the new year. Portrait placements are cleared (last year’s students are not this year’s students); the coverage-projection module then shows every new-year roster subject as unplaced against the imported structure. The team fills the new year’s book from a structurally familiar starting point rather than from blank.

The single render facade: why one path from composition to PDF matters

The check:render-facade invariant in the codebase states that exactly one module — packages/composite/src/render-facade.ts — may call the raw PDF render primitive. No other composite module imports the render function. This is a structural constraint, not a convention, and it has direct consequences for production quality.

Gate re-run before every render

The facade re-runs the render gate (design-lock.ts, the second of the two production gates) before it calls the PDF render primitive. This means a print-spec violation that was introduced after the spread was last saved — a theme change that moved a block outside the bleed, a capability-profile update that invalidated a finishing treatment — is caught at render time, not discovered after the file is produced. A book that passes both gates at render time is a book whose scene data is consistent with the assigned printer’s capability profile at that moment.

One output path, one place to audit

Because the render facade is the only path from a composition to a print-ready PDF, it is also the only place to audit render behavior. A change to how the PDF engine handles bleed, color profile, or font embedding is a change to one module. There is no parallel render path that might produce a different result. The ssy-manifest-validator that inspects the output also has one output to inspect. The audit trail for a rendered book — which scene data produced which file, under which capability profile, at which design-lock gate result — is a record in one place.

Color profile from the printer

The PDF render primitive accepts a printer target and derives the color profile from that target. A yearbook rendered for a press that runs CMYK with a specific ICC profile receives a different render output than one rendered for a press with different color specifications. The facade injects the printer target from the assigned capability profile, so the color space and ICC profile in the output file match what the press expects. A book that arrives at the press in the wrong color space is a production problem that the render facade is designed to prevent.

Consent gate before render

The consent-placement module in the composite package ensures that a portrait block in a scene carries the consent record of the student it depicts. The render facade’s gate pass re-checks consent state at render time: a student whose consent was withdrawn after their portrait was placed in a spread will cause the render gate to reject the scene. The book cannot be rendered with a portrait that has lost consent since the last save. The consent check is not only a preflight step; it is also a render-time gate.

How this toolchain differs from the other yearbook-family properties

The yearbook-family properties each cover a different part of the yearbook lifecycle. Knowing which is which prevents a production team from landing on the wrong entry point.

schoolyearbook.software is the school-facing consumer front door: where a school adopts a yearbook program, where a coordinator sets up the school’s yearbook campaign, and where the school-side collection and distribution decisions are made. It is the entry point for a school that wants to order yearbooks, not the entry point for a production team building one. A school on schoolyearbook.software may have its yearbook produced by the toolchain here; the two sides are connected but distinct.

myyearbook.software is the consumer/family entry point: where a student or parent purchases a yearbook, accesses their copy, and manages their order. It is not a production tool. The yearbooks a family purchases through myyearbook.software are built in this toolchain; the family never touches the builder.

printlab.software is the shared press-production capability and preflight layer. The @homeroom/print-delivery gate that Yearbook Lab Software consumes for its producibility checks — the capability profile, assertProducible, the manifest validator — is the same infrastructure printlab.software exposes for general print production across publication types (newspapers, literary magazines, event programs, and yearbooks). Yearbook Lab Software is a consumer of that shared gate, not a duplicate of it. A production team that wants to understand the printability rules for a press should look at printlab.software; the yearbook-production-specific toolchain is here.

photolab.software is the photographic/package-lab intake side: the routing layer that ingests school portrait packages, routes photo products to a lab (WHCC, Bay, Richmond, HH, and others), handles Rail A (dropship to a parent’s home) and Rail B (pony-sorted crate to a school), and manages the fulfillment lifecycle of individual photo products. Portrait data ingested through photolab.software feeds into the yearbook production toolchain here; the two are connected at the PSPA intake seam. They are distinct: photolab.software routes photo products to labs; yearbooklab.software produces the yearbook book that uses those portraits.

freeyearbook.digital is the free-digital-yearbook program: the output of the production toolchain here, delivered digitally at no charge to families. The book that a production team builds in this toolchain is the same book that may be distributed through freeyearbook.digital. The production side (this toolchain) and the distribution side (freeyearbook.digital) are separate surfaces for different audiences.

What is early access and what is planned

These capabilities are not presented as available today. They are named so a production team considering this toolchain can see the honest state of each item rather than discovering a gap after committing.

Live plant send

The step that transmits the validated print-ready file and manifest to a press partner is honest-off pending enablement. The print-ready file is produced by built code; no transmission to a press occurs through the platform today. A production team that wants to use the print-ready file can take it directly to their press relationship. The live plant-send path, the order-tracking integration, and the press-confirmation workflow are early access. We name this plainly rather than describing the plant send as available. Early access

Pricing and order management

Any pricing surface, checkout flow, or order-management UI tied to a press order is honest-off. The production toolchain does not have a live pricing table or a checkout path today. A production team works with their press directly on pricing. When the plant-send path is enabled, the order-management layer will allow tracking and confirmation from within the platform. Early access

Press partner capability-profile registry

The capability-profile model is built and the assertProducible gate is built. The registry of press partners with pre-loaded capability profiles — so a production team can select a press from a list and get immediate producibility feedback without entering the profile manually — is in progress. Today a capability profile is entered for a specific press assignment; the curated partner registry is the planned next layer. Planned

Digital delivery integration with freeyearbook.digital

The print-ready book produced by this toolchain can also be the source file for a digital edition distributed through freeyearbook.digital. The integration path — where a completed book is pushed directly to the free-digital distribution program without a manual file handoff — is planned as a delivery option alongside the print plant send. Planned

Common questions

Can we send a book to our press using this toolchain today?

No, not through the platform. Composition, Book QA, preflight, and print-ready render are all built and run today. The plant send — the step that transmits the validated file and manifest to a press through the platform — is honest-off pending enablement. A production team can take the print-ready file produced by the toolchain and deliver it to their press directly. The live plant-send path through the platform is early access.

What does “any capable vendor” mean? Does the platform have press partnerships?

It means the capability-profile model supports any press whose capability profile is entered into the system, and the assertProducible gate validates a book against that specific profile. The platform does not claim to partner with specific presses or to have negotiated relationships with them. The claim is that the print-ready file is validated against the assigned press’s specific declared limits: binding, trim, stock, finishing, page count range, and the publication types the vendor will print. That validation is built. The partnership claim is not made.

What is the capability profile and why does it matter for cover design?

The capability profile is a closed-world declaration of everything a specific press can produce: binding types, trim sizes, page-count ranges, interior stocks, cover materials, board weights, lamination, finishing treatments, endsheet types, and more. A dimension not declared is denied — the profile is not permissive by default. Cover Studio surfaces only the cover options the assigned press declares. A cover treatment the press does not run is not shown as an option. The result is that a design built in Cover Studio is always a design the assigned press can produce.

What is Book QA and how is it different from preflight?

Book QA is the step that runs before preflight and checks the composition for content completeness: missing portrait placeholders, unsigned releases, consent gaps, coverage mismatches. It is the content-quality gate. Preflight runs after Book QA passes and checks physical producibility against the assigned printer’s capability profile: binding, trim, stock, finishing, page count, and all other physical dimensions. A book must pass both to receive a print-ready stamp. Book QA catches content issues; preflight catches physical-spec issues.

How does PSPA intake work in practice?

A production team ingests the school’s subject data from a PSPA manifest through the lab-routing volume/rpl-xml rails. The manifest is parsed in stable PSPA order (PonySortRow: student, grade, teacher, homeRoom) and each subject is tied to the roster. The coverage-projection module immediately shows the full roster as placed or unplaced against the current composition. There is no manual re-entry step. If the school’s photo lab delivers package data in PSPA format, the intake reads it natively.

What does the single render facade guarantee?

The render facade (packages/composite/src/render-facade.ts) is the only module in the codebase that calls the raw PDF render primitive. Before it renders, it re-runs the design-lock gate and the consent gate. A book that passes both gates at render time is rendered; a book that does not is rejected with a plain-language reason. This means a print-spec violation or a consent withdrawal that occurred after the last save is caught at render time. There is no parallel render path that could produce a file without running the gates.

What is the difference between this toolchain and printlab.software?

printlab.software is the shared press-production capability and preflight layer: the @homeroom/print-delivery gate, the capability-profile model, the assertProducible logic, and the manifest validation apply to all publication types (yearbooks, newspapers, literary magazines, event programs, and others). Yearbook Lab Software is a yearbook-production-specific toolchain that consumes that shared gate. The builder, Theme Studio, Cover Studio, PSPA intake, Book QA, and the render facade are all yearbook-production-specific surfaces that sit on top of the shared preflight infrastructure.

Is this connected to the consumer/school front doors?

Connected but distinct. A school that adopts a yearbook program through schoolyearbook.software may have its yearbook produced by the toolchain here; the school-side coordinator and the production team are separate roles on separate surfaces. A family that purchases a yearbook through myyearbook.software receives the book produced by this toolchain; the family never interacts with the builder. The consumer and school front doors are the demand and distribution side; this toolchain is the production side.

Can a prior year’s book be used as a starting point?

Yes. The prior-book-import path extracts the structural shell from a previous year’s book — section sequence, spread templates, front matter, colophon, endsheets — and populates it as a draft for the new year. Portrait placements are cleared. The new year’s roster subjects appear as unplaced in the coverage tracker against the imported structure. The production team fills the new year’s book from a structurally familiar starting point rather than from blank.

What does “honest-off” mean for pricing and the plant send?

It means the feature is not live: the code infrastructure exists or is in development, but a specific dependency — in this case the enablement of the plant-send path and the pricing rail — is not yet connected. Pricing on this page is honest-off: there is no published price table. The plant send is honest-off: the step of transmitting the print-ready file to a press through the platform does not occur today. We name the gap rather than presenting these as available.

Related properties

The yearbook production toolchain is part of a connected set of properties. Each covers a different side of the yearbook lifecycle.

freeyearbook.digital

The free-digital-yearbook program: the distribution side of the yearbooks the production toolchain here builds. Families receive the digital edition of the yearbook produced from this toolchain at no charge through this program.

homeroom.software

The flagship platform brand home and the full product story: yearbook, picture day, student records, family communication, theatre software, scheduling, and the complete school program suite that the yearbook production toolchain is part of.

printlab.software

The shared press-production capability and preflight layer. The @homeroom/print-delivery gate — the capability-profile model, assertProducible, the manifest validator — that this toolchain consumes for its producibility checks is the shared infrastructure printlab.software exposes for all publication types.

schoolyearbook.software

The school-facing consumer front door: where a school adopts a yearbook program and where a coordinator sets up the school’s campaign. The demand and adoption side, distinct from this production toolchain.

myyearbook.software

The consumer/family front door: where a student or parent purchases a yearbook and accesses their copy. The books a family purchases here are built in this production toolchain.

photolab.software

The photographic/package-lab intake side: the routing layer that ingests school portrait packages and routes photo products to labs. Portrait data ingested through photolab.software feeds into this yearbook production toolchain at the PSPA intake seam.

What is built and what is honest-off

The book builder and layout engine (composite + layout packages: authoring, auto-layout, scene-template, design-lock, consent-placement, coverage projection, front matter, endsheet, colophon) are built and running today. Theme Studio and Cover Studio are built routes. The fail-closed Book QA and preflight gates — refusing a book with a missing portrait, an unsigned release, a consent gap, or a physical-spec mismatch against the assigned printer’s capability profile — are built and running today. The single server-side render facade that produces the print-ready file, re-running both design-lock gates before calling the PDF render primitive, is built. PSPA-world subject intake via the lab-routing volume/rpl-xml rails and the prior-book-import path are built. The live plant send to a press and any pricing or order-management UI tied to a press order are honest-off: not available today, named plainly. The press partner capability-profile registry and the digital-delivery integration with freeyearbook.digital are planned. Money — any pricing surface or checkout — is honest-off.

Get in touch The full platform story →

Yearbook Lab Software is a Stanley Studios product — the production toolchain within the same substrate that backs schoolyearbook.software, myyearbook.software, freeyearbook.digital, and the broader school-platform suite. Built for production teams and yearbook programs that print elsewhere: build the book, prove it is producible, hand a print-ready file to any capable press.