Africa does not have a Learning Operating System. It has Learning Management Systems. It has School Management Systems. It has mobile apps that deliver quiz questions, platforms that store lesson notes as PDFs, and dashboards that track attendance. What it does not have — what no country on the continent has — is a system where the national curriculum functions as a computable data structure from which every feature in the platform derives its behaviour. This is not a product gap. It is an infrastructure gap. And it is the reason we started building ROAN L-OS.
What a Learning Operating System is not
The term needs precision before it can be useful. A Learning Operating System is not a bigger LMS. It is not an LMS with more modules bolted on — a gradebook plus attendance plus parent messaging plus fee collection bundled under one login. That is a suite. It may be convenient, but its architecture is still content-centric: content goes in, student activity is tracked, grades come out. The curriculum is a tag attached to the content. It is not the foundation the system is built on.
A Learning Operating System is also not a School Management System with academic features added. An SMS is institutionally native — its data model is built around the school as an organisation: its staff, its finances, its timetable. An SMS knows that a student is enrolled in Grade 8 and attends Kiswahili on Wednesdays. It does not know which learning outcomes that student is expected to achieve in Kiswahili this term, whether those outcomes have been assessed, or what intervention should follow if they have not been met.
A Learning Operating System is neither of these things. It is infrastructure. In computing, an operating system sits between the hardware and the applications. It manages resources, enforces constraints, and provides the primitives that every application depends on. The analogy to education is direct: the "hardware" of a national education system is its curriculum — the sequence of learning outcomes, competency expectations, assessment frameworks, and progression rules that every school operates within. A Learning Operating System treats the curriculum as its kernel. Everything else — assessment, scheduling, AI content generation, teacher tools, parent dashboards, publisher integrations, institutional reporting — runs on top of that kernel.
The curriculum is not a feature of the system. The curriculum is the system. Everything else is an application running on it.
What Africa has instead
The EdTech landscape across the continent is growing rapidly. Platforms like Zeraki, Eneza Education, uLesson, and others serve millions of learners with content delivery, SMS-based quizzes, and video instruction. These are valuable tools. They have expanded access to learning materials in contexts where textbooks are scarce and connectivity is intermittent. But they share a common architectural trait: they are curriculum-adapted, not curriculum-native.
A curriculum-adapted platform is built as a generic system and then configured to accommodate a particular curriculum. The curriculum exists as metadata — tags, labels, mapping tables. The platform's core data model is content-centric or institution-centric. When a government reforms its curriculum — as Kenya did when it replaced the 8-4-4 system with the Competency-Based Curriculum — the platform must be reconfigured. Mapping tables are updated. Content is re-tagged. Assessment rules are rewritten. The change is a maintenance task, not a structural one.
A curriculum-native system does not have this problem, because the curriculum is the data model. When the assessment framework specifies that Grade 6 operates at a 60/40 SBA-to-summative ratio while Grade 9 operates at 20+20/60, that ratio is a property of the curriculum graph — not a configuration value entered by an administrator. When Senior Secondary introduces three pathways, seven tracks, and 571 valid subject combinations, the system does not require a feature request. The graph already encodes the structure. Every downstream feature inherits the correct behaviour automatically.
The gap in the literature
Here is what makes this problem intellectually interesting, not just commercially relevant. Search the academic databases for "Learning Operating System" and you will find almost nothing. There are papers on LMS architecture — hundreds of them. Papers on competency-based education. Papers on knowledge graphs in education. But the concept of a Learning Operating System as a distinct architectural category — infrastructure where curriculum is the structural primitive — has not been defined, theorised, or investigated in peer-reviewed research.
The closest work sits in adjacent fields. In medical education, the BCIME project explored competency-based curriculum mapping tools. The Curriculum KG Ontology project proposed a framework for interlinking educational materials. EducOnto introduced an ontology for modelling university curricula. These contributions treat the curriculum graph as a content organisation tool — a way to link learning materials — rather than as the architectural foundation for a complete operational system.
For Sub-Saharan Africa specifically, the gap is wider still. Despite the continent hosting some of the most ambitious curriculum reforms in the world — Kenya's CBC, Rwanda's competency-based curriculum, South Africa's CAPS — no peer-reviewed framework exists for curriculum-native learning infrastructure designed for African education systems. The papers that should describe how to build technology infrastructure for a national curriculum have not been written.
Why Kenya, and why now
Kenya's Competency-Based Curriculum is one of the most structurally complex curriculum reforms undertaken anywhere in recent decades. It spans Pre-Primary 1 through Grade 12 in a 2-6-3-3 structure. It introduces competency-based assessment at every level. It creates a three-pathway Senior Secondary system with track-specific elective rules. It defines learning outcomes at the strand and sub-strand level for every subject at every grade. And it did all of this without a technology infrastructure designed to support it.
Schools implementing the CBC today are using a patchwork of tools. Generic LMS platforms for content delivery. SMS platforms for administration. Spreadsheets for assessment tracking. WhatsApp groups for parent communication. None of these tools understand the CBC. None of them can answer the fundamental question: for this student, in this subject, at this grade, which learning outcomes have been achieved and which have not?
This is the question a Learning Operating System answers. Not by storing more content. Not by adding more dashboards. But by encoding the curriculum as a directed acyclic graph — every learning outcome, strand, sub-strand, and theme as a node, with edges carrying prerequisite relationships, assessment weight distributions, and progression logic — and deriving every feature from that graph.
What we are building
ROAN L-OS is Kenya's first curriculum-native Learning Operating System. Its core is the Curriculum Graph Engine — a directed acyclic graph that maps the entire KICD curriculum from PP1 through Grade 12. The graph is tier-aware: it knows the structural difference between Early Years Education, Lower Primary, Junior Secondary, and Senior Secondary, and it derives behaviour from that structure rather than from configuration tables.
Six AI integration points are curriculum-constrained — no generic chatbot, no personal learner data reaching the API. Only curriculum structure and anonymised mastery state. Assessment evidence is cryptographically timestamped and append-only — once a teacher seals an observation, it cannot be altered. Student privacy is enforced at every layer through a Zero-Contact Student Architecture: no student contact information exists in the system.
Eight role-based dashboards — Super Admin, School Admin, Teacher, Parent-Student, Publisher, County, NGO/INGO, and KICD/KNEC Institutional — all operate on the same curriculum graph. When a teacher records a competency observation, the parent dashboard updates, the school admin sees aggregate shifts, and the KNEC export pipeline queues. One graph. One source of truth. Eight views.
We are not building a better LMS. We are building the infrastructure layer that should have existed before any LMS was deployed in a CBC school.
The papers on Learning Operating Systems have not been written. We are writing them in code. And we are starting in Kenya because Kenya's curriculum reform is ambitious enough to demand infrastructure this deep — and because the 18 million learners in the Kenyan school system deserve technology that understands the curriculum they are actually learning.
ROAN Learning Designs
Building Kenya's sovereign learning operating system — CBC-native, curriculum-first infrastructure for every learner on the continent.
Get in touch