04 — Information Architecture (Biometric Module)
- 1. Module subtree
- 2. Navigation rules
- 3. Content model (per screen)
- 4. IA decisions
- 5. Future expansion
Navigation hierarchy for the Biometric admin console. Gating by the three real permissions (
permissions.constants.ts:41-43); blueprint-only surfaces are(planned). Global IA in 00-shared/05; this file adds the module subtree only.
1. Module subtree
Settings / Administration
└── Biometric (hub — gated: any of the 3 biometric.* perms)
├── Overview / Sync Status [planned] gated: biometric.device.manage
├── Devices [planned] gated: biometric.device.manage
│ ├── Device List
│ ├── Device Register
│ └── Device Detail
│ ├── Sync now
│ └── Enrollment ──────────── (planned, per-device)
├── Logs [planned] gated: biometric.log.read
│ ├── Log List (search/filter)
│ └── Log Detail (bottom sheet)
└── Attendance-Verification Check-in [planned] gated: biometric.log.read
└── punch timeline / verify result
Routing convention (matches module rest: /biometric/... — controller prefix
@Controller('biometric'), biometric.controller.ts:10):
| Route | Screen |
|---|---|
/biometric | Hub (sync status) |
/biometric/devices | Device List |
/biometric/devices/new | Device Register |
/biometric/devices/:id | Device Detail |
/biometric/devices/:id/enroll | Enrollment (per-device) |
/biometric/logs | Log List |
/biometric/logs?student=:id | Log List pre-filtered by student |
/biometric/verify | Attendance-Verification Check-in |
2. Navigation rules
- Hub-first: Biometric is a single hub row in Settings; no biometric surface may be linked from student/attendance detail views into the admin console (Meera/parent personas must only see derived attendance).
- Permission gating: hub visibility = any
biometric.*perm; Devices subtree =biometric.device.manage; Logs subtree =biometric.log.read(permissions.constants.ts:41-43). - Deep links:
/biometric/logs?student=:idshared by the clerk for dispute resolution (journey 4 in03). - Master-detail (tablet/desktop): Devices and Logs use two-pane list/detail
(
00-shared/05).
3. Content model (per screen)
| Screen | Primary entity | Fields shown | Source |
|---|---|---|---|
| Device List | BiometricDevice | name, deviceId, model, status, location | biometric-device.schema.ts:15-31 |
| Device Register | BiometricDevice (create) | name*, deviceId*, model?, location?, config? | schema + blueprint Biometric.md:26 |
| Sync Status | queue/job state | last sync, pending, failed (→ DLQ) | queue.constants.ts:7, blueprint RETRIES.md:38 |
| Log List | BiometricLog | student, device, timestamp, mode | biometric-log.schema.ts:9-19 |
| Log Detail | BiometricLog + raw | rawData (forensic) | biometric-log.schema.ts:21-22 |
| Enrollment | student + device + template | student ref, deviceId, employeeCode, template status | blueprint COLLECTIONS.md:1878-1879 |
| Verify Check-in | student + punches | punch list, matched attendance status | attendance.schema.ts:16-21 |
4. IA decisions
- Logs and Devices are siblings — one is evidence, the other is infrastructure; mixing them confuses the clerk (Arjun) who only ever touches Logs for disputes.
- Enrollment lives under Device, not under Student — enrollment is a device-scoped operation (template lives on hardware), even though the subject is a student.
- Sync Status is the hub landing — the ops manager's first question is "is the gate
healthy?" (
02, persona Riya); device list + queue health answer it in one glance. - No biometric entity is exposed to student/parent profiles in this module's IA —
biometric data stays admin-side (privacy posture,
14§8).
5. Future expansion
(forward-looking)push/QR check-in (phone-as-badge) — new capture surface under the same Sync Status hub; no IA rework needed.(proposed)fleet analytics tile (platform admin) — read-only dashboard widget, gatedreport.read/platform role.