The Missing Research on Learning Operating Systems | ROAN L-OS

In 1984, Benjamin Bloom published a finding that has haunted education technology for four decades. Students who received one-to-one tutoring with mastery learning techniques performed two standard deviations above their conventionally taught peers. The average tutored student out‐ performed 98% of the control group. Bloom called this the "2 Sigma Problem" and framed it as a challenge: find methods of group instruction as effective as individual tutoring.

Forty years later, we have not solved it. But we have produced an enormous quantity of software that claims to be working on it. Learning Management Systems. School Management Systems. Student Information Systems. Adaptive learning platforms. AI tutors. Each generation of education technology has arrived with the implicit promise that it would close the gap Bloom identified — that it would bring the quality of personalised instruction to the scale of classroom teaching.

None of them has delivered on that promise. Not because the people building them lacked talent or ambition, but because they were building at the wrong layer of the problem.

This article traces the intellectual history of learning technology from its earliest mechanical ancestors to the present day. It examines a concept that has emerged in industry but remains almost entirely absent from academic literature: the Learning Operating System. And it explains why we at ROAN chose to build one — not as a better LMS, not as a smarter SMS, but as curriculum-native infra‐ structure for an education system that has never had it.

A century of teaching machines

The urge to mechanise instruction is older than computing itself. In 1924, Sidney Pressey built what he called a "teaching machine" — a device resembling a type‐ writer that administered multiple-choice questions and provided immediate feed‐ back. Pressey was not trying to replace teachers. He was trying to solve a logistics problem: the ratio of students to instructors made individualised feedback impossible at scale.

Five years later, Milton Ezra LaZerte built the Problem Cylinder, which presented students with sequenced problems and monitored their steps toward a solution. These were crude devices, but they contained an architectural insight that would prove prescient: learning could be decomposed into discrete, sequenced interactions, and a machine could manage the progression through them.

In the 1950s, B.F. Skinner formalised this insight into programmed instruction — the idea that material should be broken into small frames, each requiring an active response, with immediate reinforcement. Skinner's approach was behaviourist and mechanical, but it introduced a principle that every learning system since has inherited: the learner's state must be tracked, and the next action must be determined by that state.

Then, in 1960, something genuinely new happened. Donald Bitzer and his team at the University of Illinois built PLATO — Programmed Logic for Automated Teaching Operations. PLATO was not just a teaching machine. It was a networked system that supported multiple simultaneous users, featured graphical displays, allowed instructors to create and distribute course materials, and pioneered what we would now recognise as discussion forums, email, and real-time messaging. PLATO ran for four decades. The term "LMS" was originally coined to describe its management subsystem — the part that handled course administration, separate from the courseware itself.

PLATO matters to this story because it was, arguably, the last time anyone attempted to build learning technology as infrastructure rather than application. Everything that followed would be narrower.

The rise of the Learning Management System

The modern LMS emerged in the mid-1990s, riding the wave of the commercial internet. Blackboard (originally CourseInfo) and WebCT offered web-based course management: content storage, discussion boards, gradebook tracking. They were useful. They were also, architecturally, content delivery systems with administrative wrappers.

The critical development of this era was SCORM — the Sharable Content Object Reference Model, initiated in the early 2000s. SCORM standardised how learning content could be packaged and shared across different platforms. It was an interoperability standard, and a necessary one. But it also cemented a particular architectural assumption: that the fundamental unit of learning technology is the content object, and the system's job is to deliver, sequence, and track completion of these objects.

This assumption shaped everything that followed. When Moodle launched as an open-source alternative, it replicated the same architecture. When Canvas and Brightspace entered the market, they improved the user experience but preserved the underlying model. The LMS became, in essence, a sophisticated filing cabinet with a gradebook attached.

By the 2010s, the LMS market had matured into a commodity category. Platforms competed on user interface design, integration capabilities, and mobile responsiveness. Cloud hosting replaced on-premise installations. Analytics dashboards grew more sophisticated. But the fundamental architecture remained unchanged: content goes in, student activity is tracked, grades come out.

What did not change — what could not change within this architecture — was the relationship between the platform and the curriculum. An LMS does not know what a curriculum is. It knows what a course is, what an assignment is, what a grade is. It can store a PDF of curriculum standards and link it to a course. But the curriculum itself — its structure, its learning outcomes, its progression logic, its assessment framework — exists outside the system. The LMS is curriculumignorant by design.

The parallel track: School Management Systems

While LMS platforms focused on content delivery and assessment tracking, a parallel category emerged to handle the administrative machinery of schools: the School Management System, or SMS. These platforms manage admissions, enrollment, attendance, fee collection, timetabling, transport logistics, and communication with parents.

In Africa specifically, the SMS market has grown rapidly. Platforms provide schools with digital tools to replace paper-based administration. The value pro‐ position is straightforward: reduce administrative overhead, improve data accuracy, enable real-time parent communication.

