The Teaching-Week Problem: How Does Kenya's Term Structure Shapes Data Architecture?

Kenya's school year has three terms, and they are not equal length. A typical school calendar runs Term 1 for 13 weeks, Term 2 for 14 weeks, and Term 3 for 9 weeks; 36 calendar weeks in total, once holidays and administrative closures are factored in. KICD does not publish a teaching-week ratio; its curriculum designs specify content and suggested lesson counts per subject, not a term-by-term teaching calendar. This is why ROAN L-OS has re-imagined the formative weeks (teaching weeks) to be 10 weeks for term 1, 11 weeks for Term 2 and 6 weeks for Term 3.

The 10:11:6 split across 27 teaching weeks is ROAN L-OS' own model; the number of weeks in each term that are actually available for instruction once assessment periods, orientation days, and closing activities are set aside from the 13:14:9 calendar structure. Every lesson allocation, every assessment window, every remedial scheduling decision in ROAN L-OS is shaped by this internal teaching-week model. And it is the reason the Curriculum Graph Engine treats lesson distribution as a computed output rather than a user input.

Why the asymmetry matters

If the school year were divided into three equal blocks of teaching time, curriculum distribution would be trivial. Take the annual lesson count for a subject, divide by three, assign one-third to each term. A spreadsheet could do it. A human could do it in their head.

But the terms are not equal length, and the teaching time within each term is smaller still once assessment weeks and closing activities are set aside. Working from a 13:14:9 calendar structure, ROAN's model treats Term 2 as carrying slightly more instructional weight than Term 1, and Term 3, the shortest and most exam-heavy term, as carrying substantially less. A subject with 135 annual lessons should not receive 45 lessons in each term. It should receive an amount proportional to the actual teaching capacity of each term, which is not one-third, one-third, one-third.

The problem compounds at the sub-strand level. A subject like Junior Secondary Mathematics may have 18 to 25 sub-strands, each with a different KICD-suggested lesson count. Distributing these sub-strands across terms in proportion to actual teaching capacity, while ensuring no week exceeds the lessons-per-week ceiling, while preserving the teaching sequence specified in the curriculum design, is not an arithmetic problem a teacher should be doing on a Sunday evening. It is a constraint-satisfaction problem that belongs in an engine.

Unequal teaching capacity across terms is not a planning failure. It is an infrastructure absence. Teachers should not be solving constraint-satisfaction problems in spreadsheets.

What happens when humans do it manually

We have seen the spreadsheets. During early conversations with schools implementing the CBC, we asked how they distributed curriculum across terms. The answers fell into three patterns.

Pattern one: equal division. The school divides the year's sub-strands into three roughly equal groups and assigns one group per term. This ignores how much shorter Term 3 actually is in teaching capacity once exams and closing activities are accounted for. Term 3 ends up with the same amount of content as Term 1, despite having far less available instructional time. Teachers rush. Content is skipped. Assessment coverage suffers.

Pattern two: front-loading. The school assigns more content to Terms 1 and 2, treating Term 3 as revision and examination only. This is pragmatic but creates a structural problem: if the curriculum design specifies learning outcomes in a progression sequence, removing Term 3 from active teaching breaks the prerequisite chain for the following year. Grade 5 Term 1 assumes Grade 4 completed its full sequence, including Term 3 content.

Pattern three: per-teacher discretion. Each teacher distributes their own subject based on experience and intuition. This produces inconsistency across classrooms. Two Grade 7 Mathematics teachers in the same school may cover different sub-strands in the same term, making school-level assessment aggregation meaningless and remedial scheduling impossible.

None of these patterns is wrong in intent. Each reflects a teacher or administrator making a reasonable decision with insufficient tools. The problem is structural: the unequal teaching capacity across terms creates a distribution challenge that manual methods cannot solve reliably at scale.

Why lessons_allocated is a computed output

This is where ROAN made an architectural decision that surprised some early reviewers. In the Curriculum Graph Engine's upload template, the structured file used to ingest KICD curriculum data, there is no column for lessons allocated per sub-strand and no column for term target. These fields do not exist as inputs. They are outputs of the distribution engine.

The template captures what the KICD curriculum design specifies: the sub-strand structure, the KICD-suggested lesson count per sub-strand (a weight, not an allocation), and the KNEC assessment weight tier. That is all. The engine takes these weights, reads the subject's lessons-per-week value from the KICD capacity table, and computes the allocation.

