Plans

Rationale

Open EdTech proposes open infrastructure for a lifetime of learning: shared specifications, open-source software and public interoperability tests that let a person's learning travel with them across organisations and tools, under their own control. These are the reasons we think that plan makes sense.

1. The best learning technology is a good teacher. Every worthwhile thing we can build either makes the machine behave more like one, or puts you in front of one. Everything else on this page is the machinery needed to make those two things work, and to make them trustworthy.
2. Learning lasts a lifetime; our systems rarely do. People learn across schools, universities, workplaces, communities and private interests, but the records and work end up scattered across separate accounts that were never designed to talk to each other. Every change of institution, job or tool means starting again.
3. The problem hurts organisations too. A teacher rarely has usable context about what someone has already attempted. A receiving institution has to interpret unfamiliar records. A community programme has no easy way to give a learner a lasting copy of what it observed. Each organisation can improve its own system without ever solving the gaps between them.
4. A single central database is the wrong answer. A universal store of everyone's education would concentrate power and risk in one place. The useful question is how independently run systems can exchange what is needed while the learner keeps one coherent record of their own.
5. AI changes what learning tools have to do. Assistants can explain, translate, give feedback and complete work. Completing a task with help is not the same as being able to do it later without help. One study found that unguarded assistance improved students' performance while it was available and harmed it once it was taken away, while an assistant built to give hints rather than answers did no such harm (Bastani and colleagues, PNAS, 2025). That is one subject and one age group, but it is a clear warning that how assistance is designed matters.
6. Learning context should not be locked inside one assistant. If a person's learning history and preferences live inside one AI provider, changing provider means losing continuity. The context should sit with the learner and be shared with whichever assistant they choose.
7. The future of the interface is uncertain. Assistants will come from employers, institutions, commercial services and personal devices. Access to capable models, decent hardware and reliable connectivity will stay uneven for a long time. Infrastructure built around one provider, one model, or the assumption that everyone can run their own AI would be fragile, so the core functions must work without an assistant at all.
8. Control has to be practical, not a slogan. People need to see what is held about them, get it back in a usable form, correct it, decide what to share, learn privately, and recover from a lost phone or a forgotten password. None of that should need expertise in servers or cryptography. Those are design requirements, not nice-to-haves.
9. Education serves more than employment. Understanding the world, making music, caring for people and taking part in society are educational purposes too. Infrastructure built only around qualifications quietly excludes most of a life.
10. Healthy learning needs room for relationships and rest. Learning happens with teachers, peers and communities, often in physical places, and it competes for attention with feeds designed to keep you scrolling. A learning tool needs a different measure of success: does it help someone pursue something they value, including the freedom to stop? For the Coach that means treating local, face-to-face opportunities as the first option rather than a fallback.
11. Trust requires that nobody owns it. Technology that holds a lifetime of learning has to outlast any company, product or funding cycle. That is only possible when the infrastructure is open, when there is no mandatory service in the middle, and when any implementation can be replaced. A corporation cannot change the terms under your feet if there is no corporation in the loop.
12. Much of the groundwork already exists. Personal learning environments, portfolios, learning management systems, Open Badges and verifiable credentials have each solved part of this. What is missing is the connection between them, centred on the learner, with clear responsibilities and interoperability that has actually been tested.

Current design

The organising idea is a learner-controlled application we call the Coach. It exists to do two things: make whatever AI you use behave like a good teacher, and connect you with good teachers and places to learn near you. To do that it holds the goals, work, reflections and credentials a person chooses to keep, connects to the organisations they learn with, and supplies relevant context to AI assistants with the learner's permission. Organisations keep teaching, supporting, assessing and issuing credentials through their own systems. Assistants keep helping. Open EdTech defines how these parts work together.

Three parts, connected by open standards:

Responsibilities

Each part has a defined role. Much of the design is about being clear on which decisions belong to whom.

Three interfaces

The arrows on the diagram are the three exchanges Open EdTech specifies.

• Assistant to Coach. An assistant connects under a grant that names exactly which resources and actions it may use. Reading a project, updating a draft goal and submitting evidence are different capabilities. The Coach checks each action against the grant as it happens rather than trusting the assistant to remember its limits. Consequential actions, such as a new data-sharing relationship or a submission, need the learner's confirmation through a trusted interface.
• Coach to LMS. A relationship begins with an offer from the provider that states the programme, the data requested, what is optional, what comes back, retention and how it ends, and the learner's acceptance of those specific terms. After that, both sides exchange scoped messages: submitted work and selected activity one way, programme details, feedback, observations and credential offers the other. New requests for data need fresh agreement; updating published terms is not consent.
• Credential exchange. A provider issues a credential under its own authority and the Coach stores the original. Presenting it to a verifier is a separate act, authorised by the learner, that shows exactly what will be disclosed. A valid signature proves who made a claim, not that the claim is true or that anyone must recognise it.

Pedagogical profiles

