Yearbook Events · Coverage + distribution · Early access · 2026

Cover every event all year — then match every book to a paid student on distribution day

Yearbook Events runs the operational work on both ends of the yearbook year. From September: every dance, game, concert, and club meeting uploads to a coverage log, photos tag to students from the roster, and spreads fill with the right material as the year goes. In spring: a coverage-gap report catches students the staff missed before deadline. And at the end: a distribution-day check-in list at the door matches each book to a paid student so nothing leaves without a roster match. Early access — no pricing commitment, no signup, no live checkout today.

Book a conversation How it works

Coverage logevery event photographed, multiple staff uploading to one record per event

Roster taggingphotos tagged from the roster — facial recognition off by default, never auto-on

Coverage-gap reportstudents with too few tagged photos surface before deadline, not after

Distribution-day check-incheck-in list at the door — every book matched to a paid student, real-time count

The season-long coverage workflow — from first upload to spread

Every event, every photographer, every tagged photo — one coverage log for the whole year

A yearbook staff covers dozens of events across the school year. The homecoming game, the winter formal, the spring musical, the state championship, the senior sunrise, the graduation rehearsal — each one needs photographers assigned, photos uploaded, students tagged, and the right spread filled before deadline. Without a systematic log, the work accumulates in shared drives, personal phones, and messages to the adviser asking which photo goes where.

The event-capture engine gives every event its own coverage record. Multiple photographers upload to the same event; their work merges into one pool. Each photo is tagged to the students in it from the school roster — not by facial recognition, but by a photographer selecting names from a list. The tag connects the photo to that student’s coverage record. When a page editor opens the homecoming spread, the photos already tagged to those students are there. The event-capture engine and roster-tagging engine are built and production-ready.

Before deadline, the coverage-gap report runs on the tagging data. It lists every student with fewer tagged photos than the minimum the adviser has set — a concrete, actionable list, not a vague sense that the staff may have missed some people. The report is adviser-only analytics: names and counts, never a surfaced photo. A student whose family has not consented to publication is still counted here — so the adviser sees the coverage gap honestly instead of the student silently vanishing from it — but that student’s photos are never offered as candidates for a spread, and the student never appears on a published page without consent. From the publishable part of that list the adviser plans a targeted catch-up shoot; the consent rule is enforced in the engine, not by a reminder.

Book a conversation Distribution day

Distribution day — the last event of the year

A check-in list at the door — every book matched to a paid student before it leaves the building

Distribution day is the most operationally complicated day of the yearbook calendar. Boxes of books arrive. Students line up. Advisers and volunteers hand them out. Without a check-in system, books go to students who didn’t pay, or students who did pay leave empty-handed because their name wasn’t on a list anyone could find. A manual spreadsheet printed the morning before is already out of date before the bell rings.

The distribution-day check-in list solves the match problem. Every student with a confirmed order appears on the list, linked to their roster record. A volunteer at the door finds the student by name or student ID, marks the pickup, and the book goes home with the right person. The list shows remaining stock in real time as pickups are marked — the adviser knows how many are left without counting boxes. Students who did not order are not on the list; no book leaves without a roster match.

The check-in list and the roster-matched pickup record are built. The book-ordering checkout — the payment rail a family uses to order a book — is honest-off: present in the platform, not enabled for live transactions today. When the payment rail is enabled, confirmed orders flow directly into the distribution-day list. No separate import, no manual reconciliation between a payment system and a spreadsheet.

How it works

The yearbook year in four stages

Yearbook Events runs on the school calendar: setup and consent before the first event, coverage and tagging throughout the year, a coverage-gap catch-up before deadline, and distribution day at the end. Every stage is described as it is built today.

Step 1 · Year start — event schedule, photographer assignments, and consent

Before the first event, the adviser sets up the event schedule for the year: every homecoming, every home game, every concert and performance, every club induction. Photographers are assigned to event types or specific dates. Depiction consent is collected per student — a family opts in before any student’s photos are included in the shared book. Families who do not opt in are excluded from the shared edition from the start; the rule is enforced in the consent engine, not in a spreadsheet. The school owns its roster and consent records from day one.

Step 2 · Throughout the year — events happen, photos upload, spreads fill

