Student ID · For school front offices and district IT · Early access · 2026

Student IDs done in-house — roster-driven cards, one picture-day shoot, no surveillance defaults

Student ID is the in-house student ID card programme built for front offices that are tired of coordinating two separate photo sessions. The headshot for the ID card comes from the same picture-day shoot that delivers portraits for the yearbook — one appointment, one roster match, two outputs. The school designs the card template: your logo, your fields, your layout. Facial recognition is off by default. This is a system for identification, not surveillance. Early access — no live card order, no pricing commitment, no signup today.

Book a conversation How it works

One shootportrait and ID headshot from the same picture-day session — no second appointment

School-controlledyour logo, your fields, your layout — the school owns the card template

Identification, not surveillancefacial recognition off by default — face-matching is opt-in, not a standing capability

Consent-gatedheadshots access-controlled, never public, never visible to other students or families

One picture-day shoot — two outputs, no second appointment

The same session that delivers the yearbook portrait delivers the ID headshot

Most schools running their own ID card programme coordinate two separate photo sessions. One for the yearbook portrait — with the photographer, the lighting setup, and the parent communications. Then a second one for ID headshots, with its own scheduling, its own parent reminder, and its own roster-matching pass to connect each headshot to a student record. Two appointments, two sets of logistics, two matching workflows, and the same students in front of a camera twice.

Student ID collapses that to one session. The photographer runs picture day once. The same roster-matched gallery that delivers the yearbook portrait delivers the ID headshot crop. A front-office reviewer confirms the match in the card production queue — name, grade, and headshot confirmed, ready to generate. The one-picture-day pipeline is built and production-ready.

Consent is part of the same picture-day workflow. A student without documented consent for ID use does not receive a headshot in the ID system — they receive the school’s default placeholder. Consent is not assumed. It is collected during picture-day communications, before the session runs.

Book a conversation Full platform

How it works

The ID card programme in four stages

Student ID runs on the school year: roster setup and template configuration before the year starts, headshots matched at picture day, cards reviewed and generated for production, and a replacement and refresh workflow through the year. Every stage is described as it is built today.

Step 1 · Pre-year — roster import and card template setup

Before the school year opens, the front office imports the student roster and configures the card template. The roster import maps column fields — student name, grade, homeroom, custom identifiers — to card fields in the template editor. The card layout is set at this stage: the school’s logo, the field positions, the headshot crop dimensions, and any secondary data the card needs to carry (library number, activity status, grade year). Once the template is saved, every card generated that year follows it. Consent for ID headshots is collected during picture-day communications, not after the fact.

Step 2 · Picture day — ID headshots matched to the roster in the same session

On picture day, the same shoot that delivers portraits for the yearbook delivers the headshot for each student’s ID card. The photographer’s roster-matched gallery is the source for both: one matched file per student, used for portrait output and ID headshot crop. There is no separate ID-only photo appointment. Consent status is checked before any headshot is associated with a card record — a student without consent does not have a headshot in the ID system. The matching and consent check are part of the live picture-day pipeline.

Step 3 · Card production — review, approve, and generate

After picture day, the front office opens the card production queue: a matched view of every student’s name, headshot, grade, and card fields. A reviewer works through the queue — confirming each match, flagging any headshots that need a retake, and approving the batch for generation. Cards are generated as a print-ready batch output. Students who did not consent to a headshot or who are absent on picture day receive a card with the school’s default placeholder headshot, not a blank card. The review, approve, and generate workflow is built and production-ready.

Step 4 · Ongoing — replacements, mid-year enrolments, and year-end refresh

Lost and damaged cards go through a replacement workflow: the front office retrieves the student’s existing card record, confirms the data is current, and generates a replacement card. Mid-year enrolments are added to the roster and run through the card production queue with a default or deferred headshot until picture day. At year end, the roster is refreshed — graduating students marked out, incoming students added — and the card template carries forward or is updated for the new year. Card records are retained in the access-controlled ledger; no student headshot is visible to another family or student.

