Pieces of learning, connected: What it takes for AI to read a curriculum

Imagine a Grade 4 teacher in Ghana asks an LLM to make a week’s multiplication lesson. The model can produce a polished teacher guide, worksheet, and practice game in seconds. The problem is that the material can look completely reasonable while being ahead of what the local curriculum expects at that grade.

That is a hard problem to solve with prompt engineering alone. The model needs curriculum context: not just mathematics, Grade 4, but the exact expectations for that curriculum, how they sit within the source document, what smaller skills they contain, what earlier or related learning connects to them, and where those claims came from.

Curriculum PDFs already contain much of that context, but PDFs are a poor interface for traditional software. Our answer is to turn them into a structured knowledge layer that keeps the source curriculum intact, adds useful graph relationships around it, and makes the result available to AI applications through a common interface.

Our approach: we reconstruct the PDF before interpreting it, preserve the curriculum’s own hierarchy, break broad statements into smaller pieces of learning, add reviewed progression relationships, and serve the resulting graphs through MCP.

Why a shared curriculum context layer matters

The value is not just the knowledge graph itself. It is also what becomes easier once an application can ask for a specific curriculum record and get context back with it.

A shared layer also gives researchers, ministries, and product teams something concrete to inspect together. If an application produces a surprising answer, we can ask which curriculum item it retrieved, which relationship it followed, and which part was the model’s own interpretation.

What we built, in one view

We currently have six curricula across four countries and three subjects: 5,278 curriculum items and Learning Components connected by 5,729 relationships. The explorer below highlights one shared concept (fractions) across Rwanda, Ghana, Nigeria, and Tamil Nadu.

Open the current Learning Explorer in a new tab ↗

Our data model takes inspiration from Learning Commons. We use three related graph ideas, each for a different job:

• Academic Standards represent what a curriculum says and how the source organizes it. A hasChild relationship records source hierarchy.
• Learning Components break broad curriculum statements into smaller skills or concepts. A supports relationship connects a component back to the standards it helps express.
• Learning Progressions describe reviewed connections among standards. buildsTowards is directional; relatesTo records a meaningful connection without saying that one target comes first.

At a high level, the system looks like this:

1. Reconstruct before interpretation

Curriculum PDFs are designed for people, not machines. A person can tell that a bold phrase is a heading, that an indented statement belongs to the section above it, or that a sentence at the bottom of one page continues at the top of the next. Plain text extraction can preserve the words while losing those relationships.

So the first job is not to build the knowledge graphs. It is to reconstruct the document faithfully enough that later steps have something reliable to work from.

Each page is converted into a layout-aware Page Intermediate Representation, or Page IR. An intermediate representation is simply a structured description of what is on the page before we assign curriculum meaning to it. The Page IR records headings, paragraphs, lists, tables, visible codes, coordinates, and possible continuations across page boundaries.

This is one place where a vision model is useful. Curriculum layouts vary a lot, and deciding whether a block is a heading, label, standard, or table cell is often easier from the rendered page than from formatting rules alone. We do not ask the model to read an entire curriculum and invent a graph in one pass. Each call handles a narrow task on a specific piece of the page.

Page boundaries get their own check. If a standard begins on one page and continues on the next, treating the two fragments as separate standards would create curriculum content that was never there. Candidate continuations are also checked before the pipeline moves on.

The verified pages are then stitched into a Document IR. This step is deterministic: it rebuilds document-level blocks and tables from the verified pages without making new curriculum claims.

This gives us provenance. When a later graph node says that a statement is a competency or that two pieces belong in a parent-child relationship, we can trace that claim back toward the source page instead of relying on an opaque extraction step.

For an application, that means a retrieved curriculum item can still come with the source context needed to check it.

Readers who want the schemas, validators, artifact lifecycle, and pipeline details can find them in the KG production documentation.

2. Preserve the curriculum’s own structure

Once the document is reconstructed, the next step represents curriculum structure rather than page layout.

The Academic Standards graph creates entities for the curriculum framework and its standards items, assigns stable identities, reconciles duplicate extraction candidates, and connects items with hasChild relationships.

We do not force every curriculum into one universal hierarchy. Rwanda Mathematics can move from Framework to Grade, Topic Area, Sub-Topic Area, Unit, Key Unit Competence, and objective types before reaching a Learning Component. Meanwhile, Tamil Nadu Mathematics reaches a comparable learning idea through a much shallower structure built around Curricular Goal, Competency, and Content.

The graph contract is shared, but the source vocabulary is not. Curriculum-specific configuration describes local statement types, grade or class scope, identity rules, and allowable parent relationships. Validation checks for broken endpoints, cycles, unreachable nodes, invalid parent counts, and other graph problems before release.

Some curricula are not strictly trees either. For example, CBSE Science contains legitimate multi-parent structures, so the Academic Standards graph allows a directed acyclic graph where the source requires it rather than forcing every node to have exactly one parent.

With this approach, a user can ask what sits above or below a curriculum item and get an answer in the curriculum’s own hierarchy instead of one we imposed for convenience.

3. Turn broad standards into smaller pieces of learning

Academic standards are often broad on purpose. One statement can combine several actions, concepts, representations, and levels of detail. That works well as a curriculum expectation, but an assessment or tutoring application may need a more specific answer to a question such as: What skill is being taught or measured here?

Learning Commons defines Learning Components as granular skills or concepts that break broad standards into teachable and measurable parts.

Our Learning Components layer starts with eligible Academic Standards items and decomposes them into smaller components. Each accepted component is connected back to the standard or standards it helps express through supports.

One statement can become fourteen addressable skills

Consider a Tamil Nadu Class 1 mathematics statement that asks learners to compare and order objects by length, height, distance, thickness, weight, capacity, and quantity.