But an SMS, by its nature, is administratively native. Its data model is built around the school as an institution — its staff, its finances, its operational workflows. An SMS knows that a student is in Grade 7 and attends Mathematics on Tuesdays. It does not know what learning outcomes that student is expected to achieve in Mathematics this term, whether they have achieved them, or what should happen if they have not.

The LMS and the SMS sit side by side, each handling one dimension of the educational experience, neither aware of the other's concerns. Content delivery and school operations. Pedagogy and logistics. Learning and management. The two categories were never designed to be unified, and attempts to bolt them together have produced integration layers, not integrated systems.

What is a Learning Operating System?

In December 2021, GEMS Education — the world's largest private K-12 operator — spun out a new entity called Tmrw and introduced a concept they called the "Learning Operating System," or LearnOS. Their pitch was that education needed something more than a standalone LMS or SMS. It needed an integrated ecosystem that could underpin learning, teaching, and the operational needs of K-12 education. Tmrw's platform includes modules for curriculum management, assessment tracking, student progress, sports, counselling, health, and parent relations. It was designed, they said, to cater to the needs of every curriculum, context, and mode of learning.

The instinct was correct. The gap is real. But the framing reveals a particular architectural assumption: that a Learning Operating System is achieved by comprehensiveness — by building enough modules to cover every operational need and bundling them into a single platform.

This is not what an operating system is.

In computing, an operating system is not defined by the breadth of its applications. It is defined by its relationship to the hardware it manages. An operating system is the foundational software layer that sits between the raw machine and the applications that run on it. It manages resources. It enforces constraints. It provides the primitives — file systems, memory management, process scheduling, security models — that every application depends on but none of them implements independently.

The "hardware" of a national education system is its curriculum. A true Learning Operating System would be a system where the curriculum is the kernel — the foundational data structure from which everything else derives its logic.

The analogy to education is precise, if you follow it carefully. The "hardware" of a national education system is its curriculum. The curriculum is the foundational structure — the sequence of learning outcomes, competency expectations, assessment frameworks, and progression rules that every school, every teacher, every student operates within. It is not content. It is not a course. It is the underlying logic of the system.

A true Learning Operating System, then, would not be a platform that happens to include curriculum alongside fifty other modules. It would be a system where the curriculum is the kernel — the foundational data structure from which everything else derives its logic.

The missing literature

Here is where the story becomes strange. Search the academic databases for "Learning Operating System" and you will find almost nothing. There are papers on teaching operating systems to computer science students. There are papers on Learning Management Systems — hundreds of them. There are papers on competency-based education, on curriculum mapping, 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.

This is not a gap in the marketing literature. It is a gap in the engineering literature. It is a gap in the educational research literature. No one has formally asked: what would it mean to treat a national curriculum not as a document to be referenced, but as a computable data structure? What are the architectural implications of building a system where every feature — assessment, scheduling, content generation, analytics, parent communication — derives its behaviour from the curriculum graph? What happens when you stop adapting generic tools to a curriculum and start building tools that are native to it?

The closest academic work sits in adjacent fields. In medical education, the BCIME project (Building Curriculum Infrastructure in Medical Education) has explored competency-based curriculum mapping tools, identifying twelve key characteristics and four thematic categories: visualisation, text analysis, outcomebased approaches, and adaptability. The MedBiquitous Curriculum Inventory standard provided a structured framework for medical curricula specifically. But this work is domain-specific, focused on mapping rather than infrastructure, and does not extend to K-12 national curriculum systems.

In knowledge graph research, recent work has explored how educational content can be represented as graphs. The Curriculum KG Ontology project proposed a framework for dense interlinking of educational materials across platforms. Li et al. developed knowledge graph construction for electronic information curricula. Hubert et al. introduced EducOnto, an ontology for modelling university curricula and student profiles. These contributions are valuable, but they 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.

The gap is this: no one has built the theory for a system where the curriculum graph is not a feature but the kernel. Where assessment types are not user-selected but derived from national examination body specifications per subject and level. Where a single boolean flag can reconfigure fourteen interface components because the system understands the structural difference between Junior Secondary and Senior Secondary at the data model level. Where AI content generation is not just personalised but curriculum-constrained — locked to identified learning gaps, unable to generate material for outcomes a student has already demonstrated competency in.

This is the system we are building. And because the papers do not exist, we are, in effect, writing them in code.

Why curriculum-native, not curriculum-adapted

The distinction between curriculum-native and curriculum-adapted is not a branding exercise. It is an architectural decision with consequences that cascade through every layer of the system.

A curriculum-adapted system is built as a generic platform — a flexible LMS or SMS — and then configured to accommodate a particular curriculum. The curriculum exists as metadata: tags, labels, mapping tables that connect content to standards. The platform's core data model is content centric or institution centric. The curriculum is something the system knows about but is not struc‐ tured around.