The reason is simple: if lessons_allocated were a user input, it would be wrong. Not because teachers or administrators are careless, but because the computation requires simultaneous awareness of the total annual capacity, the relative weights of all sub-strands in the subject, the actual teaching capacity of each term once assessment periods and closing activities are excluded, the lessons-per-week ceiling, and the rounding behaviour needed to ensure the sum of allocated lessons equals the annual capacity exactly. No human performs this computation accurately across 18+ sub-strands without tooling. And if the platform accepted a human-entered value, it would have no way to guarantee the total adds up — opening the door to weeks with too many lessons, terms with too few, or silent rounding drift that accumulates across the year.

By making lessons_allocated an output, the engine guarantees three things. The total allocation for a subject equals its full annual capacity exactly; no more, no less. No individual week exceeds the lessons-per-week ceiling. And the distribution respects both the relative weights the KICD assigned to each sub-strand and the actual teaching time available in each term. These guarantees are mathematical, not aspirational. They hold for every subject at every grade level in the system.

Calendar-agnostic by design

There is a subtlety in ROAN's teaching-week model that took time to recognise. It defines canonical teaching weeks — a fixed sequence within each term — but it does not define calendar dates. Term 1 always has the same number of canonical teaching weeks, but the specific calendar dates of those weeks vary by school. Some schools start the year in early January. Others start in mid-January. Some counties have different holiday schedules. A national school and a county school in the same region may have Term 1 ending on different dates, even though both are working from the same 13-week Term 1 calendar block.

This means the Curriculum Graph Engine must be calendar-agnostic. The engine distributes sub-strands across canonical teaching weeks, in sequence, term by term. It knows which canonical weeks belong to Term 1, Term 2, and Term 3. But it does not know that Week 1 starts on January 6th or that a particular week falls in the first week of May. That mapping, from canonical weeks to calendar dates, happens at the school level, not in the engine.

The Term Framework module in the Super Admin dashboard publishes the national framework: how many weeks per term, which assessment windows are mandatory, which are optional. School administrators then key in their school-specific start and end dates within these nationally defined constraints. The engine validates that the school's date entries are consistent with the canonical structure (a school cannot claim Term 1 has 12 teaching weeks), but it does not dictate the dates.

This separation matters for three reasons. First, it allows the engine to compute curriculum distribution once at the national level and share the result across all schools using that subject at that grade, rather than recomputing per school. Second, it allows schools to set their own calendar within the national framework without affecting curriculum integrity. Third, it means the engine's distribution outputs are stable across the entire academic year. A change to a school's holiday schedule does not require recalculating the curriculum allocation. The canonical weeks are fixed. Only the date mapping changes.

The engine distributes curriculum across canonical weeks. Schools map canonical weeks to calendar dates. The two concerns never mix.

What this reveals about system design

The unequal length of Kenya's three school terms is, in isolation, small. Thirteen weeks, fourteen weeks, nine weeks. But it reveals something important about the difference between building education technology and building education infrastructure.

A platform that treats curriculum as content, a tagged library of lessons and assessments, never encounters this problem. It does not need to distribute sub-strands across terms because it does not model terms as structural entities. Teachers browse the library, pick content, and teach it when they choose. The calendar is irrelevant to the data model.

A platform that treats curriculum as configuration encounters the problem but handles it through manual entry. An administrator sets up the term structure, enters lesson counts per term, and hopes the numbers add up. The platform stores what it is told. If the numbers are wrong, the platform does not know.

A platform that treats curriculum as a computable graph encounters the problem and solves it. The engine knows the ratio because the ratio is a property of the graph. It knows the constraints because the constraints are invariants of the distribution algorithm. It computes the allocation because allocation is an output, not an input. And it separates canonical weeks from calendar dates because those are different concerns with different owners.

This is what curriculum-native means in practice. Not a slogan. Not a positioning statement. A design philosophy that says: if the curriculum specifies it, the system should compute it. If a human is entering a value that the curriculum already determines, something is architecturally wrong.

The detail that contains the whole

We sometimes describe Kenya's unequal term structure to investors and partners as the "small detail that contains the whole." It is the kind of requirement that a product team might dismiss as an edge case — a calendar quirk to be handled with a configuration field. But the decision to handle it as a computed invariant rather than a configured input cascades through the entire platform.

Because lessons_allocated is computed, the LPW Gate can work; it knows exactly how many lessons should have been delivered because the engine told it. Because term placement is derived from the teaching-week model, the assessment calendar can enforce window constraints without asking a teacher to manually specify which term they are in. Because canonical teaching weeks are separated from calendar dates, a school's schedule change does not invalidate its curriculum data.

Each of these downstream features — the LPW Gate, the assessment calendar, the term framework — would be harder, more fragile, or impossible if unequal term length had been handled with a spreadsheet column instead of a distribution engine. The small detail shapes the architecture. The architecture shapes what the platform can do.

Kenya's school terms run 13, 14, and 9 calendar weeks. This is a fact about the education system. What ROAN built is the infrastructure that takes that fact seriously.