The full platform

Five capabilities — honest about what is built and what is in early access

Every capability is labelled honestly: Built means the underlying engine is production-ready. Early access means the surface or workflow is in active development. We do not claim otherwise.

Roster-to-card pipeline — fields from the import, headshots from picture day

The ID card program starts with the same roster import the school already runs: student name, grade, homeroom, any custom fields the front office tracks. Those fields populate each card automatically — no re-keying, no second data-entry pass. The headshot is pulled from the picture-day shoot that delivers portraits for the yearbook; the same session, the same matched file, used for both outputs. A front-office reviewer sees each card before it is finalised: name and photo matched, layout confirmed, ready to generate. The roster-to-card pipeline, the headshot match from picture day, and the review-and-approve workflow are built and production-ready.

Roster-to-card pipeline built · live

School-controlled card template — your logo, your layout, your fields

The card template is not a vendor’s default with a logo upload field added. The school defines the card layout: which fields appear, where the headshot sits, the school logo, the card background, the field labels, and which side of the card carries which information. A template lives at the school level — the same layout applied to every card for that school — or at the programme level for a district running different templates per building. The card design module is built and production-ready. There is no locked template. The school owns the layout.

Card design module built · school controls the template

One shoot, two outputs — portrait and ID headshot from the same session

Running a separate photo appointment just for ID cards is a logistics problem the platform is designed to eliminate. The headshot used on the ID card is drawn from the same picture-day session that delivers the student portrait for the yearbook. One appointment, one set of parent communications, one set of roster matches — two outputs. The ID headshot is cropped and sized for the card format from the same matched file the portrait uses; no second shoot is required. This connection is built and production-ready: the picture-day pipeline that delivers ID headshots alongside portraits is live.

One-shoot workflow built · live

On-card barcode and QR encoding — for check-in, access, and attendance

The barcode and QR encoding engine is built: a card can carry an encoded identifier — student ID number, a school-defined access code, or a roster-matched token — readable by a standard scanner at the library desk, the lunchroom point-of-sale, or an entrance reader. The full front-office workflow for configuring which encoding scheme applies to a card batch, previewing the encoded output on a card layout, and issuing barcoded cards through the standard generate-and-print flow is in active development. On-card barcode and QR encoding is in early access: the encoding engine is built and production-ready; the end-to-end workflow surface is not yet complete for general use. We describe it honestly.

Encoding engine built · workflow surface in early access

Facial recognition off by default — identification, not surveillance

Facial recognition is not a default capability of the ID card programme; it is off by default and requires an explicit, founder-gated enablement step to turn on. The ID card system is built to perform identification — a front-office staff member looks up a student by name or ID number, pulls their card record, and confirms identity — not to run continuous recognition against a camera feed. Student headshots are consent-gated: they are access-controlled, never public, and are not enrolled in a face database — facial recognition is off by default and requires an explicit, founder-gated enablement step to turn on. No headshot is visible to another student or family. The privacy defaults — facial recognition off, consent-gated headshots, access-controlled records — are built into the platform at the data layer, not as policy recommendations.

Privacy defaults built · facial recognition off by default

Who uses it

Built for the front office that runs the programme and the district IT that evaluates the infrastructure

School front offices

The front-office coordinator who runs the ID card programme needs a workflow that does not require a separate photo appointment, does not lock the school into a vendor’s template, and does not make replacement cards a multi-step hassle. The roster import brings in the data already on file. Picture day delivers the headshot. The review queue presents matched name-and-photo cards for approval. Replacement cards are generated from the stored record without a new photo session. Year-over-year, the template carries forward and the roster is refreshed.

District IT and administration

District IT evaluates the infrastructure question: where does student data live, who can see it, and what happens when a student leaves or a family withdraws consent. Student ID records live in an access-controlled system. Headshots are consent-gated and never public. Facial recognition is off by default and requires an explicit enablement step. The full record set — card records, headshots, consent status — is exportable. The school owns its data; the platform does not retain it for any purpose beyond running the programme.

