NESA Machine Readable Curriculum and MCP Server

NESA came to us with a half-built curriculum publishing platform and a problem. It was being built on someone else's product, and that product could not do what NESA needed. It had been designed for university curriculums. Almost every NESA requirement meant customising or extending it. We were brought in to steer the platform in the right direction.

This is where most people misread the project. The NSW Digital Curriculum is not a website. It is the official record of every syllabus taught in New South Wales. Every learning area, every stage from Kindergarten to Year 12, every outcome, every content point, every prescribed text. Teachers use it daily, and schools, systems and assessment bodies rely on it. It also sits behind a curriculum reform with published dates, so publication cannot slip, and content that goes out wrong shows up in classrooms.

It was never only a screen, either. Teachers print curriculum content as Word or PDF documents, laid out differently from the site: no interactive parts, and their own choice of which syllabus sections and stages to include. So from day one the curriculum content had to be stored separately from the way any one destination shows it.

A platform carrying all that needs three things a normal site does not. Content structured the way a curriculum is actually organised, rather than the way a page is laid out. A record of every change that stands up to audit. And the ability to publish to more than one place, because the reader is not always a person.

We moved curriculum publishing onto Kontent.ai, a headless CMS. "Headless" means the content is stored on its own, with no fixed page design attached to it. That was the whole point, not a technical preference.

A traditional CMS ties each piece of content to the page it appears on. That is fine when there is one place for it to go. NESA had at least three, and the third did not exist yet: the curriculum site teachers read, the Word document syllabus prints teachers need, and eventually any system that wanted to read the curriculum as data. Tie content to pages and that third one stays expensive forever.

Kontent.ai let us store the curriculum as structured content, with the links between pieces recorded properly, and treat every output as one more view of the same source. It also gave NESA's curriculum teams a publishing process they own, with sign-off steps that match how a government agency actually approves content.

The option we advised against was staying on a system where the content followed the page design. It would have launched sooner. It would also have made everything further down this page either impossible or a rebuild.

One requirement shaped every decision after the CMS choice. A syllabus is a document with legal weight.

When a school reports on a student, when an assessment is written, when a teacher's program is audited, what matters is what the syllabus said at the time. Not what it says now. So the platform can never just overwrite content the way an ordinary CMS does. What the Stage 5 Mathematics outcomes said in June 2024 has to stay readable, word for word, indefinitely, next to what they say today.

That is why the Machine Readable Curriculum keeps history rather than replacing content. Every item keeps every version it has ever had. A system reading it can ask for the current version, an older version, or the full history of an item. Content changes in scheduled releases rather than continuously, so anyone reading it can say exactly which version they used. And NESA's team can see, item by item, what changed between any two releases.

Most systems like this treat history as a nice-to-have and are built for speed. This one was built to be accountable first, then made fast.

Sitting on content that other systems need?

That's the shape of problem we like. Thirty minutes, no pitch deck.

"Machine Readable Curriculum" is NESA's own term, and it appears in NESA's published tender for the work. It means what it says: the NSW curriculum, in a form software can read, not just people.

It has four parts.

The curriculum API is published through Azure API Management, Microsoft's front door for APIs. It is how a government agency safely runs an API other organisations will use. Each organisation gets its own key, which NESA can issue or switch off, and every request is logged against that key. So NESA can see who is reading the curriculum, and how much.

One detail is worth explaining, because it is the kind of thing that quietly breaks a system like this. To stay fast, Azure keeps a copy of recent answers and hands that out instead of asking again. That is exactly what you want for a curriculum that changes on set dates and is read constantly. But the moment a new release goes live, that saved copy is the old curriculum. So we tied clearing it to the release itself, rather than leaving it on a timer. Finishing a release marks the saved copies as out of date, and the next request gets the new content.

The API has also been through penetration testing, where security specialists try to break in on purpose. Findings were closed across the application, and across NESA's own infrastructure and Azure configuration.

