Modules
The modules of the toolchain: what is built and what is early access
The photography program runs as a chain of modules, each keyed off the roster. The first six are shipped and running. The last two are partially shipped: the order infrastructure is built but live payment is honest-off, and delivery tracking beyond the order ledger plus outside-lab routing are early access. Each is marked honestly.
Roster import — the module every other module keys off
The toolchain starts from the school roster. A school imports its roster in the format its student information system exports; every later module resolves to a roster identifier. A gallery is a roster match, an order is placed against a roster record, and the pro-lab export is keyed by roster line. The roster is the spine of the whole program — a student who is on the roster can have a gallery, an order, and an export; a student who is not on the current roster does not. The school keeps the authoritative roster in its existing system; the toolchain reads it on import. Shipped
Consent gate — enforced at the data layer, not a reminder
A student without a completed consent record does not appear in a family-accessible gallery. That is not a policy note or a checkbox a route can forget — it is enforced in code at the data layer: the module checks the roster record’s consent status before admitting a portrait to any family-facing view. A school administrator sees which students are consent-confirmed and which are pending before the gallery opens. Consent is off by default, collected per student, and withdrawable at any time; a withdrawal removes the student from the shared view. Shipped
Private roster-matched galleries — find by name, not by face
A family finds their child’s photos by entering the child’s roster name — a roster LOOKUP, not a face match. The studio assigns each portrait to a roster record explicitly during upload, and that assignment is the access key. A portrait is never visible to any other family, never indexed in a public view, and never searchable from outside the family and the studio. Facial recognition plays no part in the matching workflow; it is a capability we are building and is not turned on today. Shipped
Team photos, composites, directory, and ID-card composites
From the same roster-matched portrait set, the toolchain builds the derived products a school program needs: team and group photos, class composites, the class directory, and ID-card composites. Each is assembled against the roster, so a name on a composite resolves to the same roster record the gallery and the order use. There is no re-keying between the portrait, the directory, and the ID card — they read the one roster-matched set. Shipped
School-choosable backgrounds — deterministic matting
A school selects its portrait background from a catalog of options: solid tones, school-color-derived backgrounds, and thematic choices. The studio uploads portraits with transparent-alpha cutouts, and the chosen background is composited by a deterministic matting step — the same inputs always produce the same composited portrait. PNG-alpha cutout delivery is available alongside the standard pro-lab JPG for layering uses. Background selection is a module of the toolchain, configured per school at setup. Shipped
PSPA/SPOA pro-lab output — the structured delivery file
At the end of a session the toolchain produces the structured, lab-ready output the school information system and the print lab expect: PSPA (Professional School Photographers of America) and SPOA (School Portrait Order Association) export formats, keyed by roster line. This is the file the school’s system imports for the yearbook and ID cards, and the file the lab reads to produce prints. The pro-lab output module is built and runs from the roster-matched portrait set. Shipped
Order rails / parent store — infrastructure built, payment honest-off
The order rails are built as infrastructure: product selection, the order ledger, and fulfillment tracking are present in the toolchain. The live payment rail that accepts a family’s transaction is honest-off. No card is charged today and there is no live checkout. We name that plainly rather than presenting a live parent store. The ordering surface exists as infrastructure; the payment step is the early-access leg. Early access — live payment rails Early access -- live payment rails
Delivery tracking and outside-lab routing — early access
The built order ledger records what was ordered and where it stands. Delivery tracking beyond that ledger — the family-facing status trail on a shipped order — is early access. Outside-lab routing, the ability for a program to send fulfillment to a print lab of its own choosing rather than the default, is in active development: the routing seam is designed, the production wire-up is in progress. Texted family reminders are in active development as well. Each is named as early access, not presented as live. Early access -- in active development