After each event, photographers upload directly to the coverage log. Photos are tagged to students from the roster by a photographer or adviser — roster-driven selection, not facial recognition. Each tagged photo lands in the right student’s coverage record. Page editors pick from the coverage log to fill spreads; as more events are covered, more material accumulates for each section. The adviser sees a running view of how much of the year has been captured, by event type and by student.

Step 3 · Pre-deadline — coverage gaps surface, spreads lock, proof goes to printer

Before deadline, the coverage-gap report surfaces students with too few tagged photos — a list the adviser can hand to the photo team for a targeted shoot day before pages lock. Once spreads are finalised, a proof link goes to the printer without the staff having to export a large file and hope the colours survive the conversion. Unconsented students remain excluded from the proof and from the final printed edition. The gap report and proof output are built and production-ready.

Step 4 · Distribution day — check-in at the door, every book matched to a paid student

The final event of the year. The distribution-day check-in list shows every student with a confirmed order, matched to the roster. A volunteer at the door marks each book as picked up when the student collects it. Students without a confirmed order do not appear on the list. The check-in list keeps a real-time count of remaining stock as pickups are marked. The book-ordering checkout (the payment rail) is honest-off today; when it is enabled, orders flow directly into this list.

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. In development means the surface, wire-up, or payment integration is in active build. We do not claim otherwise.

Season-long event coverage — every school event photographed and logged

The event-capture engine lets any photographer on the staff upload directly from a school event: the homecoming dance, the spring musical, the championship game, a club induction, a pep rally, a senior sunrise. Each upload carries the event name and date; the photos go into the coverage log for that event and stay on our own private system. Multiple photographers can cover the same event simultaneously — their uploads merge into one coverage record. An adviser sees the running log of events covered across the year: a concrete record of how much of the school year the staff actually captured. The event-capture engine is built and production-ready.

Built · production-ready

Roster tagging — every photo connected to the right student, from the roster

Tagging connects a photo to the students in it using the school roster — a photographer or adviser selects names from a roster list for each frame. Facial recognition is off by default and is never used for automatic tagging unless a parent explicitly enables it for their own child. The tag connects the photo to that student’s coverage record, not to a public profile and not to any outside company’s system. All photos stay on our own private system. A tagged photo is access-controlled: never visible to other families, never public, and revocable at any time if a family withdraws consent. The roster-tagging engine is built and production-ready.

Built · facial recognition off by default

Spread assignment — tagged coverage flows to the right page as the year goes

When a spread covers the homecoming court, the photos already tagged to those students are waiting for it. A page editor picks from the coverage log for that event; the roster connection means the right photos surface first. As deadline approaches, the coverage-gap report surfaces students with too few tagged photos — a named list the adviser can hand to the photography team for a catch-up shoot day, not a surprise in the final week. An adviser can see at a glance which events produced the most coverage and which students the staff has missed across the year. The spread-assignment and coverage-gap engine is built and production-ready.

Built · coverage-gap report included

Distribution day — a check-in list that matches each book to a paid student at the door

Distribution day is an event too — and the last one of the year. A check-in list shows which students have a book coming, matched against the school roster. A volunteer at the door works through the list: the student presents their ID, the volunteer marks the pickup, the book goes home. No book leaves without a roster match. The check-in list keeps a real-time count of remaining stock as pickups are marked — the adviser knows exactly how many are left without a manual count. The check-in list is built, along with the roster-matched pickup record. The payment rail that processes book orders — the checkout a family uses to buy a book — is honest-off: present in the platform, not enabled for live transactions today. When the payment rail is enabled, confirmed orders flow directly into the distribution-day list.

Check-in list built · ordering checkout honest-off

What gets covered

Every event type on the school calendar — one coverage workflow for all of them

Dances and social events

Homecoming, prom, winter formal, senior night — events with large student attendance and multiple photographers shooting simultaneously. Uploads from three photographers at the same dance merge into one coverage record. A page editor filling the homecoming spread picks from the full merged pool, with roster tags already in place from the photographers who were there.

Athletics and competitions