A portable, readable description of how an assistant should help in a particular context: worked examples before practice, feedback after an attempt, explanations in a given language. A learner can write their own, install an educator's, or adopt one attached to a course. The Coach supplies the active profile to a compatible assistant. Profiles carry their author, version, purpose and known limitations, and conflicts are shown to the learner rather than silently merged. Whether profiles improve learning, and whether they work across different assistants, is a research question we intend to test rather than assume.

The learner's record

The record distinguishes what the learner wrote, what an educator observed and what an assistant inferred, and keeps that distinction through export, display and submission. A learner can edit their own reflection but cannot alter a signed judgement and present it as original. They can ask for a correction, attach a response, or simply not present it. A portable archive with a documented schema lets someone move from one Coach to another with work, context and permissions intact. Deleting a personal copy, asking a recipient to delete, and revoking future access are three different operations, and the design says so.

Where it runs

A Coach can run on the learner's own device, which gives the clearest separation from any institution, or be hosted, which makes participation easier for people who share devices or rely on mobile data. Either is legitimate. Both must be honest about who can read the data, who holds the keys, and how the learner leaves with everything. Backup and recovery are part of ordinary usability, not an advanced feature. The first release will support a few configurations well rather than every deployment model badly.

What is firm and what needs testing

Standards

Where a suitable standard exists we build on it and document anything we add, rather than inventing a new format for every part of education. These are the standards the current design draws on, what each is for, and how settled our use of it is.

• Model Context Protocol (MCP) for the assistant-to-Coach interface. MCP gives a defined way to expose data, tools and prompts to an assistant, and its prompts specification is the candidate mechanism for delivering pedagogical profiles. It does not by itself make an assistant follow a profile; each supported integration needs an explicit, tested agreement about that. Proposed; the exact protocol version will be pinned when the first integration is tested.
• W3C Verifiable Credentials and Open Badges for credentials. Established models for issuing and checking claims about achievement without a central registry. Proposed as the basis of the credential profile; the initial implementation will pick one precise combination that works across independent software and document it.
• OpenID credential exchange protocols for issuing and presenting credentials between a provider, a Coach and a verifier. Proposed; to be selected alongside the credential formats above.
• SD-JWT-based Verifiable Credentials as the reference for selective disclosure, so a learner can prove one achievement without revealing the whole portfolio. Draft 16 documents the capabilities and their limits. Under evaluation, not a commitment to use it.
• Structured exchanges over HTTPS for the Coach-to-LMS interface: enrolment, permissions, work, feedback and synchronisation as scoped, attributable messages with idempotent retries and explicit receipts. This is where Open EdTech expects to write its own specification, because no existing standard covers the whole relationship. LearnCard's ConsentFlow is the closest existing pattern for the consent part and will be evaluated before anything new is defined.
• Passkeys, decentralised identifiers and encrypted backups as candidate building blocks for identity, device authorisation and recovery. Under evaluation; none of them solves long-term identity or key recovery on its own, and that design needs independent review.
• OSI-approved open-source licences for anything that carries the Open EdTech certification mark, with AGPL-3.0 proposed for the reference applications so that improvements to hosted versions stay available. Proprietary software may implement the public interfaces; the mark is a separate commitment to openness.

Our specifications will keep the field names and meanings of the standards they adopt, and every published example will be validated against the chosen profiles before we offer it as guidance.

Certification

Claimed interoperability is worth little. Tested interoperability is the point. Open EdTech will run an automated conformance service that checks any submitted software against the published requirements. The question it answers is narrow on purpose: does this particular release implement the requirements, under the stated conditions?

• What is tested. Data exchange, permission enforcement, export and import, and defined failure cases: that permitted exchanges succeed, unpermitted requests fail, revoked grants stop new disclosures, duplicate messages are handled safely, and a migration preserves the required records.
• What every certified Coach must meet. The core requirements for portability, learner access and permissions. Optional capabilities are reported separately in a compatibility matrix, and no certification level excuses failing the learner-control commitments.
• A public record. Each result names the tested release, build configuration, test-suite version, date and outcome, and stays available. Certification attaches to an identified revision, never to a moving branch, and the mark links back to that record.
• Independence. A reference Coach and reference LMS built by the same team can share unspoken assumptions, so certification depends on independent implementations working from the written interface and reporting its ambiguities.
• Different kinds of evidence, reported as such. Automated conformance tests, accessibility review, security review and research into whether learning improves answer different questions. We will not present one as if it were another.

The service will start small, once the first interoperability tests pass between independent implementations. How it is governed, including how disputes about a test are settled and how misuse of the mark is dealt with, will be published alongside it.

Software

None yet. Open EdTech has not released any software. The first prototypes, a small reference Coach and a minimal provider-side implementation, are being built for testing and research and will be announced in News when they are ready to try. When they exist, this section will hold the download links, the source repositories, what each release is for, and a frank statement of how mature it is.

The first demonstrator will follow one learner across the boundaries that matter: create a goal, bring in a piece of work, connect an assistant with limited scope, establish a provider relationship, submit selected evidence, receive attributed feedback, and export to another Coach to see what survives. If you want to help build or test it, the community page is the place to start, and the Matrix room is where the work is discussed.