Skip to content

ERP student standard fields: demographics + statutory identity on the enrolled record

The ERP student record (erp.student_profiles) needs to hold every particular an Indian institution must produce on a report card, a marksheet, or a UDISE+ / AISHE government return. An audit against OpenEduCat op.student found the record was already fairly standard — it carries admission number, name, gender, category, quota, APAAR ID (the NEP education student ID), DOB, contact, and a proper guardian sub-record — but was missing a short list of demographic particulars: middle name, nationality, blood group, mother tongue, religion, CWSN (Children With Special Needs) status, and disability type. This doc covers adding exactly those to StudentProfile, all nullable.

No raw Aadhaar. An earlier draft proposed an encrypted Aadhaar field with a deferred parental-consent flow. That was dropped: the record already stores APAAR ID — the education-sector statutory ID that UDISE+/AISHE key on — so storing raw Aadhaar would add the biggest compliance liability (field encryption, verifiable parental consent under DPDP) for little gain. Relying on APAAR removes that debt entirely.

Status: Phases 1–2 built — Product Mindset Gate passed 2026-07-30 (customer-driven; a tenant needs it now). Scope: student first; teacher/ faculty standardization + Teacher↔Employee unification is a separate later track. Branch: feat/erp-student-standard-fields; code PR MySetu-AI/kwiloai_webapp#1465; this doc lands with it.

Related: erp-institution-standard-fields.md (same standardization pattern, one level up — this reuses its three-bucket / conditional-by-type approach), erp-branch-transfer.md (records keyed by student UUID that these particulars sit alongside), auth-and-onboarding.md (student creation paths).

Why this exists

  1. Who asked: A tenant needs it now — customer-driven, confirmed during planning, the same footing as the institution-fields work. (Name/onboarding context to be pinned in the header before the implementation PR.) It also surfaced independently from an OpenEduCat standards audit, so the standard and the demand agree.
  2. User pain: A registrar enrolls a student and expects the student's particulars — category, Aadhaar, mother tongue, gender, emergency contact — to live on the student record. They don't. When the registrar later generates a report card, a transfer certificate, or a UDISE+/AISHE return, the mandatory student particulars aren't in the system, so they keep a parallel spreadsheet alongside Kwilo. Worse, the demographics they did type at admission (gender, category, guardian, address) are not on the enrolled student at all.
  3. Cost of not doing it: Kwilo isn't the system of record for students — report cards and statutory returns can't be produced from it, which undercuts the ERP during the exact rollout we're in. The cost lands now, on a live tenant, not later.
  4. Validated or guess: Validated — customer-driven, and the field set is grounded in legally required identifiers (UDISE/AISHE particulars), not a hypothesis. The audit confirmed these fields exist nowhere in the model today.
  5. How we will know it worked: An admin enters a student's demographics/ statutory particulars once (at admission) and they persist on the enrolled record; a report-card or UDISE export renders the required particulars with no manual step. Sean Ellis counterfactual: remove it a week after shipping and the registrar says "where do I put the student's category and Aadhaar for the marksheet?" — specific and loud, because those fields are legally mandatory.

Personas

Mrs. Latha, registrar at a higher-ed tenant. Prepares marksheets and the annual AISHE return; needs each student's category, gender, DOB, and ID on the student record, not scattered across admission forms and spreadsheets.

A K-12 school clerk filing the UDISE+ return, which mandates Aadhaar, mother tongue, religion, category, and CWSN (disability) status per child — all missing today.

The admitted student / their guardian (indirect): a minor whose Aadhaar is sensitive data requiring parental consent under DPDP.

ICP exclusions

  • B2C self-service learners — no institutional student record, no statutory particulars; nothing here applies to them.
  • Teacher/faculty standardization — the parallel gap on the staff side (demographics + Teacher↔Employee link) is a separate track, deferred.
  • Report-card / UDISE-export consumption — this feature makes the data storable and carried; producing the actual returns/marksheets is downstream.