Home games, championship runs, away games the staff travelled to cover. Each game is its own event in the coverage log, with its own photographers and its own upload. A sports spread pulls from the game-by-game log: action shots already tagged to players from the roster, grouped by event so the editor sees the championship game separately from the regular season.

Performances and school life

Spring musical opening night, fall play, concerts, pep rallies, graduation, club inductions, spirit days, senior sunrise, class trips — the events that fill the sections no one forgets at the ten-year reunion. The event schedule is set by the adviser: any named event the school recognises can be added, dated, and assigned photographers. The coverage log and roster tagging work the same way for every type.

Consent and student data

Your school’s student data. Consent-gated. Exclusion enforced, not suggested.

Depiction consent is collected per student before any photo is included in the shared book. A family that does not opt in has their student excluded from every shared surface: the digital edition, the proof, and the distribution-day check-in. Excluded means excluded — not a blurred photo, not a blank placeholder, not a note. The exclusion is enforced at the consent engine’s data layer, not by policy reminder.

Student photos are owned by the school and are never sold or shared with outside companies or advertisers. All photos stay on our own private system: never hosted on a public photo platform, never passed to a third-party facial recognition service. A tagged photo is access-controlled — never visible to other families, never public. Consent can be withdrawn at any time; every change is logged. If the school ever leaves the platform, the roster, the coverage records, and the consent log leave with it — in the onboarding agreement, not a footnote.

What is built and what is coming — plainly

The coverage engines are built. The ordering checkout is not live yet.

Built and production-ready today: the event-capture engine (photo upload from any event, multi-photographer merge, running coverage log); the roster-tagging engine (roster-driven tag selection, facial recognition off by default, access-controlled photos on our own private system); the spread-assignment and coverage-gap engine (tagged photos waiting for the right spread, gap report before deadline); the distribution-day check-in list (roster-matched pickup, mark-as-collected per student, real-time remaining count); and the consent gate (per-student opt-in, exclusion enforced at the data layer, revocable, ledger-logged).

Not yet enabled for live use: the book-ordering checkout (the payment rail that processes a family’s order), and the live scan-and-pay interface at distribution day. These are honest-off — present in the platform, not enabled for live transactions. There is no live checkout here, no billing, and no subscription. We say so directly because yearbook advisers deserve to know what is production-ready and what is still being wired.

Connected to the yearbook programme

The coverage feeds the book. The book becomes the record. The record lives on the platform.

Yearbook Events covers the events and manages distribution day. yearbook.press is where the finished publication lives: the layouts, the typography, the print-ready pages that the coverage feeds into. yearbook.cloud is the collaborative workspace: the always-online environment where multiple editors hold different spreads without overwriting each other. Assembly captures the live moments behind the photos: the concert, the game, the ceremony — the context a printed page can only hint at. Seen ensures every student lands on a real page in the book and in the programme — adviser-approved and consent-verified. The full platform is at homeroom.software.

yearbook.press yearbook.cloud assembly.school seen.school

Early access · Yearbook advisers, editors, and coordinators

Book a conversation to see the current state honestly

Yearbook Events is in active development. We do conversations that show the current state honestly: how the event-capture engine receives an upload and tags it to the roster; how the coverage log shows gaps before deadline; how the spread-assignment surfaces the right photos for the right page; and how the distribution-day check-in list matches books to paid students at the door. There is no pricing commitment and no signup. If it looks right for your programme, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

How is yearbook.events different from the rest of the yearbook programme?

The yearbook programme has several angles. The finished publication — the layouts, typography, and print-ready pages — lives at yearbook.press. yearbook.events is the operational story behind the content that fills those pages: the season-long coverage workflow that turns every school event into tagged photos in the right spread, and the distribution-day logistics that get the printed book from the box into the right student’s hands. Two things the rest of the programme doesn’t address specifically: the running coverage log across the whole school year, and the check-in list at the door on distribution day.

How does photo tagging work — is it facial recognition?

No. Facial recognition is off by default and is never used for automatic tagging unless a parent explicitly enables it for their own child. Tagging works from the school roster: a photographer or adviser looks at a frame and selects the students in it from a roster list. The roster connection means the right names are available without any face-matching technology running in the background. There is no automatic tagging by face on any image unless a parent has opted in for that student specifically — and that opt-in is per-student, not a platform-wide setting. The roster-tagging engine is built and production-ready.

