Surfaces · Schedule.software
Eight places a person books something. One engine underneath all of them.
A “surface” here means a real place in a school or studio’s week where somebody takes a slot: a family picking a picture-day sitting, a parent taking a conference time, a caretaker reserving the gym. Each one has its own rules about who is entitled to book and what the record is allowed to hold — and each one is the same slot primitive composed into a different context.
The status on each is the honest one. Six of the eight run in production; two are built and module-dark, meaning the code is finished and gated behind a module-enable flag rather than shipped on by default.
All eight at a glance — scroll sideways on a narrow screen
Who books, what the record holds, and whether it is on today
| Surface | Who books on it | What the record holds | Status |
|---|---|---|---|
| Picture-day family booking | A guardian, for their own child | Slot, capacity, booking state | Built · production-ready |
| Parent-teacher conferences | A guardian, against staff-published hours | Published-minus-booked slots, an opaque .ics feed | Built · production-ready |
| Admissions interviews & tours | An admissions owner, for a prospective family | An opaque lead reference — no student census | Built · production-ready |
| Academic master schedule | A scheduler, reviewed by a human before it commits | A proposed timetable and what it could not place | Built · module-dark (advisory only; no eligibility gating) |
| Volunteer & student-helper shifts | A volunteer or student helper, per shift | Shift claims, gated on verification status | Built · module-dark (unverified = no student-contact, fail-closed) |
| Staff & substitute scheduling | An administrator, HR-gated | Staff and substitute assignments | Built · production-ready (HR-gated) |
| Photo-crew dispatch | A studio owner, for their own crew | Jobs, assignments, credential facts about adults | Built · production-ready (route optimization advisory) |
| Facilities & resources | Booking staff, for rooms and equipment | Resources and their windows — never a public roster | Built · production-ready |
The column worth reading twice is the third one. A scheduling product’s risk is not in what it does, it is in what it accumulates: the admissions surface owns no student census at all, the crew dispatch surface holds employment facts about working adults and no student data, and the facilities calendar holds rooms rather than people. The narrower each row is, the less there is to lose. The privacy page takes that inventory apart in full.
Surface by surface — the whole description, not a summary card
What each one actually does
Picture-day family booking — open slots, live remaining capacity, family-walled
Built · production-ready
A guardian opens the booking surface and sees time slots with real remaining capacity: “3 of 4 left,” “full,” or “1 of 4 left.” They book, reschedule, or cancel. A cancel frees the slot to re-book immediately. No double-booking is possible: a partial-unique index on the appointments table enforces the invariant at the database — two families racing the last slot both get a clean, retryable conflict, never a silent over-book. Per-slot capacity is counted under a lock inside the same transaction that books, so a slot never over-fills even under concurrent requests. The family wall holds throughout: the student ID comes from a hash-verified claim, not from the request body — there is no roster to browse, no other family’s child to touch. Picture-day family booking is built and production-ready.
Parent-teacher conference booking — staff publish availability, families book, .ics with no names
Built · production-ready
Staff publish their open hours; the slot list a guardian sees is published-minus-booked. A guardian books for their own student: the engine confirms the slot is open, the family wall holds, no double-booking occurs. A subscribable .ics calendar feed delivers the schedule with opaque labels — never a student’s or teacher’s name in the SUMMARY or ORGANIZER fields, only a non-PII handle. Staff see all bookings in the feed; a guardian sees only their own. Parent-teacher conference booking is built and production-ready.
Admissions interview and tour booking — recruitment funnel on the same slot engine
Built · production-ready
An admissions owner publishes interview and tour slots; a prospective-family lead is booked into an open slot on the recruitment funnel. The same canonical slot/booking/availability engine that drives conferences and picture day drives admissions — one primitive composed into a third context. The lead reference is opaque; this surface owns no student census and is gated on the tenant and an injected admissions-owner predicate. Admissions interview and tour booking is built and production-ready.
Academic master schedule — advisory, conflict-minimized, never enrolls on its own
Built · module-dark (advisory only; no eligibility gating)
The advisory master schedule proposes a conflict-minimized timetable and explains what it could not place — you review and commit; the engine never enrolls students on its own. A what-if surface lets you model changes and diff the impact before committing. When an enrollment runs, the conflict classifier checks for period clash, full seat, and duplicate before placing anyone, with a machine reason on the 409 — never a silent over-enroll. Rosters are consent-aware: a suppressed student’s name and grade are stripped at the roster route; the row still counts, only the identity is masked. This surface is module-dark and requires enabling the scheduling module. Prerequisite or grade-eligibility gating is not wired and is not claimed here. The academic master schedule is built and production-ready behind its module flag.
Volunteer and student-helper shift scheduling — capacity, waitlist, approval sign-off
Built · module-dark (unverified = no student-contact, fail-closed)
Library, clubs, athletics, and events consume the same volunteer scheduling engine through an owner-context discriminator — no separate fork per arm. Shifts have capacity, a waitlist, and a draft→submitted→signed approval lifecycle. An unverified volunteer cannot be assigned to a student-contact shift: the screening decider is fail-closed. A consent chokepoint strips a suppressed helper’s name and hours from the roster view. This surface is module-dark and requires enabling the volunteer scheduling module. Per-state legal sufficiency of a background check is not modeled and is not claimed here. Volunteer and student-helper shift scheduling is built and production-ready behind its module flag.
Staff and substitute scheduling — HR-capability gated, server-resolved identity
Built · production-ready (HR-gated)
Staff and substitute scheduling is HR-capability gated from the server: the scheduling identity is resolved from the server-side context, never from a client-supplied claim. A server-side capability gate decides access; the check runs on the server, not a feature flag a client request can disable. The surface is staff-coupled and never touches the student census. Staff and substitute scheduling is built and production-ready.
Photo-crew dispatch — credential-gated assignments, self-healing reschedules
Built · production-ready (route optimization advisory)
Studio crew dispatch is built around the school photography calendar — picture day, retakes, sports, events, senior sessions, graduation. The job-type taxonomy lives in the schema, but the dispatch store does not yet persist it distinctly, so this page does not advertise a count the round-trip would not preserve. Assignments are credential-gated: expiry must exceed the scheduled date, district must match, and verified must be true — the gate throws before any write, and the same gate re-runs on an open-shift claim with an atomic single-winner check. Self-healing reschedules propose minimal-cascade changes for weather, closure, lockdown, sick crew, or school request — ranked proposals for human ratification. Route optimization runs for the working-day dispatch (heuristic greedy default); an external optimal-solver seam is available but is not claimed as live. Photo-crew dispatch scheduling is built and production-ready.
Facilities and resource booking — rooms, gyms, fields, auditoriums, equipment
Built · production-ready
Book rooms, gyms, fields, auditoriums, and equipment against a shared availability calendar. Double-booking is fail-closed: the booking engine checks for overlapping windows using the canonical half-open [start, end) predicate; a malformed instant fails closed. Back-to-back bookings are legal; overlapping bookings are not. Resource kinds include room, field, gym, auditorium, equipment, and other. The availability view is authorized-only — never a public room roster. Statuses are held, confirmed, and cancelled. Facilities and resource booking is built and production-ready.
Where this goes next
Surfaces are the shipped implementations. Modules are the taxonomy.
The eight above are what a school or a school-photography studio can run. They are not the whole product: the same engine is organised into seven modules that span the professional segments too — appointment links, business-services booking, room and resource management, field-service dispatch and routing, workforce shifts, events and reservations, and personal and family scheduling. Surfaces are the K-12 and studio implementations that exist today; modules are how the same primitives are packaged for everyone else. Two axes, one engine, and the modules page is honest about which of the seven are finished.
If you want to see the flow that all eight share, the how it works page walks the four steps and lets you work through the slot arithmetic yourself.