The Realities of Piloting a Learning Operating System

Nobody warned us that the hardest part of piloting a Learning Operating System would not be the engineering. The Curriculum Graph Engine works. The Summative Handshake generates auditable evidence. The dashboards communicate across the Bridge event bus in real time. The system does what it was designed to do. The hard part is something older and more stubborn: the assumptions that school managers and educators carry into every first conversation about new education technology. Getting past those assumptions, or watching them slow everything down when you cannot, is what piloting a genuinely new category of system actually feels like from the inside.

The misconception that will not die: ROAN L-OS is a better LMS

The single most persistent obstacle in every school conversation is the assumption that ROAN L-OS is a Learning Management System. It is not. We have explained this in writing, in demonstrations, in structured walkthroughs of the Curriculum Graph Engine. And yet the mental model reasserts itself, because every person sitting across from us has either used an LMS or has heard of one, and "education software" defaults to that category in the absence of a better frame.

The assumption matters because it sets the wrong expectations. An LMS is evaluated on content library size, user interface elegance, price per seat, and how quickly a teacher can upload a PDF. When ROAN L-OS is evaluated on those criteria, it loses — not because it is inferior, but because those are not the criteria it was designed for. ROAN L-OS is not a better place to store lesson notes. It is a system in which the national curriculum is the foundational data structure, and every feature — assessment, scheduling, AI content generation, parent communication, SBA evidence — derives its behaviour from that structure.

The distinction is architectural, not cosmetic. An LMS can be replaced with a different LMS and the school loses a content library. ROAN L-OS cannot be replaced with a different LMS without the school losing its entire curriculum-to-evidence chain — the verified record of what was taught, when, to whom, assessed at which competency level, sealed into a KNEC-compliant SBA record. That record does not exist in an LMS because an LMS does not know what a curriculum is. It knows what a course is.

We have started using a specific line in school conversations when the LMS assumption surfaces: "An LMS is a filing cabinet for lessons. ROAN L-OS is the plumbing underneath the school." It is imperfect, but it does something that technical explanations alone cannot — it resets the frame fast enough that the rest of the conversation can happen at the right level.

The hardest thing to sell is not a new product. It is a new category. When a school manager has never seen curriculum-native infrastructure before, they have no shelf to put it on — and their instinct is to find the nearest shelf that exists.

Skepticism in schools: what it looks like and where it comes from

Skepticism about new education technology in Kenyan schools is not irrational. It is learned. Most school managers have watched EdTech vendors arrive with large promises, deploy partially, disappear when the free period ends, and leave teachers with one more system to maintain alongside the others. The graveyard of abandoned school portals is real, and every person who has lived through one carries the scar tissue into the next conversation.

The skepticism we encounter takes three distinct forms.

The "we already have something" objection. Schools that have invested in an existing system — even a basic SMS for fees and attendance — are reluctant to add another layer. The concern is not cost during the free pilot period. It is the invisible cost of teacher attention, administrative time, and the organisational energy required to learn a new system. This objection is reasonable. Our answer is not to argue against it but to demonstrate what ROAN L-OS does that no existing system in the school does: it tracks CBC learning outcomes at the sub-strand level, generates KNEC-compliant SBA evidence, and tells teachers which students have genuine learning gaps versus which students simply have not been taught the content yet. If a school's existing system does any of those things, the conversation ends there. None of them do.

The "show me the results" objection. School managers — particularly the more analytically rigorous ones — want evidence before commitment. They want to see data from other schools, peer-reviewed studies, outcome comparisons. We do not yet have all of that. We have a working system, a coherent architecture, and a clear theory of change. What we do not have is longitudinal data from a completed pilot, because the pilot is eight months long and we are three months in. This objection is also reasonable. Our answer is honest: the pilot is how we produce those results. Schools that join now are shaping the study, not waiting for it.

The institutional inertia objection. In larger schools and multi-campus institutions, the decision to adopt a new system rarely rests with a single person. It moves through layers of management, sometimes a board, sometimes a parent association, sometimes a sponsor organisation. Each layer adds time. Each layer is a potential veto point. Each layer requires the conversation to be had again, with a different audience, using a different frame. This is not resistance — it is governance. But it is slow, and it is one of the primary reasons that genuine uptake, even among schools that express genuine interest, takes longer than any optimistic projection suggests.

The constraint that surprises everyone: it cannot be piloted in parts

This is perhaps the most misunderstood aspect of ROAN L-OS for school managers who are cautious by temperament. The system cannot be adopted module by module. A school cannot use only the assessment tracker, or only the parent portal, or only the lesson planner. The architecture does not permit it — not as a commercial restriction, but as a structural reality.

Every feature in ROAN L-OS depends on the curriculum graph. The lesson planner works because the curriculum graph has computed what should be taught this week. The assessment interface works because the curriculum graph knows which learning outcomes belong to which sub-strand and what competency scale applies to the learner's education tier. The parent portal works because the assessment records have been sealed into the Summative Handshake. The AI content generation works because the gap analysis has identified which sub-strands have not been mastered. Remove any link in that chain and the chain breaks.

This surprises school managers who are used to modular SaaS — where you can buy the attendance module now and add the grade-book later. It also surprises them because it sounds, in the worst possible framing, like a lock-in play. It is not. It is the consequence of building a curriculum-native system rather than a curriculum-adapted one. The integration is the value. A school that uses ROAN L-OS for attendance and nothing else is not using ROAN L-OS. They are using a very complicated attendance register.