Can multiple photographers cover the same event?

Yes. Multiple photographers can upload from the same event simultaneously — for example, the homecoming game might have three staff photographers shooting different areas at the same time. Their uploads all merge into the same event’s coverage record. An adviser sees the combined total for that event in the coverage log. A page editor filling the homecoming spread picks from the full merged pool. The multi-photographer merge is built into the event-capture engine.

How does the distribution-day check-in work?

Distribution day runs on a check-in list matched to the school roster. When a student arrives to collect their book, a volunteer finds them on the list by name or student ID and marks the pickup. The student gets their book; the record shows it as collected. Students without a confirmed order are not on the list — no book leaves without a match. The check-in list shows remaining stock in real time as pickups are marked, so the adviser knows exactly how many are left without doing a manual count of the box. The check-in list and roster-match engine are built. The book-ordering checkout (the payment rail that processes a family’s order) is honest-off: present in the platform, not enabled for live transactions today.

Is book ordering or checkout live? Can families buy a book now?

Not yet. The check-in list, the coverage workflow, the roster-tagging engine, and the coverage-gap report are all built and production-ready. The payment rail — the checkout interface a family uses to order a book and pay — is honest-off: present in the platform, not enabled for live transactions today. There is no live checkout, no billing, and no subscription. When the payment rail is enabled, confirmed orders flow directly into the distribution-day list. The CTA here is “book a conversation,” not “order now.”

What happens to a student who hasn’t given depiction consent?

They are excluded from the shared book entirely — not hidden behind a blurred photo, excluded. Their photos do not appear in any spread that goes to other families. The exclusion is enforced in the consent engine at the data layer: the spread-building tool does not make unconsented students’ photos available for placement. It is not a guideline or a reminder — it is a rule the engine enforces. The same rule applies to the digital edition, the printed proof, and the distribution-day check-in. Consent is collected per student, revocable at any time, and every change is logged.

How do coverage gaps get caught before deadline?

The coverage-gap report runs before deadline. It lists students who appear in fewer tagged photos than the adviser’s minimum threshold, and it can be grouped by year, section, or club. The adviser hands the list to the photography team for a targeted catch-up shoot before pages lock. The report is the coverage log seen from the other direction: instead of showing what was captured, it shows what the staff still needs. The gap report is built alongside the spread-assignment engine and runs on the same roster-linked tagging data.

Who owns the student photo data and the coverage records?

The school owns its roster, its coverage records, and its consent log. No student photo is ever sold or shared with outside companies or advertisers. All photos stay on our own private system — never hosted on a public photo platform, never passed to a third-party facial recognition service. A tagged photo is access-controlled: never visible to other families, never public. If the school ever leaves the platform, the coverage records and consent log leave with it — that guarantee is in the onboarding agreement, not a footnote.

What event types does the coverage workflow support?

Any named event the school runs: dances (homecoming, prom, winter formal), athletic games (home games, away games, any sport), performances (spring musical, fall play, concert, pep rally, graduation), and regular school-life events (club inductions, spirit days, senior sunrise, class trips). The event schedule is set by the adviser — it is not a preset list. An adviser names the event, dates it, and assigns photographers to it. The coverage log and roster tagging work the same way for every event type.

What can we actually use right now?

The platform is in active development. In a demonstration we walk through the current state honestly: the event-capture engine receiving an upload and tagging it to students from the roster; the coverage log showing events covered and gaps; the spread-assignment showing tagged photos waiting for the right page; the coverage-gap report before a deadline; and the distribution-day check-in list matched to the roster. None of that involves live payments today. A conversation is the honest next step — we show what is built, what the ordering and checkout timeline looks like, and what early access means for your programme.

When is the platform available?

The platform is in active development. The event-capture engine, the roster-tagging engine, the spread-assignment and coverage-gap engine, the distribution-day check-in list, and the consent gate are built and production-ready. The book-ordering checkout — the payment rail that processes a family’s order — is honest-off: present in the platform, not enabled for live transactions today. There is no live checkout here, no billing, and no subscription. The best next step is a conversation where we show the current state honestly and discuss what early access looks like for your programme.