What a knowledge graph really is

Many adaptive-learning platforms - Nodeledge included - use the term "knowledge graph" to describe the structure that captures relationships between their curriculum topics. The term is convenient and broadly recognisable, but it implies, perhaps unintentionally, that what you're looking at is the structure of the domain itself i.e. the objective relationships between ideas that hold regardless of who is teaching, in what order, or to whom. That's a stronger claim than the artifact actually warrants.

The education researcher Becky Allen describes this distinction in her piece The Curriculum Compression Problem: what most platforms have is not a knowledge graph but a curriculum graph - how a particular teacher or platform chooses to sequence learning, at what grain size, and with what emphasis. The two aren't the same object, and treating one as the other - which the term implicitly does - is a category error.

A curriculum graph approximates the knowledge graph as closely as the discipline allows. They are not the same object.

In tightly structured subjects like mathematics, a curriculum graph closely tracks the domain's actual dependency structure. You genuinely can't do calculus without limits, and any sensible curriculum will reflect that. The illusion that the curriculum graph is the knowledge graph is most powerful here, because the discipline itself does most of the work for the designer. In subjects with weaker intrinsic structure - history, for instance - the gap is much wider: the domain doesn't enforce much, so almost everything is a choice. Either way, what the graph actually encodes is a curriculum, not the abstract domain ideal.

We'll keep using "knowledge graph" in the rest of this post for the curriculum graph - it's the term most readers will recognise, and the one used widely in the field. But the precise reading is always: this is a curriculum graph, one that approximates the domain's dependency structure as closely as the discipline and our pedagogical judgement allow. For hierarchical technical subjects, that judgement is a large portion of what good curriculum design is.

Before you build a knowledge graph, you have to decide what a node actually is.

Online you'll often see "knowledge graphs" of subjects where the nodes are bare concept names - "derivative", "algebra", "conditional probability" - connected by arrows. "Algebra" has no mastery criterion. There's no clear answer to what it would mean for a learner to have passed it, and so no way to enforce a dependency on it. The graph may look beautiful - but it has little functional value.

The other extreme - one node per individual learning objective - is just as bad. The graph balloons, edges multiply (downstream lessons have to depend on many similar sibling nodes instead of one coherent topic), and the structure becomes unworkable - too fine-grained to author, review, or reason about.

The right level sits in between. A node should be a bite-sized topic that owns some new idea or skill the curriculum hasn't yet introduced. Inside the node sit two or three precise learning outcomes that pin down what mastery of that idea means: each outcome is testable, each has a clear mastery criterion, each is a thing the learner either can or can't do. The node's label is shorthand. The outcomes inside it are the contract.

A node's label is shorthand. The learning outcomes inside it are the contract.

There's also a size constraint that comes from cognition. Each node is delivered as a lesson, and a lesson should be small enough that a learner isn't asked to juggle too many interacting elements at once - cognitive load theory calls this "element interactivity" - and short enough to complete in one focused sitting, roughly ten to fifteen minutes. That's what "one lesson" means in operational terms.

Together these criteria pin down what counts as a node and what counts as passing one.

There are two ways you could imagine building a knowledge graph.

The backwards approach starts from a learning goal - "compute a derivative", say - and works back to whatever prerequisites the goal turns out to require. Every goal yields its own prerequisite set. The forwards approach starts from the structure of the discipline. Decide what topics matter, what depends on what, and lay them out as a graph that supports many different goals.

Backwards has obvious appeal. State your goal, the system computes the minimum prerequisites, you skip everything else. It sounds efficient. But it has three failure modes that show up quickly in practice.

First, goals are rarely stated precisely enough for backwards working to give clean answers. "I want to learn machine learning" doesn't pin down its prerequisites - building a classifier, implementing a paper, and doing original research all require different things. And most learners can't articulate exactly what they're after until they're some way in, if ever - they're non-experts by definition.

Second, even when goals are precise, each precise goal yields a different prerequisite graph, and the space of precise goals is unbounded.

Third, there's a coherent version of the backwards argument worth engaging: exam items are concrete and testable, so building a whole curriculum backwards from them feels more disciplined than working backwards from vague learner goals. For narrow goals - passing a specific exam, satisfying a specific competency - this works. But test items sample an outcome rather than define it, and a curriculum built from samples produces knowledge shaped to the test rather than the domain. That's fine when the goal is the test. It fails for building solid foundations, where the point is to support things the learner can't yet enumerate.

Forward construction sidesteps all three. Build the graph once, by hand, with the help of someone who knows the discipline. Then every learner draws from the same graph: pick a target, the system returns a path through the topics that come before it, specific to that target. The path won't be the bare minimum required to reach the goal - the graph encodes the standard scaffolding for the discipline, not goal-specific shortcuts - but it's coherent, ordered, and complete by construction. The upfront cost pays off because the same graph serves many learners and many goals.

What does this mean for the person actually doing the learning? Three things change.

Progression follows real prerequisites, not syllabus order. In most courses you progress one lesson after another - lesson 1, then 2, then 3 - even when the things in between aren't really prerequisites for where you want to go.

A graph fixes that. Edges mark real dependencies, so if there's no edge connecting two topics, you can jump between them. You're held back where it matters - where skipping a true prerequisite would make the next thing incomprehensible - and free where it doesn't. For technical subjects this is the right deal: real-prerequisite gaps make later material incomprehensible, while non-prerequisite gates just slow you down for no reason.

Reviews credit related practice, not just the item itself. Spaced repetition - reviewing material at increasing intervals - is one of the best-evidenced ways to lock things into long-term memory. Most apps treat each item separately: a flashcard for X, a flashcard for Y, no relationship between them.

A graph lets the review system do something more interesting. When you practise something advanced, you're often exercising the simpler ideas it was built on. Apply the chain rule and you're using the basic rules of differentiation along the way. The system can credit you for that: success on the harder thing nudges its prerequisites along; failure flags that something building on it might be at risk. You spend less time reviewing things you've genuinely retained, and the system has a richer picture of what you actually know.

Each learner gets a path computed from their target and current knowledge. You pick the topics you want to reach - eigenvalues and matrix factorisation, say. The system finds those nodes in the graph, walks back through their prerequisites, removes anything you've already shown you know (via a diagnostic test, for example), and gives you a path that's exactly what you need. The graph turns an off-the-shelf curriculum into one that's actually yours.

The graph turns curriculum design from implicit judgement into something explicit - that can be enforced, measured against, and adapted to each learner.

This is the architecture Nodeledge is built on. The graph enforces mastery learning; the spaced-repetition system propagates credit through it; custom learning paths give each learner the prerequisite structure for a target they choose. If you want the detail on any of those: How Nodeledge Works covers the architecture; Hierarchical Spaced Repetition covers the review system; and Custom Learning Paths and Diagnostic Tests covers personalised paths.

The graph isn't magic. It's curriculum design taken seriously, encoded so it can be enforced and adapted. For technical subjects, where structure matters, that's the right architecture - and what we're building.