That is one coherent expectation at the curriculum level. However, at the Learning Component level, it becomes fourteen pieces: seven kinds of comparison and seven kinds of ordering.

Now an application can work with compare two objects by weight or order objects by distance as individual skills while still retaining the original curriculum statement that gave them context.

The same component can also appear in more than one place. In Ghana English, “Retell level-appropriate texts in own words” supports expectations in Basic 1, Basic 2, and Basic 3. We can represent the skill once and keep separate supports relationships to each grade-level context.

Across the six curricula, there are 2,543 Learning Components and 2,765 supports relationships. There are more relationships than components because the same component can support more than one curriculum item instead of being copied into disconnected records.

Thus, an assessment platform can map a question to compare weight rather than only to a broad curriculum statement that contains thirteen other skills as well.

4. Make progression a relationship of its own

Hierarchy and granularity answer two different questions:

• Where does this item sit in the curriculum? The Academic Standards hierarchy answers that.
• What smaller pieces of learning are inside it? Learning Components answer that.

Teaching and learning add a third question: How does one learning target connect to another over time?

That is the job of Learning Progressions. Following the Learning Commons Learning Progressions schema, we represent reviewed connections with relationship types that say exactly what kind of claim is being made:

• buildsTowards is directional. Proficiency in one target supports the likelihood of success in another, without saying that it is a strict prerequisite.
• relatesTo says that two targets have a meaningful conceptual or skill connection without putting them in an instructional order.

Keeping those relationships separate from hasChild is important. A curriculum hierarchy tells us how the document is organized but it does not prove prerequisite knowledge or instructional sequence.

Once progression is represented explicitly, a tutoring system can ask which earlier targets build toward the one a learner is struggling with, or which related concepts might provide another route into the same idea. The system does not have to guess a learning sequence from the curriculum’s table of contents.

5. Serve the graphs through MCP

A well-formed graph is only useful to an AI application if the application can retrieve from it consistently.

We keep graph generation and graph serving separate. Once a graph passes production checks, it is published as a versioned package with the graph data, configuration needed to interpret it, validation results, provenance and rights metadata, and checksums.

Each curriculum stays in its own package. Ghana Mathematics, Tamil Nadu Mathematics, and Rwanda Mathematics keep their own source structures and version histories rather than being merged into one master graph. The MCP service gives clients one interface across those packages.

At startup, the server validates the accepted packages and builds the graph and text-search indexes it needs for retrieval. When a user asks a question, it does not reopen the source PDF or call another LLM to reinterpret the curriculum. It looks up records from the already validated package.

Model Context Protocol is the interface between that curriculum service and an AI application. Through the server, a client can discover frameworks, retrieve Academic Standards, Learning Components, and Learning Progressions, inspect hierarchy and provenance, and gather records for comparison or progression-oriented tasks.

The same interface can support very different applications. A lesson planner, tutoring app, homework helper, and teacher assistant should not each need to build their own way of parsing and interpreting the same curriculum.

The MCP server retrieves curriculum records; the host model decides what to do with them. If a user asks for a comparison, the server can return the relevant source-backed records and provenance. The model can summarize or compare them, but its conclusion does not automatically become an official curriculum fact.

That distinction also makes the system easier to debug. If a teacher assistant produces an odd recommendation, we can separate a retrieval problem from a reasoning problem instead of treating the whole application as one black box.

The MCP server documentation goes deeper into package validation, resources, tools, prompts, rights controls, and integration patterns.

6. Compare related learning without pretending it is the same thing

Once curricula have stable standards and smaller Learning Components, we can put related ideas next to each other without pretending that different curricula say the same thing.

Fractions are a useful example. Rwanda, Ghana, Nigeria, and Tamil Nadu all contain recognizably related learning, but the expectations are different:

• Rwanda names specific fractions and comparison symbols.
• Ghana combines pictorial representations with equivalent-fraction strategies.
• Nigeria highlights the use of < and > symbols.
• Tamil Nadu emphasizes activities and materials rather than an algorithm.

Thus, finding related curriculum records does not necessarily mean they are equivalent. The graph gives us named entities and source context that can be compared. A model or reviewer can then make a separate comparison claim and label it as such.

That separation also matters in downstream applications. A curriculum researcher can compare how several systems express a common idea without rewriting them into one synthetic standard. A ministry can inspect a suggested cross-curriculum connection without having it quietly inserted into the source graph.

What comes next

The core path covers curriculum reconstruction, Academic Standards graphs, Learning Components, Learning Progressions including buildsTowards and relatesTo, versioned packages, and MCP access to those graph layers.

Next, our plan is to add more curricula without losing their local structure, improving how we review and evaluate generated components and progression links, and testing whether the shared context layer improves teacher tools, tutoring systems, and assessment mapping.

We also want the graph to become useful beyond curriculum lookup. Learning Components can act as stable junctions between curriculum expectations and other material: assessment items, lessons, teacher resources, or evidence about what a resource teaches. The hard part is deciding what new edges mean, how each was reviewed, and how a user can trace each back to its source.

Connected, without losing the source

The visualizer makes the connections easy to see. Underneath it, different edges make different claims. hasChild records source hierarchy. supports connects a Learning Component to a curriculum item. buildsTowards and relatesTo describe reviewed learning connections. An AI-suggested cross-curriculum similarity is something else again.

Keeping those claims separate means a downstream application can tell what came from the curriculum, what was added as reviewed graph structure, and what is the model’s own interpretation.

That gives AI a different starting point. Instead of asking a model to remember what a curriculum probably says, or to reconstruct its meaning from a PDF every time, we can give it a structured knowledge layer and ask it to reason over information whose meaning, context, and provenance remain visible.

The goal is to connect pieces of learning that we can name, inspect, and trust.