Modular Yearbooks · a staff-built book, composed per copy
Assemble the yearbook from modules; compose it per copy.
A yearbook does not have to be one fixed book. It can be a set of MODULES an adviser assembles once, which the platform composes into every copy. Modular Yearbooks is that build made explicit: shared spreads and per-child modules are the parts, and a pure composition engine resolves the ordered module list for each copy the same way every time — the same inputs produce a byte-identical book. Each copy runs on its own per-copy print lane, so two students can hold genuinely different books off one production without a second project. Curation runs roster-tag-only: the AI face-matching auto-fill that would pre-fill a copy from a face is early access and operator-gated — it is off, and the build degrades, by design, to a labeled roster-only lane rather than faking a match. Families author a bounded personal module — two to four pages for their own child — which the server scans and the adviser locks; there is no parent spread picker. The order rails are built, but money is off here: an adviser reserves and expresses interest today, and no card is charged. We name which parts are live and which are not.
This is the adviser-facing, modular-assembly door. The family-first entrance onto the same engine is flexibleyearbook.com, and the whole-platform overview is yearbook.software. The same real engine runs behind all of them; this page describes it as a build system a staff adviser controls.
The module catalog
A yearbook here is not one fixed file; it is an ordered list of modules a copy is composed from. These are the module classes the engine actually resolves — the vocabulary an adviser builds with. Every copy is the same re-derivation over this catalog: the protected spine and the always-in sections, the optional modules the adviser’s config admits, the owner’s own grade home, and the family’s bounded personal module — ordered by the adviser’s section ordinals into one reader-order book.
The protected spine
Cover, the people-and-portrait block, the signing and colophon, the index. The composition engine re-derives this spine into every copy from the live section table, never from a copy’s stored spec, so a stale copy can never omit it. It is the backbone every copy carries.
Adviser-defined · always in, never droppableAdviser always-in
A section the adviser marks always-in for this book, so every copy carries it whatever else varies. Like the spine, its inclusion is re-derived from the live table at compose time, not trusted from the spec.
Adviser-defined · always inComposed by config, within a window
A module the composition may include in a copy. The adviser defines the optional modules and a minimum and maximum count window; the pure resolver composes within that window and orders the result by the adviser’s section ordinals. There is no parent-facing picker — the composition config is the adviser’s, and the resolve is deterministic.
Adviser config · deterministic resolveThe owner’s own grade, resolved server-side
A grade-gated section is mandatory only for the copy whose owner is in that grade; every other grade’s home is excluded from that copy. The owner grade is resolved from enrollment on the server, so a copy can never smuggle in a grade home that is not its owner’s.
Derived from enrollment · owner-gatedThe bounded family module
Two to four personal pages a family authors for their own child, appended after the canonical run. Before it composes in, the server runs a fail-closed content-safety scan — flagged or unscannable is held, never trusted — consent is re-checked, and the adviser locks it. It is the one part a family shapes, and it is bounded.
Family-authored · scanned fail-closed, adviser-lockedWhat the modular build gives an adviser
Six parts of one system, sized for a staff adviser who wants control and repeatability. Five are built and running end to end. The sixth — the AI face-matching auto-fill — is early access and off, and marked so; curation runs roster-tag-only without it.
Modules are the unit, not a monolith
The book is a parts list, not a single fixed layout. Shared spreads carry what every copy has in common; per-child modules carry what belongs to one student. An adviser reasons about the book as a set of modules and a config for how they combine, and the platform builds each copy from those parts. Treating the book as modules is what makes the rest — determinism, per-copy variation, a bounded family contribution — possible at all. The modular composition is built and running. Shipped
Deterministic composition, byte for byte
The engine that resolves the ordered module list for a copy is pure: no clock, no randomness, no hidden state. Given the same modules and the same config, it produces a byte-identical book every time, and the per-copy spread selection is the same — a reproducible spec, not a fresh guess per run. That is what makes a modular book auditable: an adviser can re-run a copy and get exactly what shipped. The deterministic composition and curation are built and running. Shipped
A per-copy print lane
Because every copy can differ, each one is produced on its own per-copy lane rather than a single shared file. The platform checks, before it renders a byte, that the target printer DECLARES the two capabilities a per-copy book needs — variable data and per-copy-unique output — and refuses the copy up front if it does not. No half-built variable book slips to a press that cannot print it. The per-copy lane and its fail-closed capability gate are built and running. Shipped
A bounded family module, scanned and locked
Families do not rearrange the book; they author a bounded module — two to four personal pages for their own child. Before that module can be composed into a copy, the server runs a content-safety scan that is fail-closed: a module that is flagged, or that cannot be scanned at all, is held rather than trusted. Consent is re-checked, and an adviser locks the module in. Families contribute the pages that are theirs; the adviser stays in control of the book. The personal-module gate is built and running. Shipped
A consent sweep before it renders
Right before a copy is composed, the platform sweeps every subject depicted on every selected spread and resolves each one’s consent. If any depicted student is publication-suppressed or do-not-publish — or has no resolvable consent — that copy is not rendered. The sweep is a hard wall, not a warning: a suppressed child cannot ride into a personalized copy on a stale spec. Photos are matched by roster lookup, not a face scan. The suppression sweep is built and running. Shipped
AI face-matching auto-fill — off
There is an AI step in the engine — a face model that would pre-fill a copy by matching a student’s face across the photos — and it is operator-gated and not wired. So every copy composes roster-tag-only: the build uses the roster tags on each spread and stamps the copy as a labeled roster-only lane, never a faked face-group. This is the one part that is not live, and it is off by design; nothing on this page depends on it. Early access, operator-gated. Early access — AI face match off
How an adviser composes the book
The whole book is a set of modules and a config for how they combine. An adviser sets the parts and the rules once; the platform composes each copy the same way every time, checks consent and safety before it renders, and prints each copy on its own lane. Nothing is re-keyed per student, and no copy renders until the parts it depends on are cleared.
- Define the modules. Decide what the book is made of: the shared spreads every copy carries, and the per-child modules that belong to one student. The book becomes a parts list the platform can compose from, rather than a single fixed layout. The platform is free for the school to run — no per-copy fee and no subscription.
- Set the composition config. The adviser controls which modules combine, in what order, and how many personal pages a copy may carry. Only an adviser, a co-adviser, or an admin can enable a plan, build copies, or lock a module — the master-control sits with the staff, not with a parent or a student.
- Let the platform curate each copy. For each student, the engine selects the spreads that feature them from the roster tags and resolves a byte-identical per-copy spec. The AI face-matching auto-fill is off, so curation runs roster-tag-only and the copy is stamped as a labeled roster-only lane — never a faked face match.
- Invite families to author a personal module. A family authors a bounded module — two to four pages for their own child — in the editor. They contribute the pages that are theirs; they do not pick, reorder, or rearrange the shared book. There is no parent spread picker.
- Scan, re-check consent, and lock. Before a personal module can be composed in, the server runs a fail-closed content-safety scan — a flagged or unscannable module is held, never trusted — consent is re-checked for the child, and the adviser locks the module. The parts clear the wall before they reach the book.
- Sweep consent before render. As each copy is composed, the platform sweeps every subject depicted on every selected spread and resolves consent. If any depicted student is suppressed or do-not-publish, that copy is not rendered. A stale spec cannot carry a suppressed child into a personalized copy.
- Compose and merge, per copy. The platform composes and merges each copy into a press-ready PDF — no model in the compose path — and produces it on the per-copy lane. A copy is refused before render if the target printer does not declare variable-data and per-copy-unique output, so a variable book never reaches a press that cannot print it.
- Reserve — money is off. The order rails are built, but live charge and checkout are off here. An adviser reserves and expresses interest today rather than charging a card. No school has run a live sale here yet, and we say so.
Why build it as modules
Treating the book as a set of modules is not a style choice; it is what lets one production yield different books, keep them reproducible, and give a family a bounded contribution without handing over the whole book.
Parts, not a single file
A monolithic book is one file everyone shares; a modular book is a set of parts an adviser combines. Shared spreads hold what is common, per-child modules hold what is personal, and the composition config says how they join. Reasoning about parts is what makes per-copy variation tractable — you change a module or a rule, not a thousand copies by hand.
Reproducible, byte for byte
The composition engine is pure — no clock, no randomness — so the same modules and config always resolve to the same book. Re-run a copy and you get exactly what shipped, down to the byte. That is what makes a modular book auditable: the output is a function of the inputs, not a fresh guess, so an adviser can prove what a given copy contained.
One production, many copies
Each copy is produced on its own per-copy lane, so two students can hold genuinely different books off a single production — different personal modules, different curated spreads — without standing up a second project. The lane also carries the guardrail: a copy is refused before render if the target printer cannot declare the variable-data and per-copy-unique capabilities the book needs.
Adviser holds the master; families contribute a module
Modularity here does not mean a free-for-all. The adviser holds the master: which modules exist, how they combine, and when a copy is locked. A family authors a bounded personal module — two to four pages for their own child — that is scanned and locked before it composes in. There is no parent-facing spread picker; the personal pages are the family’s contribution, and the book stays the adviser’s.
Consent-gated, because a personalized book depicts real children
A per-copy book puts a named child on a page, so consent is load-bearing, not a footnote. Data that involves a minor child is consent-gated: a family opts in before their child’s image is used in a way that requires it, and that consent can be withdrawn at any time. The choice is set per child and enforced at the data layer, so an adviser is not tracking permission slips on paper — the platform knows which children may appear and which may not.
The consent sweep is where this becomes a wall rather than a hope. As each copy is composed, the platform resolves consent for every subject depicted on every selected spread — not only the student the copy is for. If any depicted child is publication-suppressed, do-not-publish, or has no resolvable consent, that copy is not rendered. A spread curated before a child’s consent changed cannot carry that child into a personalized copy on a stale spec; the sweep runs at render, every time.
Photos are matched to a child by roster lookup, not by a face scan. Facial recognition is off by default and never auto-tags a child. The AI face-matching auto-fill that could pre-fill a copy is operator-gated and off; when it is ever enabled, it is only ever turned on for an individual child by that child’s own parent, one explicit opt-in at a time — never switched on across a roster by default. The ordinary way a photo reaches the right copy is the roster tag, not recognition.
Family-authored personal modules cross the same wall as everything else: before a module composes into a copy, the server scans its content fail-closed — a flagged or unscannable module is held — and the adviser locks it. The school owns its children’s and families’ data; it is never sold to or shared with outside companies or advertisers. Minor child data runs on private systems and is never made public, so a personalized book of real students is not exposed to the open internet.
Built for an adviser who wants control
A modular book is only better than a fixed one if the person running it stays in control of the parts. The platform is shaped so the adviser holds the master and the system is predictable.
Master-control and the lock
Only an adviser, a co-adviser, or an admin can enable a personalized plan, build the copies, or lock a module. A parent or a student cannot reach that switchboard. The adviser decides which modules exist, how they combine, and when a copy is locked — the personalization is a staff-run build, and the lock is the point past which a copy is settled.
Bring a printer that can print it
A per-copy book needs a press that can print variable, per-copy-unique output, so the platform checks that the target printer declares both capabilities and refuses a copy before render if it does not. There is no captive print vendor built into the software; the school brings its own capable lab, and the platform will not hand a variable book to a press that cannot produce it.
Reproducible is auditable
Because composition is deterministic, an adviser can re-run any copy and get exactly what shipped. That turns “what did this student’s book contain” into a question with a provable answer, not a memory. When a family asks, or a record is needed, the copy is a function of its inputs — re-derivable, byte for byte, from the modules and the config.
Free to run, no rep, money off
A school stands up its own modular build on its own timeline, with no territory rep and no multi-year contract. The platform is free for the school to run — no subscription, no per-copy fee, no setup charge. The order rails are built, but live charge and checkout are off: an adviser reserves and expresses interest today rather than charging a card.
Common questions
What does “modular” actually mean here?
The book is a set of modules an adviser combines, not one fixed layout: shared spreads carry what every copy has in common, and per-child modules carry what belongs to one student. A composition config says how the parts join, and the platform builds each copy from them. Modularity is the assembly model — deterministic composition, per-copy variation, and a bounded family contribution — not a drag-and-drop free-for-all.
Is the AI face matching live?
No. There is a face model in the engine that would pre-fill a copy by matching a student’s face across the photos, and it is operator-gated and not wired. Every copy composes roster-tag-only and is stamped as a labeled roster-only lane — never a faked face-group. It is early access and off by design; nothing on this page depends on it. When it is ever enabled, it is a per-child opt-in a parent controls, never on by default.
Do parents pick or rearrange the spreads in the book?
No. There is no parent-facing spread picker. The shared book is composed by the adviser from the modules and the config; a family authors only its own bounded personal module — two to four pages for their child — which the server scans and the adviser locks. The per-copy differences come from the deterministic composition and the personal module, not from a parent reordering the book.
If two students get different books, do we need a special printer?
Yes, and the platform checks for you. A per-copy book needs a press that can print variable, per-copy-unique output. Before it renders a copy, the platform confirms the target printer declares both capabilities and refuses the copy up front if it does not. There is no captive print vendor; you bring a capable lab, and a variable book never reaches a press that cannot print it.
What stops the same inputs from producing a different book?
The composition engine is pure — no clock, no randomness, no hidden state. Given the same modules and the same config, it resolves a byte-identical book and the same per-copy spread selection every time. That determinism is deliberate: it makes a copy re-derivable and auditable, so an adviser can re-run a copy and get exactly what shipped.
What keeps a family’s personal pages safe?
A fail-closed gate. Before a family-authored module composes into a copy, the server runs a content-safety scan over its text; a module that is flagged, or that cannot be scanned at all, is held rather than trusted — we never treat “did not scan” as “clean”. Consent is re-checked for the child, and the adviser locks the module. The scan runs on the server, so the rules cannot be bypassed from a browser.
How is consent handled for the children in a personalized book?
Consent is gated and reversible: a family opts in before their child’s image is used in a way that requires it, set per child and enforced at the data layer. As each copy is composed, the platform sweeps every depicted subject on every selected spread and resolves consent; if any depicted child is suppressed or do-not-publish, that copy is not rendered. Minor child data runs on private systems and is never made public, and photos are matched by roster lookup, not a face scan.
Can we sell or charge a family today?
Not yet. The order rails are built and production-ready, but live charge and checkout are honest-off: present in the platform, not enabled for live transactions. An adviser reserves and expresses interest today. No school has run a live sale here yet, and we say so plainly rather than dressing a reservation up as a purchase.
What does the platform cost the school?
The platform is free for the school to run: no subscription, no per-copy fee, and no setup charge. When live selling is enabled, the platform is funded on the sale side of a printed-copy purchase, never by charging the school to use the software. You bring your own capable printer, and standing up the modular build costs the school nothing.
How is this different from flexibleyearbook.com?
It is the same real engine behind a different door. flexibleyearbook.com is the family-first entrance — the personalized book described for the families it is made for. Modular Yearbooks is the staff-first, build-system entrance — the same engine described as modules an adviser assembles and composes per copy, with the master-control, the determinism, and the per-copy lane in front. Same engine, a buyer who wants control.
Related surfaces
The modular door connects to the family-first entrance on the same engine, the whole-platform overview, and the single-school product page. These destinations cover the adjacent surfaces.
flexibleyearbook.com
The family-first door onto this same engine: the personalized book described for the families it is made for. This modular door leads on staff control and the build system; that one leads on the family. Same engine, different buyer.
yearbook.software
The umbrella product overview: the whole yearbook arc — write, design, photograph, proof, print, sell, give, read — on one platform and one roster per school. The wide view of what this modular door is one entrance into.
schoolyearbook.software
The single-school, run-it-yourself product page — the same program described for any school, with no rep and no contract. This modular door leads on the compose-per-copy build; that is the general single-school view.
homeroom.software
The flagship platform brand home: the full platform story behind the modular build a school runs. This page is part of the same family.
What is built and what is honest-off
The modular build an adviser runs — the composition of a book from modules (shared spreads plus per-child modules), the pure deterministic engine that resolves a byte-identical copy from the same inputs, the per-copy print lane with its fail-closed check that a printer declares variable-data and per-copy-unique output, the per-copy PDF compose and merge with no model in the path, the family-authored personal module gated by a fail-closed content-safety scan and an adviser lock, the consent and publication-suppression sweep that runs before every render, and the adviser master-control that keeps enable, build, and lock with the staff — is built and running today. The order rails are built. What is honest-off is, first, the AI face-matching auto-fill: the face model that would pre-fill a copy from a face match is operator-gated and not wired, so every copy composes roster-tag-only in a labeled roster-only lane, never a faked face-group; and second, the live payment rails — live charge and checkout are off, so an adviser reserves and expresses interest today rather than charging a card, and no card has been charged here yet. Consent is load-bearing: the school owns its children’s and families’ data and it is never sold or shared; data involving minor children is consent-gated and can be withdrawn at any time; minor child data runs on private systems and is never made public; photos are matched by roster lookup, and facial recognition is off by default and never auto-tags a child. The platform is free for the school to run, with no contract and no rep, and the school brings its own capable printer. This is a for-profit product; no tax-deductible or charitable claim is made anywhere. No competitor brand names appear here. Pricing and checkout are not on this page.