We have learned to lead with this in school conversations rather than discovering it as an obstacle midway through a negotiation. The system is whole, or it is nothing. Schools that accept that framing — and understand why it is architecturally necessary — make better pilots. Schools that push back on it consistently and want to start with one module are telling us something useful: they are not ready for what this system requires of them, and a partial deployment would fail in ways that would be attributed to the system rather than to the incompleteness of the deployment.

A curriculum-native system is not modular by nature. The curriculum graph is either the foundation of everything the school does digitally, or it is a very expensive diagram.

The strain of pushing forward

There is a particular kind of exhaustion that comes from building at the infrastructure layer of a system that does not yet know it needs infrastructure. The schools that need ROAN L-OS most are often the ones least equipped to recognise what it is. The schools that can recognise it fastest are often the ones with the most existing commitments and the least organisational bandwidth to take on something new.

The free pilot period was a deliberate decision — not a concession. Schools should not pay for a system they are still learning to trust. But free deployments carry their own strain: the absence of a commercial relationship changes the dynamics of accountability on both sides. A school that has paid for a system will push to use it correctly. A school in a free period has less at stake, and the pilot can drift toward passive observation rather than active deployment. We have experienced both dynamics in the schools we are working with, and we are navigating them.

Building at the intersection of curriculum policy, school administration, and AI infrastructure means every conversation requires fluency in three domains simultaneously. The school manager who understands the CBC but has never thought about graph databases. The technology officer who understands APIs but has never read a KNEC assessment framework. The teacher who understands sub-strands but is being asked to seal observations in a digital interface rather than write them in a register. Every stakeholder requires a different explanation of the same system. Every explanation must be accurate. None of them can contradict the others.

What is working: three schools, real signals

Against that backdrop, here is what we can say honestly about progress.

Three schools are currently in active observation with ROAN L-OS ahead of the full pilot windows — Term 1 and Term 2 2027 — which represent the primary deployment phases of the 8-to-9-month pilot. These schools are not passive observers. They are telling us what they need to see before Term 2 begins, what their teachers require in terms of interface preparation, and what their school administrators want to be able to show parents at the next reporting cycle. This feedback is operational gold — it is exactly the kind of grounded, specific guidance that no pre-pilot design process can fully anticipate.

Schools in the observation cohort are asking specific questions about the assessment interface — how long an individual sub-strand observation takes, how the system handles a teacher who needs to assess across multiple classes in a single session, and what the report card output looks like when a full term of formative records has been sealed. These are not objections. They are the questions of people who are preparing to use the system properly.

The fact that schools are preparing — asking operational questions about Term 2 workflow rather than general questions about whether the system works — is the most important signal in the pilot so far. It means the conversation has moved from evaluation to preparation. That is a meaningful shift.

The second success is harder to quantify but more important to name. In every school conversation where we have been able to demonstrate the Curriculum Graph Engine in operation — showing how a specific sub-strand for a specific subject in a specific week is computed rather than configured, how the assessment ratios derive from the education tier rather than from a settings panel, how the KNEC-compliant evidence record is generated from sealed teacher observations — the room changes. The skepticism does not disappear, but it becomes specific. Specific skepticism is productive. It is the skepticism of someone who is genuinely engaging with the system rather than deflecting it.

The third success is the pilot itself — the fact that it is running, that teachers are logging formative observations, that the curriculum graph is distributing lessons across the teaching weeks of Term 3, and that the Bridge event bus is routing assessment events in real time to the parent portal and school admin dashboard. The infrastructure is operational under live school conditions. That is not a small thing. Many systems that look impressive in demonstrations do not survive contact with a real school day. ROAN L-OS is surviving it.

What we are learning about how to introduce this system

The pilot has already changed how we open conversations with schools. We have abandoned the technical overview as the first document we share. It confuses more than it clarifies. We now start with a single question: "Can you tell me, right now, which of your Grade 8 students is below expectation in Strand 2 of Junior Secondary Mathematics — and when that gap first appeared?"

No school can answer that question. Not because the teachers do not know their students — many do, in the way good teachers always have — but because no system in the school holds that information in a way that can be retrieved, verified, and acted on at scale. The moment the school manager understands that ROAN L-OS is the system that answers that question — consistently, for every learner, every sub-strand, every subject, throughout the year — the category confusion begins to resolve.

The pilot is teaching us that a Learning Operating System is not sold or adopted the way an LMS is. It is not a product decision. It is an infrastructure decision. And infrastructure decisions in schools happen slowly, with many stakeholders, against a backdrop of prior disappointments, within the constraints of teacher time and administrative bandwidth. We knew this intellectually before the pilot began. We know it viscerally now.

What we also know — and this matters as much as anything else — is that when the system is understood for what it is, the response is not skepticism. It is relief. The relief of a school administrator who has been managing CBC compliance with spreadsheets and WhatsApp groups, and who can now see a system that handles it structurally. The relief of a teacher who realises that the platform knows what should be taught this week, and that their job is to teach it and record what they observe. The relief of a parent who can see, for the first time, not a grade but a competency — a specific thing their child has demonstrated, in a specific subject, on a specific date, verified by a specific teacher.

That relief is what we built this for. The pilot is teaching us how to find it faster.