Industry
Education and workforce development
Education technology carries a duty of care that most software does not. Learners are frequently children, the adults working with them require verification, and the record of what was taught matters to families, institutions and funders.
Workflows
The work that actually happens here
Named the way practitioners in this sector name them, because that is the vocabulary a delivery team has to learn before it can be useful.
- Educator verification and onboarding
- Identity, qualification and background checks completed before an educator becomes visible, with verification state re-checked rather than captured once.
- Enrolment and cohort management
- Learners assigned to courses, cohorts or pathways with the guardian relationship modelled explicitly.
- Scheduling and delivery
- Booking across time zones, session delivery, attendance and material access.
- Assessment and progress
- Objective-level progress recorded against a curriculum, aggregated for learners, guardians and institutions.
- Funding and outcome reporting
- Evidence of participation and achievement in the formats funders and awarding bodies require.
Constraints
What changes the architecture
These are the reasons a design that works elsewhere would be wrong here.
Children’s data requires a higher bar
UK age-appropriate design expectations, and equivalent duties elsewhere, constrain default settings, profiling, nudge patterns and data minimisation.
Safeguarding constrains product decisions
Features enabling unsupervised adult–child contact are safeguarding decisions requiring explicit review, not ordinary product changes.
The guardian relationship must be first-class
Consent, visibility and control frequently sit with a guardian rather than the learner, and that relationship changes as the learner ages.
Sharp, predictable load peaks
Traffic concentrates around after-school hours, term boundaries and examination periods. Design for the peak, not the mean.
Connectivity varies enormously
For learners in Ghana and Nigeria, mobile data cost and reliability shape what is usable far more than device capability does.
Integrations
Systems we would expect to meet
- Identity and background-check providers per jurisdiction
- Video conferencing for live delivery
- Payment providers including local African methods
- School information systems and management information systems
- Awarding body and curriculum data sources
- Calendar systems for scheduling
Trust considerations
What users and regulators need here
- Verification status must be visible to families at the point of choosing, not buried in a profile.
- Communication between adults and learners should be in-platform and retained.
- Learner data collection should be minimised to what teaching requires, with defined retention per category.
- Progress reporting must be understandable to a parent, not only to an educator.
- Reporting and escalation routes must be present at the point of concern, not in a help centre.
Architecture
A shape we would actually propose
A starting sketch, not a template. Discovery is what turns this into a specific design with recorded trade-offs.
- Identity
- Separate learner, guardian, educator and institution identities with an explicit guardianship relationship.
- Verification
- Per-market verification behind a provider interface, with expiry and scheduled re-checking.
- Learning records
- Curriculum objectives as first-class entities; sessions record coverage and outcomes against them.
- Delivery
- Mobile-first, low-bandwidth front end with offline-tolerant material access.
- Peak handling
- Aggressive caching of discovery and materials; scheduling and payments scaled for the after-school peak.
Outcomes
What good looks like
- Families able to choose on verified evidence rather than an unverified profile
- Progress recorded against curriculum objectives rather than hours delivered
- Safeguarding obligations supported by the product rather than by policy alone
- Usable delivery on low-bandwidth mobile connections
Next step
A education and workforce development project starts with the constraints
The Project Architect asks sector-specific questions about data, regulation and integration before it asks about features.