04 — Information Architecture (Dashboard Module)

• 1. Position in the app
• 2. Content structure (from the overview contract)
• 3. Screens / routes
• 4. Widget grid model
• 5. Role-filtered IA
• 6. Naming / taxonomy

How the dashboard sits in the app IA and how its content is structured. Shared app chrome per 00-shared/05 (Global IA); widget-level structure derived from the overview payload (dashboard.service.ts:50-70) and the blueprint API list (Dashboard.md:23-27).

1. Position in the app

• Dashboard Home is the post-login landing screen for roles with dashboard.read (permissions.constants.ts:37; 02_User_Personas.md P1). Roles without it land on their first permitted module (planned).
• Navigation: main rail/drawer item "Dashboard" (first item, 00-shared/05).
• KPI cards are read-only summaries with drill-through links — the dashboard never hosts CRUD; each card deep-links to its owning module.

2. Content structure (from the overview contract)

The single implemented endpoint returns one flat object (dashboard.service.ts:50-70):

overview
├── students.total                count status='active'   (:31)
├── teachers.total                count()                 (:32)
├── staff.total                   count()                 (:33)
├── attendance.total              today's records         (:34,:54)
│   ├── attendance.summary        {status: count}         (:40-43,:55-56)
│   └── attendance.rate           present/total×100, round (:57-64)
└── finance.pendingInvoices       status in issued/partial/overdue (:35-37,:67)
    └── finance.totalDueAmount    Σ(totalAmount − paidAmount) (:45-48,:68)

3. Screens / routes

4. Widget grid model

• Desktop/tablet: responsive grid (00-shared/05 §4); widgets laid out by priority, default order mirrors the service response order (students → teachers → staff → attendance → finance).
• Phone: single-column stack; KPI row condenses to horizontally scrolling cards; charts become full-width blocks.
• Widget order/customization (planned) — persisted server-side in dashboard_widgets (Dashboard.md:7) once GET/PATCH /widgets exist (Dashboard.md:26-27).

5. Role-filtered IA

• Content is filtered by the user's permissions, not by hard-coded UI logic: finance card only when the role may see finance aggregates (planned) (blueprint Dashboard.md:52; see 02_User_Personas.md matrix).
• Today the effective matrix is "org_admin sees everything; everyone else sees nothing" (role.schema.ts:23 vs :31,:39,:47,:55,:63) — role-scoped IA (planned) per IMPLEMENTATION_PLAN.md:232.

6. Naming / taxonomy