A curriculum-native system inverts this relationship. The curriculum is the data model. Every entity in the system — every assessment, every lesson plan, every teacher schedule, every parent notification, every AI-generated intervention — exists in relation to the curriculum graph. The graph is not a layer on top. It is the layer underneath.

The practical implications are significant.

In a curriculum-adapted system, when a government changes its assessment framework — say, shifting from a 60/40 SBA-to-summative ratio to a 20+20/60 ratio at a particular education level — the platform must be reconfigured. Mapping tables must be updated. Rules must be rewritten. The change is a maintenance task.

In a curriculum-native system, the assessment framework is a property of the curriculum graph itself. The graph knows that Lower Primary (Grades 4–6) operates on a 60/40 split while Junior Secondary (Grades 7–9) operates on a 20+20/60 split. When the system generates an assessment, it does not look up a configuration table. It traverses the graph and derives the correct ratio from the tier the student occupies. The assessment framework is not configured — it is computed.

This is not a theoretical distinction. Kenya's Competency-Based Curriculum, which ROAN is purpose-built for, spans PP1 through Grade 12 across a 2-6-3-3 structure with four assessment tiers, each with different SBA ratios, different grading scales, and different national examination endpoints. At the Senior Secondary level, three pathways branch into seven tracks with exactly 571 valid subject combinations. A system that treats this as configuration will drown in edge cases. A system that treats it as structure will derive correct behaviour from the graph.

What we learned from building at this layer

We did not arrive at the concept of a curriculum-native Learning Operating System through market research or competitive analysis. We arrived at it through repeated failure to make existing tools work for Kenya's CBC.

The CBC is one of the most ambitious curriculum reforms undertaken anywhere in the world in recent decades. It replaced the 8-4-4 system with a 2-6-3-3 structure. It introduced competency-based assessment across all levels. It created a three-pathway Senior Secondary system with track-specific elective rules. It defined 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 attempting to implement the CBC are using a patchwork of tools: generic LMS platforms designed for content delivery, SMS platforms designed for administration, spreadsheets for assessment tracking, WhatsApp groups for parent communication. None of these tools understand the CBC. None of them can answer the question that matters most: for this student, in this subject, at this grade, which learning outcomes have been achieved and which have not?

When we tried to answer that question using existing tools, we discovered that the question itself could not be represented in their data models. An LMS tracks course completion. An SMS tracks attendance. Neither tracks competency at the sub-strand level against a curriculum graph. The data structure required to answer the question did not exist in any available system.

So we built it.

The Curriculum Graph Engine — CGE — is a directed acyclic graph that maps every learning outcome in the KICD curriculum from PP1 through Grade 12. Every strand, sub-strand, and theme is a node. The relationships between them carry meaning: prerequisite chains, co-requisite clusters, assessment weight distributions. The graph knows that Term 1 has 10 teaching weeks, Term 2 has 11, and Term 3 has 6, and it distributes learning outcomes proportionally across this 10:11:6 ratio. It knows that lessons allocated per subject per week vary by level. These are not configuration values entered by a school administrator. They are properties of the graph, derived from the KICD curriculum design.

Everything else in the system — assessment, scheduling, AI content generation, teacher dashboards, parent portals, publisher tools, institutional reporting — operates on top of this graph. The graph is the kernel. The dashboards are the applications.

Why this matters beyond technology

There is a reason no one has written the research papers on Learning Operating Systems, and it is not that the idea is too obscure or too niche. It is that the concept sits at the intersection of three disciplines that rarely speak to each other: computer science (specifically systems architecture and knowledge graphs), education research (specifically curriculum theory and competency-based assessment), and public policy (specifically national curriculum implementation at scale).

The LMS papers were written by computer scientists thinking about content delivery. The competency-based education papers were written by education researchers thinking about pedagogy. The school management papers were written by people thinking about institutional operations. No one has written the paper that asks: what is the correct systems architecture for a national curriculum?

We believe this is one of the most important unanswered questions in education technology. Not because the answer is technically complex — though it is — but because the question has implications for how nations implement curriculum reform, how assessment evidence is generated and trusted, how AI is constrained to serve curriculum objectives rather than replace them, and how parents gain visibility into their children's learning at the level where learning actually happens: not the grade on a report card, but the competency on a sub-strand.

Bloom's 2 Sigma Problem was framed as an instructional challenge — how to bring the quality of one-to-one tutoring to group settings. But before a system can personalise instruction, it must first know where each learner stands. And before it can know where each learner stands, it must have a formal, computable representation of the curriculum they are learning.

That is what a Learning Operating System provides. Not content. Not administration. Not another dashboard. The foundational data structure that makes everything else possible.

We are building it for Kenya's CBC. The papers will follow the code.

ROAN L-OS is currently in pre-pilot development. If you are working at the intersection of curriculum, infrastructure, and education in Africa — we would like to hear from you. admin@roanldt.co.ke · roanldt.co.ke