Designing a K–12 technology curriculum is a sequencing problem before it is a content problem. The list of things worth teaching is not seriously contested — coding, data, AI, hardware, security, design. What separates a programme that works from one that does not is the order, the pacing and the honesty about what the previous year actually delivered.
This is a summary of the design decisions we think matter, written as decisions rather than as principles, so they can be argued with.
Decision 1: Anchor on capability statements, not topics
A topic list (“Grade 7: Python, loops, functions”) tells you what was covered. A capability statement (“by the end of Grade 7, a student can take a described problem, decompose it, write a program that solves it, and explain why their approach failed on the first attempt”) tells you what was learned.
The practical difference shows up in assessment design and in the conversation with parents. Capability statements are harder to write and much harder to fake.
Decision 2: Foundations get more time than feels comfortable
The pressure on every technology curriculum is to accelerate. Parents ask when AI starts. Marketing rewards early mentions of robotics. The result is programmes that reach impressive-sounding content early and then stall, because the foundation cannot carry it.
Digital literacy and computational thinking are not the warm-up. They are the load-bearing structure. A student who cannot describe a process as a sequence of steps will not benefit from being shown a neural network diagram at nine years old, however good the diagram is.
Decision 3: Every year ends in an artefact
Not a test score — something that exists. This is the single most effective constraint we have found for keeping a curriculum honest, because it is very difficult to fool.
It also changes the teacher’s relationship with the material. A teacher preparing students to produce something has to have produced something themselves, which surfaces gaps in teacher preparation early rather than in Grade 11.
Decision 4: Hard concepts arrive twice
Almost every important concept in this field can be taught at two levels: as a tool to be directed, and as a system to be built.
Artificial intelligence is the clearest case. In Grade 6, a student can use a trained classifier, observe that it makes mistakes, and reason about why. In Grade 11, a student can train one, evaluate it properly and argue about its deployment. These are not competing options. The first makes the second land.
Introducing the concept only once — either too early to be understood or too late to be built on — is the most common structural error we see.
Decision 5: Local context is part of the specification
A project brief with a fixed scenario travels badly. A project brief with a defined technical objective and an explicit slot for the local problem travels everywhere.
This is not only about international portability. Inside a single country, a brief about metro transit is meaningless in a district town. Building the local slot into the specification is what makes the same rigorous objective usable across very different schools.
Decision 6: Design for the teacher you will actually have
Every curriculum is implicitly designed for a teacher. If that imagined teacher is a computer science graduate with industry experience and a free period for preparation, the curriculum will work in a small number of schools and fail in most.
Designing for a capable teacher who is not a technology specialist changes concrete things: worked reference solutions for every project, anticipated misconceptions written into the lesson notes, a stated fallback when the hardware does not work, and explicit guidance on what “good enough” looks like for a given grade.
Decision 7: Leave a deliberate slot for what is new
A curriculum written around specific tools ages badly and expensively. A curriculum written around durable concepts, with one explicit research-and-build unit in the senior years, can absorb what is genuinely new without a rewrite.
The trick is making that slot structural rather than decorative — with a defined shape (research, evaluate, prototype, present) so it does not become a term of unstructured enthusiasm.
What this looks like assembled
Grades 1–3. Confidence, intent, sequence. Digital literacy, creative computing, visual programming.
Grades 4–5. From following steps to designing them. Computational thinking, design, first structured coding.
Grades 6–8. Text-based programming, first interfaces, first hardware, AI as a directable tool.
Grades 9–10. Systems: real data, real users, security, teamwork, advanced robotics.
Grades 11–12. Practitioner work: advanced AI, data science, cloud, product development, research.
The shape is not unusual. The discipline is in refusing to accelerate past the parts that are not photogenic.
The test
A curriculum design can be evaluated with one question, asked of a real student rather than a document: show me what you built, and tell me what you would do differently.
A student who can answer that fluently has been through a functioning programme. A student who cannot has been through a syllabus.