Ms. Okafor · Riverbend Elementary · Grade 3

Product architecture

Information architecture

One URL space, five zones, role-adaptive content. Roles do not get separate apps — they get different content, defaults and permissions inside the same pages, so an MTSS team can link each other to the same student and see the same truth. Switch the role in the header to see the tables below highlight that role.

EduNexus shared platform

What identity owns vs. what MTSS.ai owns

Shared — owned by EduNexus

  • · Organizations
  • · Schools
  • · Users & profiles
  • · Memberships
  • · Roles & permissions
  • · Product entitlements
  • · Students (canonical student_id)

Owned by MTSS.ai

  • · Cases & tiers
  • · Interventions & intervention plans
  • · Progress monitoring
  • · Meetings & team notes
  • · Screening information
  • · MTSS documents & decision history
  • · MTSS workflows

Every MTSS record references the canonical EduNexus student_id. Opening a student offers entitlement-aware links into other EduNexus applications — the student record itself is never duplicated.

Sitemap

Grouped by zone

Work

  • Dashboard

    /

  • Students

    /students

  • Student Intelligence Profile

    /students/:id

  • Universal Screening

    /screening

  • Referral Wizard

    /referral

  • Task Engine

    /tasks

Intervention

  • Intervention Library

    /interventions

  • Intervention Planner

    /plans

  • Intervention groups

    /groups

  • Progress Monitoring

    /monitoring

  • AI Meeting Assistant

    /meetings

Oversight

  • Tier pipeline

    /tiers

  • Fidelity monitoring
    role-specific

    /fidelity

  • Referral readiness
    role-specific

    /readiness

  • Compliance dashboard
    role-specific

    /compliance

  • District analytics
    role-specific

    /analytics

Admin

  • Users & roles
    role-specific

    /settings/users

  • Schools & windows
    role-specific

    /settings/schools

  • Approved interventions
    role-specific

    /settings/library

  • Integrations
    role-specific

    /settings/integrations

  • Audit log
    role-specific

    /settings/audit

Family

  • Family home
    role-specific

    /family

  • Messages
    role-specific

    /family/messages

  • Consent & notices
    role-specific

    /family/consent

Navigation

Sidebar groups render only when the role has an item in them

GroupItems
WorkDashboard · Students · Student Intelligence Profile · Universal Screening · Referral Wizard · Task Engine
InterventionIntervention Library · Intervention Planner · Intervention groups · Progress Monitoring · AI Meeting Assistant
OversightTier pipeline · Fidelity monitoring · Referral readiness · Compliance dashboard · District analytics
AdminUsers & roles · Schools & windows · Approved interventions · Integrations · Audit log
FamilyFamily home · Messages · Consent & notices

User roles

Ten roles, six archetypes

Teacher

Educator

Focus · Core instruction

Data scope · Own roster

Reading Specialist

Specialist

Focus · Reading

Data scope · Assigned caseload

Behavior Specialist

Specialist

Focus · Behavior

Data scope · Assigned caseload

Speech Therapist

Specialist

Focus · Speech / language

Data scope · Assigned caseload

Counselor

Specialist

Focus · SEL & attendance

Data scope · Assigned caseload + school SEL

MTSS Coordinator

Process owner

Focus · All tiers

Data scope · Assigned schools

School Psychologist

Evaluator

Focus · Referral readiness

Data scope · Assigned schools

Administrator

Leader

Focus · School health

Data scope · Own school

District Administrator

Leader

Focus · System & equity

Data scope · All schools

Parent / Guardian

Family

Focus · My child

Data scope · Own child only

Reading, Behavior, Speech and Counselor are one Specialist archetype with a domain attribute. They perform identical actions on identical screens; only the domain filter, default intervention category and measure set differ. Four separate role definitions would mean maintaining four near-identical permission sets forever.

Permissions

Capability × role — scope is enforced separately, server-side

CapabilityTeacherReading SpecialistBehavior SpecialistSpeech TherapistCounselorMTSS CoordinatorSchool PsychologistAdministratorDistrict AdministratorParent / Guardian
View student profile
Log progress data
Create referral
Create / edit intervention plan
Approve Tier III plan
Approve tier movement
Record fidelity observation
Schedule / run MTSS meeting
Mark referral-ready → IEPCaseManager.ai
View compliance dashboard
View district analytics
Manage approved intervention library
Manage users & roles
Send parent communication
View audit log
Family portal access

Shared vs role-specific

Why each page sits where it does

Shared shell, role-adaptive content

  • Dashboard

    Same layout; "what to do next", queues and snapshot derived from role.

  • Students

    Same table; scope ranges from 24 students to a whole district.

  • Student Intelligence Profile

    Same tabs; landing tab differs (teacher → Data, psych → Readiness).

  • Universal Screening

    Teachers see their class; coordinators triage the whole window.

  • Referral Wizard

    Same 4 steps; teachers get more AI scaffolding, psych more raw data.

  • Task Engine

    One queue, auto-assigned by role and workflow state.

  • Intervention Library

    Same catalog; default filter = the user's domain.

  • Intervention Planner

    Tier III plans need coordinator/admin approval.

  • Intervention groups

    Grouping and scheduling for whoever delivers minutes.

  • Progress Monitoring

    Measures pre-filtered by domain; identical entry surface.

  • AI Meeting Assistant

    AI drafts different sections depending on attendee role.

  • Tier pipeline

    Scoped to school or district; movement approvals gated.

Genuinely role-specific

  • Fidelity monitoring

    Observation of adults, not students — different consent context.

  • Referral readiness

    The legal seam to IEPCaseManager.ai; early access invites over-referral.

  • Compliance dashboard

    Aggregate staff-performance data; not a practitioner surface.

  • District analytics

    Cross-school equity and disaggregation — a governance surface.

  • Users & roles

    School scope for principals, full scope for district.

  • Schools & windows

    Calendars and screening windows define everyone's deadlines.

  • Approved interventions

    Coordinators may propose; district approves.

  • Integrations

    SIS, assessment vendors, IEPCaseManager.ai handoff.

  • Audit log

    Immutable record of who saw and changed student data.

  • Family home

    Plain language, translated, no staff-performance data.

  • Messages

    Two-way, auto-translated communication.

  • Consent & notices

    Signed notices and meeting invitations.

Page hierarchy

Six levels, no deeper

  1. L0Workspace shellIdentity, scope, AI command bar, notifications
  2. L1ZoneWork · Intervention · Oversight · Admin · Family
  3. L2PageDashboard, Students, Interventions, Tiers, Compliance…
  4. L3Record/students/:id · /interventions/:id · /meetings/:id
  5. L4TabOverview · Data · Interventions · Meetings · Documents · Readiness
  6. L5DrawerLog a score, add a plan, draft a parent note — never navigates away

L5 never navigates away. Every action an educator repeats many times a day happens in a drawer over the current context, so they never lose their place — that single rule is the mechanism behind the 50% documentation-time target.