Curriculum Intelligence Infrastructure
Turning fragmented curriculum data into a connected system for mapping, coverage, planning and AI-assisted learning journeys.
Contents · 12 chapters
The information existed. The relationships didn’t.
- ROLE
- Product Designer
- TIMELINE
- 2025
- CLIENT
- Confidential / NDA
- DISCIPLINES
- Product Design · Systems Design · AI UX
The whole tool, rebuilt on invented data. Click through it.
All screens shown here are anonymised rebuilds using invented data.
The curriculum team was working across frameworks, competencies, learning resources, and content spread across multiple spreadsheets.
The information was there. The difficult part was answering questions across it.
- Does this competency correspond to something in another framework?
- What does a learner need to understand before reaching this competency?
- Do we already have content that teaches it?
- Which parts of the curriculum are underserved?
- Does this correspond to another framework?
- What comes before this competency?
- Do we have content that teaches it?
- Which parts are underserved?
Answering any of these meant piecing together information from different sources and rebuilding the relationships by hand.
Initially, this looked like a data-management problem.
It turned out to be a relationship problem.
A curriculum behaves more like a network than a list.
As I worked through the different curriculum workflows, I realised that the individual rows in a spreadsheet weren’t the interesting part.
What mattered was how they connected.
- A competency belongs to a framework.
- It may depend on another competency.
- It may correspond to an outcome in another framework.
- Multiple learning resources may address it to different degrees.
- And whether those resources exist affects what the content team needs to create.
So instead of treating Crosswalk, Coverage, Dependencies, Resources, and Learning Journeys as isolated workflows, I started looking at the common structure underneath them.
Framework → Competency → Dependencies → Resources → Coverage → Learning Journey → Content Planning
That became the foundation for the work.
The design question changed from:
How do we make curriculum data easier to manage?
to:
How do we make the relationships inside curriculum data visible and useful?
Comparing curricula without comparing spreadsheets
Different curriculum frameworks often describe similar learning outcomes using different structures and language.
Finding where two frameworks lined up meant reading competencies on both sides and judging how closely they matched.
I designed Crosswalk to bring that comparison into one workspace.
Users could pick two frameworks and see how their competencies related, without switching between sources.
But a simple match / no match model wasn’t enough.
Curriculum alignment can be messy. One competency might fully match another, another might cover only part of it, and sometimes there is no equivalent.
So the interface showed three states:
Covered · Partially covered · Missing
Each relationship could also carry a relevance score, mapping type, and review status.
- Search
- Compare
- Interpret
- Document
- Select frameworks
- Review relationships
- Identify gaps
This changed the workflow from:
Search → Compare → Interpret → Document
to:
Select frameworks → Review relationships → Identify gaps
The last state, Missing, turned out to be especially useful.
A missing relationship carried information.
The rest of the system could act on it.
Knowing what to teach means knowing what comes before it.
Learning outcomes don’t stand alone.
To understand one competency, a learner may first need knowledge represented by several earlier competencies.
Many of these prerequisites weren’t recorded anywhere in the existing information.
So I designed a dependency view that made them inspectable.
For any competency, a curriculum expert could see relationships such as:
- Existingprerequisites already connected
- Suggestedadditional relationships worth considering
- Missingpossible gaps in the learning sequence
- Needs reviewrelationships that may not belong
I didn’t want the system deciding the curriculum.
I wanted the structure visible enough for an expert to check it.
Once the dependencies were explicit, they were useful elsewhere too.
They could help answer not only:
“What is related to this competency?”
but:
“What should a learner encounter before reaching it?”
That led to the next workflow.
From finding competencies to sequencing learning
A curriculum expert could begin with an intent:
Framework · Learning level · Domain
From there, the system could use the curriculum structure to help build a learning journey.
The point wasn’t to put an AI prompt on top of the product.
The AI had context.
It could draw on the structured information underneath:
Competencies · Dependencies · Existing resources
That meant a generated journey could consider which competencies belonged in the sequence, what prerequisite knowledge might come first, and whether supporting content already existed.
- 01Competency A✓ Resource available
- 02Competency B✓ Resource available
- 03Competency C! Content gap
- 04Competency D✓ Resource available
A journey might look like:
- 01 — Competency A · Resource available
- 02 — Competency B · Resource available
- 03 — Competency C · Content gap
- 04 — Competency D · Resource available
So the prompt expressed the user’s intent.
The curriculum model provided the context.
AI became a reasoning layer over the curriculum infrastructure, rather than a replacement for it.
Having a lot of content doesn’t mean the curriculum is covered.
Once resources and competencies were connected, we could answer another question:
How much of this curriculum can our existing content actually support?
Instead of measuring the size of the content library, Coverage looked at the curriculum itself.
For each area, the team could see whether it was:
Covered · Partially covered · Not covered
| Numbers | Shapes | Measure | Patterns | |
|---|---|---|---|---|
| Level 01 | ||||
| Level 02 | ||||
| Level 03 | ||||
| Level 04 |
This made gaps visible across learning levels and domains rather than buried inside individual resources.
The question changed from:
“How much content do we have?”
to:
“Where is the curriculum underserved?”
That mattered, because a gap in the curriculum doesn’t always mean something new has to be made.
First you need to know what already exists.
A gap is a question about the library before it becomes a brief for new content.
When Coverage showed a gap, the next step was to look at the resources that already existed.
- A video might address most of a competency.
- An activity might cover one part of it.
- A game might be relevant across several curricula.
The Resource Map connected resources back to the competencies they supported and showed how much of each one they covered.
That gave a clearer path to a decision:
Identify gap → Inspect resources → Evaluate coverage → Reuse / Adapt / Create
It also worked in the other direction.
Starting with a resource, the team could see where it was being used and which curriculum outcomes depended on it.
Curriculum planning and content inventory were no longer separate views of the organisation.
They were two sides of the same system.
From understanding the curriculum to deciding what to create.
With the workflows connected, the system could answer a chain of questions, each more useful than the last.
- 01What does the curriculum expect?
- 02What does the learner need first?
- 03What do we already support?
- 04Do we already have something useful?
- 05What still needs to be created?
- What does the curriculum expect?Crosswalk showed how different frameworks related.
- What does the learner need first?Dependencies made prerequisite relationships visible.
- What do we already support?Coverage showed where existing content addressed the curriculum.
- Do we already have something useful?Resource Map connected gaps back to the content library.
And finally:
What still needs to be created?
The same information could now feed content planning.
A gap could first trigger a search for an existing resource.
If something suitable existed, it could be reused or adapted.
If not, the gap could become an input into new content creation.
When that content was linked back to the curriculum, coverage changed.
Curriculum → Gap → Resources → Reuse / Adapt / Create → Content → Coverage → Curriculum
back to curriculum
The loop closed.
One place to ask questions across the system
By this point, different workflows could answer different parts of the curriculum problem.
- Crosswalk handled alignment.
- Dependencies handled prerequisites.
- Coverage handled gaps.
- Resource Map handled the content library.
- Learning Journeys handled sequencing.
But nobody should have to remember which tool holds which answer.
The Companion was another way into the same infrastructure.
- Crosswalk
- Dependencies
- Coverage
- Resource Map
- Journeys
A user could ask:
- “Which competencies in this domain still need content?”
- “What prerequisites are missing here?”
- “Help me build a learning journey for this domain.”
It wasn’t a standalone chatbot. It could draw on the same structured curriculum data the workflows used.
The interface became conversational.The intelligence still came from the system beneath it.
What looked like several features was one connected system.
Crosswalk, Dependencies, Coverage, Resource Map, Learning Journeys, and the Companion could easily have become independent tools.
The more useful work was connecting them.
- A gap discovered while comparing frameworks could appear in Coverage.
- Coverage could lead to Resource Map.
- Resource Map could reveal that appropriate content didn’t exist.
- Dependencies could show what learners needed beforehand.
- Those relationships could help construct a Learning Journey.
- And the same information could then inform what content needed to be created.
Each workflow made the others more useful because they all worked from the same curriculum structure.
From storing curriculum information to understanding it.
The project wasn’t about replacing spreadsheets with nicer screens.
It was about moving from:
Search → Compare → Verify → Repeat
toward a connected curriculum model that could support:
Comparison · Sequencing · Coverage · Resources · Planning · AI assistance
The information already existed.
The design work was making its relationships explicit, then designing tools that let people use those relationships to answer real questions.
I designed the infrastructure connecting curriculum, content, and planning, and the product that made it useful.
- Role
- Product Designer
- Timeline
- 2025
- Client
- Confidential / NDA
- Disciplines
- Product Design · Systems Design · AI UX
The product, module by module
Every module as it stands in the working build. The names, frameworks and codes are demo data.
A journey starts as a sentence and a curriculum file. The draft lands in a grid, and the Companion reviews each objective as it’s written, with a fix you can apply in one click.
Describe it, get a first draft
Name, subject, framework and a one-line focus.
The Companion checks the grid
A verb-uniformity fix, with the old line struck through.
Coverage and the tree answer the same question from two sides: what this journey teaches, and what it still misses.
Every gap before it ships
22 of 48 objectives mapped, gaps first.
Grade to objective, one tree
Each objective mapped or flagged for review.
Dependencies make the order explicit. The Companion checks each prerequisite chain and suggests the one that fits; the chart shows the chain unit by unit.
What must come before what
A suggested swap, with Decline and Accept.
Every chain, unit by unit
One block per competency, one line per chain.
The crosswalk sets the core curriculum against each country’s framework. Every match carries a relevance score, and the hard ones come with a reason.
One core, every country
Pick a base and the frameworks to compare.
Matches you can trust
One-to-many matches explained, 96% relevance on the first row.
Coverage sheets and the resource map turn mapping into a commissioning list: what is fully covered, what rests on a single resource, and what has nothing at all.
Know what to commission
2 fully covered, 2 limited, 2 not covered.
Every resource, every objective
No interactives anywhere: a gap, not a mapping error.
The show planner closes the loop. Episodes are planned against objectives, and anything left uncovered is scaffolded from what the library already holds.
Plan the show around the learning
Two library resources offered for an uncovered objective.
Every show, and what it still needs
Coverage per series, with what is left to resolve.
MyGooru Companion
An AI companion that understands where you are, where you're going, and what might help you get there.