Outcomes (user outcomes, not deliverables)

  • Demographics captured at admission persist on the enrolled student — entered once, never retyped.
  • An admin can record every particular a report card / statutory return needs, on the student record.
  • Each institution type shows exactly the particulars it must file and no others.

Non-goals

  • Not building the report-card or UDISE/AISHE export itself (downstream).
  • Not standardizing teacher/faculty in this phase.
  • Not changing the B2C learner model.
  • Not storing raw Aadhaar — the existing APAAR ID is the statutory student ID; storing Aadhaar would add encryption + parental-consent liability for no real gain.
  • Not re-architecting the student record — build on StudentProfile, which is already the ERP record of the student.

Metrics

  • North star: % of enrolled students at a tenant with a complete statutory particular set (category + APAAR ID + the type-required fields).
  • Guardrail: no increase in admission-form abandonment; every new field is optional and never blocks enrollment.

Risks & mitigations

  • Minor PII / DPDP Act 2023. Avoided by design: we store no raw Aadhaar (APAAR ID suffices), so this feature carries no biometric-grade PII and no parental-consent obligation. The existing face-recognition consent flow (erp/attendance, K-12/PU only) remains the reference if a raw-Aadhaar requirement ever appears.
  • Wrong target. An early plan aimed at the core Student (learning profile) and would have scattered demographics further. Mitigation: the fields live on StudentProfile, the ERP record of the student, where the rest already is.
  • Scope creep into report cards. Mitigation: explicit non-goal; this phase stops at storable data.

Success signals

  • Registrars stop keeping a side spreadsheet of student particulars.
  • Admission demographics appear on the enrolled student with no re-entry.
  • (Later) report-card / UDISE work reads particulars straight from the record.
  • Sean Ellis: removing it makes marksheet/return prep impossible from Kwilo — a loud, specific complaint.

Mental model — StudentProfile is the record

StudentProfile (ERP) is already the record of a student — it holds admission number, name, gender, category, quota, APAAR ID, DOB, contact and guardians. This feature just fills its demographic gaps. No new record, no core-Student change.

The seven added fields, all nullable:

  • Core (all types): middle_name, nationality, blood_group.
  • K-12 / UDISE-oriented: mother_tongue, religion, is_cwsn (Children With Special Needs), disability_type.

Statutory ID is already covered by APAAR ID — no raw Aadhaar. Admission demographics (gender, category, quota, DOB, contact, address) already flow onto StudentProfile at admit via StudentProfileCreate, so there is no carry to build.

User flows

  • Admin adds/edits a student in the Add Student dialog (ErpStudentsPage); the demographic fields appear as an extra block (CWSN as a checkbox, sent only when set). All optional.

Design decisions

  • Store on StudentProfile, not core Student. The ERP student record is the right home; adding to core Student would scatter demographics further.
  • APAAR over Aadhaar. APAAR ID is the education statutory ID; storing raw Aadhaar was rejected to avoid encryption + parental-consent liability.
  • Per-type field visibility deferred. Mother tongue / religion / CWSN are K-12-oriented but shown for all types in v1 (all optional). Conditional-by- org_unit_type visibility is a follow-up — it needs org-unit-type context in the dialog, which isn't wired there today.

Rollout plan

  1. Phase 1 (done) — StudentProfile columns + schemas + migration erp0022 (additive, all-nullable) + tests.
  2. Phase 2 (done) — demographic fields in the Add Student dialog + service types + i18n.
  3. Later — per-type field visibility; teacher/faculty track; report-card / UDISE-AISHE export consumption.

Changelog

  • 2026-07-31 — Built Phases 1–2. Audit correction: StudentProfile was already fairly standard (APAAR ID, category, guardians), so scope narrowed to 7 demographic fields. Raw Aadhaar dropped — rely on APAAR ID, removing the encryption + consent debt entirely. Code PR kwiloai_webapp#1465.
  • 2026-07-30 — Gate passed (customer-driven). Student-first scope chosen; teacher deferred. Grounded in an OpenEduCat op.student audit.