The Problem With Flat Curricula

A curriculum is just the ordered set of things you want a learner to end up knowing — for a kids' Arabic app, that means letters, their sounds, joining letters into words, reading short sentences, and (in the wider product) some math, English, and grammar too. Before any clever software, a curriculum is a decision about what to teach and in what order.

The obvious way to store that decision is a flat curriculum: a single ordered list of lessons, lesson 1 then lesson 2 then lesson 3, the same list for everyone. It is the spreadsheet model of teaching. It is also how almost every learning product starts, because it is the simplest thing that could possibly work — and, exactly like the monolith in software, the trouble only shows up later.

The diagram shows the whole curriculum as one straight line. Every child enters at the top and is expected to walk down in the same order at (roughly) the same pace. That single shape is the source of the three problems this whole course is about.

The first thing a flat list cannot express is which lesson depends on which — a prerequisite being a thing you must understand before another thing can make sense. "Read the word baab" secretly requires that the child already knows the letter ب (baa), its sound /b/, and how letters join. A flat list implies that order by position, but it does not know it.

That gap bites the moment reality diverges from the list. A child who never really mastered the sound /b/ still gets marched to the word baab because baab is simply the next row. The list has no idea a foundation is missing, so it lets the child hit a wall it was never prepared for — and a five-year-old who hits that wall does not file a bug report, they just decide the app is "too hard" and leave.

The arrows in that diagram are the actual dependencies between concepts. A flat list stores the boxes and throws the arrows away — and the arrows are the part that keeps a child from being set up to fail.

The second failure is that one list means one path for everybody. Two children are never in the same place: one already speaks Arabic at home and needs to move fast; another is brand new to the letters and needs slow, repeated practice. A flat curriculum serves them the identical rows in the identical order.

The result is the classic mismatch every teacher knows. The advanced child is bored by lessons far below her level and disengages; the beginner is overwhelmed by lessons far above his and disengages too. Good teaching lives in the "just-right" zone — hard enough to be worth doing, easy enough to succeed at — and that zone sits at a different place in the list for every child. A single shared list cannot be in two places at once.

The third problem is not about the child at all — it is about the cost of building. In a flat model, each lesson is usually hand-authored as one finished screen, and every place the content needs to appear — the app, the website, a printable worksheet, a marketing page — is authored again, by hand, in that surface's own format.

So the letter ب lives as a hand-built app lesson, a separately hand-built web lesson, a separately drawn PDF worksheet, and separately written marketing copy. Four copies of one idea, four things to keep in sync, and the marginal cost of every new surface is "author the entire curriculum one more time." That does not scale to a product that wants to be an app and a website and printables and books.

The table is the whole indictment in one place: a flat list drops the dependencies, forces one path on everyone, and duplicates authoring per surface.

The fix chosen for Amal was to stop storing the curriculum as a list and start storing it as a graph — a structure of nodes (the things) connected by edges (the relationships between them). Here a node is a single teachable concept (the letter ب, the sound /b/, addition-to-10), and an edge is a prerequisite ("you need the sound /b/ before the word baab").

That one change addresses all three problems at their root, which is why the rest of this course builds on it:

• The arrows become first-class data. Prerequisites are stored explicitly as edges, so the system can know a child is missing a foundation instead of blindly serving the next row.
• A path can be computed per child. Given the graph plus what one specific child knows, software can pick that child's just-right next concept — a different pick for every child, from the same graph (Days 3–5).
• One node feeds every surface. Because a concept is stored once as structured data (not as a finished app screen), the app, the web lesson, the printable, and the marketing card can all be generated from that single node — author once, render everywhere (Days 6–7).

The diagram is the seed of everything that follows: the same three concepts as before, but now the arrows are stored, so a path can be figured out for each child instead of frozen into one shared list. Day 2 makes this graph concrete — the exact tables that store the nodes, the edges, and each concept's pictures and audio.

• A curriculum is a decision about what to teach and in what order; the simplest way to store it — a flat, one-size-for-all ordered list of lessons — is where almost every product starts.
• A flat list drops prerequisites (the dependencies between concepts), so a child can be marched into a lesson it was never prepared for and simply hit a wall.
• A flat list forces one path on everyone, so it cannot keep each child in the "just-right" zone that sits at a different point for every learner.
• A flat list encourages hand-authoring each lesson per surface, so every new surface (app, web, print, marketing) means authoring the whole curriculum again.
• The bet that fixes all three at once: model the curriculum as a graph — nodes are teachable concepts, edges are prerequisites — so dependencies become data, each child's path can be computed, and one node can feed every surface.

• [ ] I can define a curriculum and explain what makes a curriculum "flat".
• [ ] I can name the three things a flat curriculum cannot do (prerequisites, per-child path, reuse).
• [ ] I can explain, with the ب → /b/ → baab example, what a prerequisite is and why storing it matters.
• [ ] I can explain the "just-right" zone and why one shared list cannot hit it for every child.
• [ ] I can state the core bet of this course: a curriculum as a graph of concept nodes and prerequisite edges.