First, what an MCP server is. The Model Context Protocol is an agreed way for AI assistants to connect to an outside source of information. An MCP server is the small piece of software that sits in front of your content and offers it to those assistants in a form they can use. Build one, and any AI assistant that speaks the protocol can read your content, on demand, from wherever the user already works.

We thought AI was where this was heading early on, and we raised the MCP approach with NESA well before it was the obvious answer. As AI assistants matured, NESA agreed it was the right direction.

The alternative was a chatbot on the curriculum site, and it was the shorter path. We had already proved the search technology behind one, using Azure AI Search. We argued against it, for a reason that has nothing to do with technology.

A chatbot means NESA pays for every question. Every teacher, every query, every follow-up is a cost NESA carries. So the more useful it gets, the more it costs, and sooner or later a budget conversation decides how useful it is allowed to be. For an agency serving every teacher in New South Wales, that is a pilot, not a service.

An MCP server turns that around. NESA publishes the curriculum once, in a form AI assistants can read. Teachers, schools and education companies connect using the AI subscription they already pay for, and ask their own questions on their own account. NESA's cost stays the same whether ten people use it or a hundred thousand.

None of that rules out a chatbot. For a defined group of people, a known set of questions and a volume you can predict, an assistant the organisation owns and controls can be exactly the right build. NESA's own internal teams are a good example. The economics only turn when the audience is every teacher in the state.

That is the difference between adding an AI feature and building AI groundwork, and it is the argument we would make to anyone holding content other people need. It is also the core of our AI services work.

The hardest part of this project was not connecting systems together, moving platforms or making things fast. It was deciding how the curriculum should be structured in the first place.

A curriculum is genuinely complicated. Learning areas contain syllabuses, syllabuses run across stages, stages carry focus areas, and focus areas carry outcomes and content points. Almost everything links to something else, across stages, across life-skills pathways, and across the K–10 and senior boundary, where the same course can legitimately appear more than once. Getting that structure right is hard on its own.

• →Syllabuses that don't work the same way. One structure had to hold them all: K–10 and senior, extensions, language examples, elective content and more, and the reading experience had to make sense for each.
• →A reform happening mid-flight. Some content fully reformed and on the new platform, some partly reformed, some still on an older system entirely, all managed from one place. And new features were being designed and built while content was being entered, against ministerial release dates that do not move.

The real difficulty was that the same content had to suit two quite different readers. Software needs the links between things spelled out exactly, with nothing left implied and nothing that only makes sense once you have seen the page. A teacher needs to look at the curriculum and understand it, laid out visually, in the order they think in, with the emphasis a document gives you and a plain data structure doesn't.

There is a second gap underneath that one. The way content is organised inside the CMS is built for the people entering it, and the printed documents understand its quirks and handle them. Those quirks are not appropriate for an outside audience reading the curriculum as data. So as well as reshaping the content for AI to read, we had to smooth over differences that matter a great deal to NESA's content team and mean nothing to anyone reading the API.

Build only for the machine and you get something correct that teachers won't use. Build only for the teacher and you get something readable that software will confidently misread, which is worse than useless when the subject is what a child is meant to be taught.

The mistake a less experienced team makes here is treating the machine-readable version as an export you generate at the end. It isn't a formatting job. If the structure underneath is unclear, no later conversion can make it clear. It can only guess, consistently, and be wrong in a way nobody notices until a teacher does.

The MCP server is in testing with the NESA team. Next comes rollout, and after that the interesting part.

Once a teacher can reach the curriculum through the AI assistant they already use, work that means reading across many pages and piecing it together becomes something you can simply ask for. Comparing a focus area with its previous version. Building a teaching program from the outcomes for a stage. Seeing the curriculum arranged the way you think about it rather than the way it appears on screen, while knowing it is the current published syllabus and nothing has been made up.

Further out, the same groundwork would support things we are not building yet: practice questions, assessment support, tutoring tools. None of that is committed work and we are not claiming it. It is worth saying only because it explains why the structure matters. Publishing the curriculum as data was never a feature. It is the layer everything after it stands on.