Book a demo

How It Works

How a photo moves through the toolchain, module by module

The toolchain has a clear data flow. Every module projects forward from the roster; nothing is re-keyed or invented at a later stage.

  1. The roster is imported. The program begins with the school roster, imported in the format the school information system exports. Every later module resolves to a roster identifier, so the same student record carries through the gallery, the order, and the pro-lab export.
  2. Consent is collected and gated at the data layer. Families complete consent per student through the school’s own channels; the toolchain tracks the consent status on each roster record. A student without a completed consent record does not appear in a family-accessible gallery — enforced in code at the data layer, not by a reminder. The administrator sees the consent-confirmed count before any gallery opens.
  3. Portraits are captured and matched to the roster. After the shoot, the studio uploads portraits and assigns each one to a roster record explicitly. That assignment is the access key. There is no face scan in the matching workflow — the match is the studio’s roster assignment, and facial recognition is a capability we are building and is not turned on today.
  4. The chosen background is composited. The school’s selected background — a solid tone, a school-color-derived option, or a thematic choice — is composited onto the transparent-alpha cutout by the deterministic matting step. The same portrait and the same background always produce the same result.
  5. Private galleries open to families. Once portraits are matched and the consent check passes, each consent-confirmed family opens its child’s gallery by searching the roster name. Access is restricted to the family on that roster record; a portrait is visible to no other family and is never placed in a public index. Find-my-child is a roster lookup, not a face match.
  6. Derived products are assembled. Team photos, class composites, the class directory, and ID-card composites are built from the same roster-matched portrait set, so a name on a composite resolves to the same roster record the gallery uses.
  7. Orders are placed against the roster. The order rails present products and record an order against the roster record. The order ledger and fulfillment tracking are built. The live payment rail is honest-off: no card is charged today and there is no live checkout. The order infrastructure runs; the payment step is early access.
  8. Pro-lab output is produced. The PSPA/SPOA export produces the structured, lab-ready file keyed by roster line — the file the school information system imports for the yearbook and ID cards, and the file the print lab reads. Delivery tracking beyond the built order ledger, and outside-lab routing, are early access.