Yearbook Media · the media library behind the book
All the media a yearbook needs, organised on one roster.
A yearbook is thousands of pieces of media — portraits, event photos, captions, coverage, and the copy that ties a spread together — and the hard part is not making any one of them, it is keeping all of them organised and accounted for. Yearbook Media is the content-management side of the platform: a media library where every photo is bound to a student record off the school roster, captions and copy move through a real editorial workflow, and a coverage-gap report shows what still needs covering before the deadline. Privacy rides with the media: photos and face data are never sent to an outside AI or photo company, a photo is matched to a student by a roster lookup rather than a face match, facial recognition is off by default, and a photo is publishable only when consent on file allows.
The photo-to-book flow is at yearbook.photos; the newsroom editorial workflow that produces captions and copy is at yearbook.news; the whole platform is at yearbook.software. The platform is free for the school to run, and there is no checkout on this page — this is content management, not commerce.
Managing the media — what is built
The library, the editorial workflow behind captions and copy, the coverage tracking, the consent-gated intake, and the workspace resilience are all built and live today. This page is content management; the money rails live elsewhere and stay honest-off.
A media library bound to the roster
Every photo in the library is bound to a student record off the school roster — by name, grade, and homeroom — so the library is organised by the same records the book is built on. A staff can find every photo of a student, a homeroom, a team, or an event without hunting through folders. The media is one shared set the whole platform reads from, not a copy made for each product. Shipped
Captions and copy through a real editorial workflow
The words in the book are not typed in at the last minute. Captions and copy move through the newsroom story lifecycle — pitched, assigned, reporting, drafting, content edit, copy edit, design, editor-in-chief sign-off, adviser review, published — with staff roles scoped at the data layer. A caption is edited, checked, and signed off, not left to memory. The story lifecycle engine is built and live; it goes deep at yearbook.news. Shipped
Coverage tracking against the roster
Because every photo is tagged to a student, the platform can answer what a shoebox of files cannot: what is not yet covered? A coverage-gap report shows which students, homerooms, teams, and clubs are not yet on a spread, before the deadline rather than after the printer runs. Coverage is a report against the roster, not a tally someone keeps by hand. The coverage-gap engine is built and live. Shipped
Staff submissions, consent-gated at intake
Photos from the whole staff — the assigned photographers, the section editors shooting an event — come into the same library and are bound to the roster at intake. Each photo carries the student it belongs to and the consent record that governs it. A photo without publish consent is held for the school’s own use and kept out of any public or purchasable place. Intake and consent binding are built and live. Shipped
Identity by roster lookup, never a face match
Media is associated to a student by a roster lookup — the same name, grade, and homeroom the gradebook uses — never by a face match. That standard path computes no biometric template. Face matching is a separate per-child opt-in feature that is off by default across the whole platform and is never used to auto-tag a child’s photo without an explicit per-child opt-in from that child’s parent; when a parent turns it on, the face template is held only inside our own private system, with no outside recognition service connected. The school sets a face-data retention window — 365 days by default — and that window is what marks a template due for destruction. Withdrawing the opt-in stops the matching. The step that destroys the stored template is not finished, and we are not going to tell you it runs nightly when it does not. Roster lookup shipped · template destruction not finished
Autosave and recoverable versions on the media
The book lives in a resilient online workspace, so as media is placed and captions are written, every change autosaves and any saved state is recoverable. A crashed lab computer loses nothing, and a bad edit to a caption or a mis-placed photo can be rolled back without losing the work that came after. The autosave and version-recovery engines are built and live; the deep dive is at yearbook.cloud. Shipped
How a piece of media moves through the library
The library is easiest to read as the path of a single item — a photo and the caption beside it — from intake to the finished spread. Each step runs on the step before it.
- Media comes in and is bound to the roster. A photo enters the library on our own private system and is bound to the student it belongs to by name, grade, and homeroom. It is not sent to an outside AI or photo company and not placed in a shared vendor pool. There is never a need to run facial recognition to make the association.
- Consent is recorded with the item. The consent gate reads the student’s consent record and travels with the photo. A photo without publish consent stays out of any public or purchasable place; the gate is fail-closed, so an absent record is treated as no consent.
- Copy is written and edited through the workflow. The caption or story moves through the editorial lifecycle — drafted, content-edited, copy-edited, signed off by the editor-in-chief, reviewed by the adviser. The words are checked before they reach the page, and each role is scoped so no one overwrites another section.
- Coverage is tracked while it can still be fixed. The coverage-gap report shows which students and groups are not yet on a spread. A staff chases a missing photo or an uncovered event before the deadline, not after.
- Media is placed, autosaved, and versioned. Photos and captions are placed in the production editor on the resilient workspace. Every change autosaves and any saved state is recoverable, so a mistaken edit rolls back and a dead lab computer loses nothing.
- The adviser proofs and print preflight runs fail-closed. The adviser reviews the spreads and approves; print preflight blocks a page from going to press if a photo is missing or a consent gap is open. Nothing reaches the printer that should not be there.
The media library, in detail
A yearbook staff spends more time finding and accounting for media than making it. The library is built to take that work off them.
Organised by the records the book uses
The library is keyed to the same roster the book is built on, so a photo is filed by the student, homeroom, team, or event it belongs to — not by a filename someone remembered to set. A staff can pull every photo of a student for their senior page, or every photo of a game for the sports spread, from the records the platform already agrees on.
One shared set, not a copy per product
The same media set feeds the book, the directory, the ID composites, and the team photos through one shared record. A photo edited or replaced once is the version every surface uses. There is no re-import for each product and no drift between the copy the book uses and the copy the directory uses.
Captions carried with the media
A caption is not a floating text box; it is copy that moved through the editorial workflow and is carried with the media it describes. A photo and its checked, signed-off caption travel together, so the words on the page were edited before they got there rather than typed under deadline pressure.
Consent and ownership travel with every item
Each item carries the consent record that governs it, and the whole library is owned by the school and never sold or shared with outside companies. A student’s media is never visible outside the school tenant that owns it, and minor student data runs on private systems and is never made public. Consent can be withdrawn at any time.
Coverage tracking: knowing what is missing before June
The oldest failure in a yearbook is a student who never made it into the book, discovered after the printer has run. Coverage tracking is built so that gap is visible while there is still time to close it.
Because every photo and every caption is tied to a student off the roster, the platform can report what is not yet covered: which students are not on a spread, which homerooms are thin, which teams and clubs are still missing a photo. The coverage-gap report is a live query against the roster, not a headcount a staff keeps in a spreadsheet, so the answer is current the day a staff asks it.
That turns coverage from a June regret into a March task. A staff schedules a retake for the missing portrait, assigns a photographer to the uncovered club, and writes the caption that a spread still needs — all while the deadline is ahead of them. The coverage-gap and roster-tagging engines are built and live; season-long coverage and distribution day go deep at yearbook.events, and the editorial workflow behind the copy goes deep at yearbook.news.
Common questions
How is this different from yearbook.photos?
yearbook.photos is about the photo pipeline specifically — how picture-day portraits and event photos flow from capture into the book. Yearbook Media is broader: the whole media library that fills a yearbook, including the captions and copy through the editorial workflow, the coverage tracking, and the staff submissions, not only the photos. If you want the photo-to-page flow, start at yearbook.photos; if you want to manage all the material a book needs, you are in the right place.
What counts as “media” here?
The photos in the book — portraits, candids, and group / club / sports photos — and the words that go with them: captions and the copy that ties a spread together. All of it is organised in one library keyed to the school roster, so a photo, the student it belongs to, and the caption beside it are managed as one connected set rather than scattered files and floating text.
Can parents or students upload their own photos here?
This page describes staff-side media management: photos come in from the assigned photographers and the section editors shooting events, bound to the roster and consent-gated at intake. We describe what is built rather than implying a general public upload portal. Families interact with picture-day photos through the consent-gated gallery on the picture-day program at pholio.photos, not through this library.
How do captions and copy get written and checked?
Through the newsroom story lifecycle: a caption or story moves from pitched to assigned to reporting to drafting to content edit to copy edit to design to editor-in-chief sign-off to adviser review to published, with staff roles scoped at the data layer. The words are edited and signed off before they reach the page. The editorial workflow is built and live and goes deep at yearbook.news.
How does coverage tracking work?
Every photo and caption is tied to a student off the roster, so the coverage-gap report can show which students, homerooms, teams, and clubs are not yet on a spread — before the deadline. It is a live query against the roster, not a manual tally, so a staff can chase a missing photo or an uncovered event while there is still time to fix it.
Does the media get sent to an outside AI system?
No. Photos and any face data run on our own private system. Media is never sent to an outside AI service, an ad network, a data broker, or a shared vendor environment. Editing and storage happen on infrastructure we operate. An outside print lab receives only the minimum required to fulfill a specific order a family placed.
Is facial recognition used to sort the library?
No. Media is associated to a student by a roster lookup — name, grade, homeroom — never by a face match. That standard path computes no biometric template. Face matching is a separate per-child opt-in feature that is off by default; when a parent opts their own child in, the face template is held only inside our own private system, with no outside recognition service connected. The school sets a face-data retention window — 365 days by default — and that window is what marks a template due for destruction. Withdrawing the opt-in stops the matching. Destroying the stored template itself is a step we have not finished, so we do not claim it happens on a schedule; the cleanup job halts and raises an alert rather than record a deletion it cannot carry out.
What keeps an un-consented photo out of the book?
The consent gate, which travels with each item. A photo is publishable only when consent on file allows, enforced in code, per subject, fail-closed. A do-not-publish student or an under-13 student without guardian consent is held for the school’s own use and suppressed from any public or purchasable place. An absent record is treated as no consent.
What happens to the media if a lab computer crashes?
Nothing, from the library’s perspective. The book lives in a resilient online workspace where every change autosaves and any saved state is recoverable. The authoritative copy is in the workspace, not on the device, so a student opens another machine and continues from the last saved state. The autosave and version-recovery engines are built and live.
What does this cost a school to run?
Nothing to run. The platform is free for the school — no subscription, no per-student fee, and no setup charge. This page is content management, not commerce; there is no checkout here. This is a for-profit product and makes no tax claim of any kind. When live selling is enabled elsewhere, the platform is funded on the sale side, never by charging the school.
Related surfaces
The media-management door connects to the photo flow, the newsroom, the picture-day program, and the umbrella overview. These destinations cover the adjacent surfaces.
yearbook.photos
The photo-to-book flow: how picture-day portraits, candids, and group / club / sports photos move from capture into the spreads. The photo side of the same roster-bound media set.
yearbook.news
The newsroom editorial workflow: the story lifecycle that produces the captions and copy managed here, and the reporting that feeds both the book and a live news site.
pholio.photos
The picture-day program itself: the privacy-first front door for families and schools, the consent gate, and the roster-lookup family gallery that governs the photos in the library.
yearbook.software
The umbrella platform overview: write, design, photograph, proof, print, sell, give, and read, off one roster. Where the media library fits into the whole book.
What is built and what is honest-off
The media library bound to one roster, the editorial workflow behind captions and copy, the coverage-gap report, the consent-gated staff intake, the roster-lookup identity with no biometric template and no face match, and the resilient workspace with per-edit autosave and recoverable versions are built and live today. Photos and face data are never sent to an outside AI or photo company; facial recognition is off by default and never auto-tags a child without an explicit per-child parent opt-in. The consent gate is fail-closed and per-subject: a photo is publishable only when consent on file allows. The parts of the platform that move money — the sell and giving checkout — are honest-off, founder-gated and not enabled for live transactions; this page is content management, and no card is charged here. Student media is owned by the school, never sold or shared; minors’ data is consent-gated and never public. The platform is free for the school to run. This is a for-profit product and makes no tax claim. No competitor brand names appear here.
Yearbook Media is the content-management side of the same platform — one consented student record underneath, from Stanley Studios.