Brightpath Learning

Mobile application

The challenge

Brightpath measured engagement — logins, video completion, time on page — and none of it predicted whether a student would pass. Instructors learned a student was struggling when a grade posted, typically too late for meaningful intervention. Completion rates sat at 61%, and exit surveys consistently cited feeling lost without knowing how to ask for help. The platform's accessibility had also been retrofitted rather than designed in, and failed audit in eleven places.

Research

• Analysis of three years of outcome data against every engagement signal collected
• Interviews with 40 instructors on how they currently identify struggling students
• Exit surveys and follow-up interviews with 120 non-completing students
• Full WCAG 2.2 audit of the existing platform

The solution

We replaced time-based progression with mastery-based: students advance on demonstrated understanding rather than elapsed weeks, and the system knows precisely which concept is blocking them. The early-warning model consumes assessment-level performance rather than engagement proxies, flagging risk an average of 3.5 weeks earlier than the previous grade-based trigger. Instructors receive a ranked list of students needing attention with the specific concept in question — not a risk score, which the academic team correctly noted invites fatalism.

UX decisions

Features

• Mastery-based progression with concept-level dependency mapping
• Early-warning analytics on assessment performance, not engagement proxies
• Instructor intervention workflows with concept-specific context
• WCAG 2.2 AA guaranteed at the design-system level
• Offline-capable mobile learning for low-connectivity regions
• Transfer credit evaluation and cohort assignment
• Accreditation and outcome reporting across 14 jurisdictions

Technology

Architecture

The Next.js platform serves course content through an ISR-backed catalog with per-student progression state in PostgreSQL. Assessment events stream into Snowflake, where the Python risk model runs nightly against a concept-dependency graph to identify blocking concepts per student. Redis caches the concept map and session progression. The model was validated against three years of held-out historical outcomes before any instructor saw its output, and the rollout retained a control cohort so the completion lift could be measured rather than asserted.

Results

Course completion rose from 61% to 79% — a 29% relative increase — measured against the held-out control cohort rather than pre/post, which the academic team insisted on. At-risk students are identified 3.5 weeks earlier on average. All student-facing surfaces pass WCAG 2.2 AA. Instructor survey responses shifted markedly on the question of whether they could tell who needed help.

Lessons learned

1. 01Insisting on a control cohort cost us a more impressive headline number and gave us one we could actually defend. The pre/post figure would have been meaningfully inflated by concurrent curriculum changes.
2. 02The academic team's objection to risk scores was the most important design input we received. Engineering instincts favored the score; the pedagogy was right.
3. 03Building accessibility into components rather than pages made it essentially free to maintain. The retrofit had been costing them a failed audit every cycle.