Identification, not surveillance — the privacy posture built into the platform

Facial recognition off by default. Face-matching is opt-in, not a standing capability. Headshots consent-gated and access-controlled.

The decision to turn facial recognition off by default is not a checkbox in a settings menu — it is the platform’s designed posture. The ID card programme is built to answer one question on request: is this the student they say they are? A front-office staff member looks up a student by name or ID number, pulls their card record, and confirms identity. That is the use case the system is engineered for. It is not engineered for continuous recognition against a camera feed, for tracking student movement, or for building a behavioural profile from entry and exit patterns.

The ID card programme does not enrol student headshots in a face database; facial recognition is off by default and requires an explicit, founder-gated enablement step to turn on. No headshot is visible to other students or families. Headshots are access-controlled: only authorised front-office staff can view them through the card production and lookup interface. Consent is collected during picture-day communications before the session runs. Consent can be withdrawn: if a family withdraws, the headshot is removed from the active card system and the student receives the school’s default placeholder. The consent record is retained in the access-controlled ledger.

Student data & consent

The school owns the card records. Student headshots are never public. Consent can be withdrawn at any time.

Student ID records — name, grade, headshot, roster fields, card history — belong to the school. Student data is never sold to or shared with outside companies or advertisers. Student headshots are consent-gated: a family must provide documented consent before a headshot is associated with a card record. Consent is not assumed. It is collected before picture day runs.

The full record set is exportable at any time: card records, headshots, consent status, and card history. This guarantee is part of the onboarding agreement. If the school leaves the platform, every record leaves with it. Headshots are never retained by the platform for any purpose beyond running the active ID programme.

What is built and what is in early access — plainly

The roster-to-card pipeline and card template are built. Barcode encoding is in early access.

Built and production-ready today: the roster-to-card pipeline (roster import, headshots from the picture-day shoot, review-and-approve queue, batch card generation); the school-controlled card template editor (your logo, your fields, your layout); the one-picture-day connection (same matched file for portrait and ID headshot); and the privacy defaults (facial recognition off by default, consent-gated headshots, access-controlled records, and no ID-card face enrolment unless explicitly, founder-gated, turned on).

In early access: on-card barcode and QR encoding (the encoding engine is built and production-ready; the complete front-office workflow surface for configuring, previewing, and issuing barcoded cards is in active development). There is no live checkout and no live card order here. No billing. No pricing commitment. We say so directly because front offices deserve to know what is production-ready and what is still being built.

Connected to the school platform

The same picture-day shoot runs through the portrait system, the recognition programme, and the ID card programme.

Student ID draws its headshots from the picture-day pipeline at schoolphoto.network: the same roster-matched session that delivers the student portrait. That portrait is also what Seen uses for the recognition programme — the layer that ensures every student lands on a real page in the yearbook, the newspaper, or the playbill. One picture-day session. One matched file per student. Three outputs: the portrait, the recognition page, and the ID card. The full publishing platform is at homeroom.software.

schoolphoto.network seen.school homeroom.software

Early access · Front-office coordinators and district IT administrators

Book a conversation to see the current state honestly

Student ID is in active development. We run conversations that show what is built today: how the roster import maps to card fields, how the picture-day headshot match works, how the card template editor handles a school’s logo and layout, and how the consent and privacy defaults are enforced at the data layer. There is no pricing commitment and no signup. If the programme looks right for your school, we discuss what early access looks like.

To book: email [email protected].

FAQ

Common questions

Do we need a separate photo day just for ID cards?

No. The ID headshot comes from the same picture-day session that delivers the student portrait for the yearbook. One appointment, one roster match, two outputs — portrait for the yearbook and headshot for the ID card. The picture-day pipeline that delivers ID headshots alongside portraits is live. Schools that have already run picture day through the platform can pull ID headshots from that session; no second appointment is required.

Can we design our own card template — our logo, our colours, our field layout?

Yes. The card template is fully school-controlled. The front office defines which fields appear on the card, where the headshot is placed, the school logo, the background, and the field labels. A district can run different templates per building. The template editor is built and production-ready. There is no locked vendor template. The school owns the layout from the first save.

Is facial recognition used in the ID card programme?

Facial recognition is off by default, and it requires an explicit, founder-gated enablement step to turn on. The ID card system is built for identification — a staff member looks up a student by name or ID number, pulls their card record, and confirms identity — not for continuous recognition against a camera feed. The ID card programme does not enrol student headshots in a face database — face-matching is a separate, opt-in capability that stays off unless it is explicitly, founder-gated, turned on. This is a design choice built into the platform at the data layer, not a policy recommendation.

What is on-card barcode and QR encoding, and when will it be available?

The barcode and QR encoding engine is built: a card can carry an encoded identifier readable by a standard scanner at a library desk, a lunchroom point-of-sale, or an entrance reader. The full front-office workflow for configuring the encoding scheme, previewing the encoded output on a card layout, and issuing barcoded cards end-to-end is in active development. Barcode and QR encoding is in early access — the encoding engine is production-ready; the complete workflow surface is not yet finished for general use. We say so directly. A conversation is the honest next step if barcode encoding is a requirement for your school.

How is student data handled? Is the system FERPA-appropriate?

Student ID records — name, grade, headshot, roster fields — are stored in an access-controlled system, never made public, and never shared with outside companies or advertisers. Headshots are consent-gated: a student without documented consent does not have a headshot in the ID system. The platform does not operate as an outsourced education records manager; the school controls its own data and can export the full card record set at any time. FERPA compliance is a school governance responsibility; the platform is designed to support it by making consent, access control, and data export straightforward, not by making those decisions on the school’s behalf.

Who can see a student’s ID headshot?

A student’s ID headshot is visible only to authorised front-office staff through the access-controlled card production and lookup interface. It is never visible to other students or other families. It is never indexed publicly. The headshot is not shared with the yearbook team as a default — the connection between the picture-day shoot and the ID headshot is a roster-matched pull done at the platform level, not a public shared gallery. Consent can be withdrawn: if a family withdraws consent for their student’s headshot, the record is updated and the headshot is removed from the active card system.

What about replacing a lost or damaged card?

The replacement workflow runs through the same card production interface. A front-office reviewer retrieves the student’s existing card record, confirms the data is current, and generates a replacement card from the stored headshot and roster fields. No new photo is required unless the school wants a retake. The replacement is logged against the student’s card record. The above-cost-floor pricing model applies to replacement cards the same way it applies to the original issue — the model is described on request; there is no live order or checkout here.

What does “identification not surveillance” mean for our front office?

The ID card programme is designed to answer one question: is this the student they say they are? A front-office staff member can look up a student by name or ID number, pull their card record, and confirm identity. That is the use case the system is built for. It is not built for tracking student movement through continuous camera recognition, for building a behavioural database from entry/exit patterns, or for any purpose beyond on-request identification by authorised staff. Facial recognition is off by default, and the data the system holds is the minimum needed for the identification function.

What can we use right now, and what is still in early access?

Built and production-ready today: the roster-to-card pipeline (fields from the roster import, headshots from the picture-day session, review-and-approve queue, batch card generation); the school-controlled card template editor (your logo, your fields, your layout); the one-picture-day connection (portrait and ID headshot from the same matched file); and the privacy defaults (facial recognition off by default, consent-gated headshots, access-controlled records). In early access: on-card barcode and QR encoding (encoding engine built; end-to-end workflow surface in active development). A conversation is the honest next step; we show the current state directly.

How is this priced?

The pricing model is above-cost floor: cards are priced above a cost floor the platform enforces at the data layer, so the school always recovers more than material cost on every card issued. The model and the cost floor are explained in a conversation; there is no live order, no live checkout, and no pricing commitment from the site. If the model looks right for your programme, we talk through what early access looks like for your school.