Proposed by: The Spix Foundation, for consideration by the African Union Development Agency (AUDA-NEPAD), in partnership with GovStack (specification governance and adoption)
Duration: 36 months (three years, structured as three phases with go/no-go gates)
Requested funding: USD 7M (staged across three phases with go/no-go gates)
Africa's DPI-Ed consists of two layers: a GovStack-compatible specification layer and an implementation layer. The implementation exists — RESPECT is a working platform stewarded by the Spix Foundation. The specification does not exist. It is purely notional. BEINGS will create it.
This proposal requests USD 7M over three years to develop and submit GovStack building block specifications for Digital Public Infrastructure for Education (DPI-Ed) — specifications that do not yet exist within GovStack's framework. Formal adoption as official GovStack specifications will follow GovStack's own governance processes.
BEINGS will fund African developers to learn GovStack's specification development methodology and governance processes, and to extract formal GovStack building block specifications from RESPECT's working code. The program will produce two parallel high-level building blocks:
The Learning Platform building block — specifying the required functions, APIs, workflows, and interoperations with other DPIs (Identity, Data Exchange, Payments) for a DPI-Ed learning platform. Because this specification is derived from RESPECT, compliance will require verified curriculum alignment, outcome measurement hooks, and content certification — the mechanisms that distinguish a quality-driven education ecosystem from an undifferentiated content marketplace.
The EMIS Interoperability building block — specifying the interfaces through which existing national Education Management Information Systems connect to and exchange data with DPI-Ed. EMIS systems are entrenched national infrastructure — the post-entrenchment landscape that GovStack was designed to accommodate (see Essay 3, Section 7). This building block will specify interoperability, ensuring that no Ministry must abandon its existing EMIS to participate in DPI-Ed.
Deliverables: a trained cohort of African GovStack specification developers; both building block specifications formally adopted within GovStack; a conformity testing sandbox for verifying DPI-Ed compliance; and documentation of the specification extraction methodology as a reusable model for future DPI sectors.
GovStack is the most mature, widely accepted specification framework for Digital Public Infrastructures. It defines the required functions, APIs, workflows, and interoperations of each DPI building block — currently covering nine foundational building blocks including Identity, Payments, Digital Registries, and Messaging. More than 80 technical experts from 40+ organizations have contributed to GovStack's specification work, and 20+ countries are actively using GovStack in their digital transformation strategies. (The architectural foundations are developed in Essay 3, "Digital Public Infrastructures (DPIs)," and the governance implications in Essay 14, "Governance and Sovereignty.")
GovStack has no education building blocks. No specification exists for a DPI-Ed learning platform, and no specification exists for EMIS interoperability with DPI-Ed. Without these specifications, DPI-Ed remains outside the global GovStack adoption wave — meaning that when a country adopts a GovStack-compatible DPI stack, education is absent. BEINGS will ensure education is present.
The specification extraction methodology is itself novel. GovStack specifications have historically been developed through expert working groups writing specifications from requirements. BEINGS will reverse the process: extracting formal specifications from working code. This "implementation-first, specification-second" approach produces specifications grounded in operational reality rather than aspirational requirements — and the methodology will be reusable for any DPI sector seeking to formalize working implementations into GovStack-compatible specifications.
BEINGS will train a cohort of 15–25 African developers in GovStack's specification development methodology and governance processes. Training will combine intensive workshops, mentored specification work, and participation in GovStack working groups. The trained cohort will be Africa's first community of GovStack specification developers — professionals capable of contributing to GovStack's evolution across sectors, not just education.
The Learning Platform building block will specify the required functions, APIs, workflows, and interoperations for a DPI-Ed learning platform. The specification will be extracted from RESPECT's working code by the trained developer cohort, with architectural guidance from GovStack specification experts and Spix Foundation engineers.
The specification will embed the architectural requirements that make RESPECT's ecosystem function:
These certification mechanisms apply equally to human-authored and AI-generated content, ensuring that AI-produced Apps and Localizations meet the same quality, safety, and pedagogical standards as traditionally authored products (see Essay 12: AI in Africa's DPI-Ed). Compliance with the resulting specification will require this quality-assurance architecture, setting a standard that rewards ecosystem quality over ecosystem volume.
The EMIS Interoperability building block will specify the interfaces through which existing national Education Management Information Systems — school management, student records, teacher records, enrollment — connect to and exchange data with DPI-Ed.
EMIS systems are already deployed in most African countries. They are entrenched national infrastructure. This building block will specify interoperability, not replacement — ensuring that Ministries retain full authority over their EMIS while gaining structured data exchange with DPI-Ed. The specification will accommodate diverse EMIS implementations through a thin-adapter approach: a common API surface with country-specific adapters for each national EMIS.
BEINGS will build a conformity testing sandbox for verifying DPI-Ed compliance. The sandbox will enable any implementation — RESPECT or alternatives — to test conformity with the published building block specifications through automated and semi-automated compliance checks. The sandbox will follow GovStack's existing testing patterns, extended for education-specific requirements.
BEINGS will document the methodology for extracting formal GovStack building block specifications from working code. This "implementation-first, specification-second" approach will be published as a reusable model for any DPI sector seeking to formalize working systems into GovStack-compatible specifications — applicable to health, agriculture, land registry, or any domain where leading-edge working implementations precede formal specification.
BEINGS depends on:
BEINGS amplifies:
Essay 14 describes the expected trajectory: as Africa's DPI-Ed specification matures and proves itself, it is expected to be incorporated into GovStack's global specification set. At that point, governance shifts from AU-led stewardship to multi-stakeholder GovStack governance, in which the African Union remains a major — but not sole — voice. BEINGS is the program that makes this pathway concrete: it produces the specifications that GovStack will absorb.
If this program produces formal GovStack building block specifications for DPI-Ed and a trained cohort of African specification developers (outputs), then DPI-Ed will become part of GovStack's globally recognized specification portfolio and any country adopting GovStack-compatible DPI stacks will gain education as an available building block (immediate outcome), which will accelerate international adoption of DPI-Ed beyond Africa and ensure that the quality-assurance architecture embedded in the specification sets a global standard for education DPI (intermediate outcome), which will establish Africa's DPI-Ed as the global reference for education digital public infrastructure — conceived in Africa, specified for the world (long-term impact).
Five precedents inform BEINGS's design:
| Precedent | Lesson | Application to BEINGS |
|---|---|---|
| GovStack's own building blocks (9 blocks, 80+ experts, 40+ organizations) | Formal specification development requires sustained expert engagement across multiple organizations, structured working groups, and iterative versioning. GovStack's process moved from 2020 launch to v1.0 publication in June 2023 — approximately three years for the first wave. | BEINGS's three-year timeline mirrors GovStack's own development trajectory for first-wave building blocks. The trained African developer cohort will participate in GovStack's established working group processes. |
| X-Road / NIIS (€50–60M/year system, Estonia-Finland-Iceland joint governance) | Cross-border interoperability specifications require joint governance structures and sustained institutional investment. NIIS demonstrates that small countries can jointly steward global-scale specifications. | BEINGS's EMIS Interoperability building block follows the thin-adapter pattern that X-Road proved: a common specification surface with country-specific adapters for entrenched national systems. |
| MOSIP ($28M initial investment, $5–7M/year operations) | A specification-plus-implementation approach to DPI achieves rapid multi-country adoption when the specification is open and the reference implementation is production-ready. | BEINGS reverses MOSIP's trajectory: where MOSIP built implementation and specification together, BEINGS extracts specification from an existing implementation. The methodology itself is a deliverable. |
| GIZ DataCipation (€41.3M over 6 years, 40 African countries) | Continental-scale digital policy development requires sustained institutional engagement, capacity building, and coordination across African governments. | BEINGS's developer training and GovStack governance participation will leverage GIZ's existing relationships across African digital transformation programs. |
| Linux kernel / POSIX specifications (specification extracted from working code) | The most durable specifications are those derived from working implementations, not from requirements documents. POSIX codified what Unix already did; it succeeded because it described reality. | BEINGS's specification extraction methodology follows this pattern: extracting formal specifications from RESPECT's working code produces specifications grounded in operational reality. |
BEINGS's timeline aligns with V&P_Core's deployment trajectory. The specifications must be mature enough to support V&P_Core's Phase 2 expansion (15 additional countries), when a formal GovStack-compatible specification will strengthen the procurement and adoption case for Ministries.
Goal: Train the African developer cohort, design the specification architecture for both building blocks, begin specification extraction from RESPECT's working code, and establish the GovStack working group structure.
Phase 1 requires V&P_Core to have deployed RESPECT in at least two pilot countries, providing operational code from which specifications will be extracted.
Milestones:
Goal: Complete both building block specifications through GovStack's review process, build the conformity testing sandbox, and begin the GovStack formal adoption process.
Phase 2 requires the following Phase 1 deliverables as inputs: Trained developer cohort, specification architecture documents, Learning Platform first draft, EMIS Interoperability scoping complete.
Milestones:
Goal: Achieve formal GovStack adoption of both building blocks, validate the conformity testing sandbox with multiple implementations, publish the specification extraction methodology, and transition specification maintenance to the developer cohort.
Phase 3 requires the following Phase 2 deliverables as inputs: Both specifications at v0.1, operational conformity testing sandbox, GovStack adoption process underway.
Milestones:
BEINGS aligns with European Development Partners with existing GovStack commitments:
GIZ (Germany's primary GovStack implementing agency) and BMZ (German Federal Ministry for Economic Cooperation and Development). Germany co-founded GovStack in 2020 and funds it through GIZ. GIZ's DataCipation program (€41.3M over 2020–2026) supports digital policy across 40 African countries. BEINGS provides a concrete, deliverable-oriented extension of Germany's GovStack investment into education — a new sector within an initiative Germany already champions.
The European Union. GovStack originated as an attempt to generalize Estonia's eGovernment across the EU. The EU's broader digital development portfolio includes education as a priority sector. BEINGS produces the specifications that make education part of the global GovStack adoption wave the EU is driving.
Finland. Finland co-founded NIIS (Nordic Institute for Interoperability Solutions) with Estonia, manages Suomi.fi Data Exchange on X-Road, and invests €497M in digital transformation. Finland's deep technical expertise in interoperability specifications and its NIIS governance experience make it a natural technical partner for BEINGS.
Estonia. As GovStack's institutional home (the GovStack Foundation is being established in Estonia), Estonia has direct interest in expanding GovStack's building block portfolio. DPI-Ed would be the first sector-specific building block family — demonstrating GovStack's extensibility beyond foundational infrastructure.
Three domains of expertise define the BEINGS leadership requirements:
Domain 1 — GovStack Specification Development. Experience developing or contributing to GovStack building block specifications, or equivalent formal API and interoperability specification work (W3C, IETF, ISO). Understanding of GovStack's governance processes, working group dynamics, and specification versioning methodology.
Domain 2 — Education Technology Architecture. Deep understanding of education platform architecture, EMIS systems, curriculum alignment, and the specific technical requirements of DPI-Ed. Experience with RESPECT's codebase or comparable education DPI systems.
Domain 3 — Developer Training and Capacity Building. Experience designing and delivering technical training programs in African contexts, particularly for specification development, open-source contribution, or standards governance.
| Institution | Role |
|---|---|
| AUDA-NEPAD | Continental legitimacy; Ministry relationships; EdTech Task Force coordination; political engagement with GovStack governance |
| The Spix Foundation | RESPECT codebase access for specification extraction; engineering expertise; conformity testing development; project management |
| GovStack / GovStack Foundation | Specification governance; working group infrastructure; formal adoption process; community review |
| GIZ | GovStack implementing partner; existing African digital transformation relationships; potential co-funding channel |
| NIIS (Estonia, Finland, Iceland) | Technical expertise in cross-border interoperability specifications; X-Road architectural patterns for EMIS adapter design |
| Ministries of Education (pilot countries) | EMIS system access for interoperability specification; pilot validation of conformity testing |
| ITU | GovStack founding partner; international telecommunications standards coordination |
| Category | Amount (USD) |
|---|---|
| Developer training and capacity building (15–25 African developers) | 1,200,000 |
| Learning Platform building block specification (extraction, drafting, review, adoption) | 1,800,000 |
| EMIS Interoperability building block specification (survey, drafting, review, adoption) | 1,000,000 |
| Conformity testing sandbox (development, validation, documentation) | 800,000 |
| GovStack governance participation (working groups, travel, diplomatic engagement) | 500,000 |
| Specification extraction methodology documentation | 300,000 |
| Program management (Spix Foundation) | 400,000 |
| Independent evaluation (midterm + final) | 200,000 |
| Contingency (~10%) | 800,000 |
| Total | 7,000,000 |
| Phase | Duration | Amount (USD) | Key Activities |
|---|---|---|---|
| Phase 1: Training + Architecture | Year 1 | 3,000,000 | Developer cohort training, GovStack engagement, specification architecture, Learning Platform first draft, EMIS scoping |
| Phase 2: Specification + Sandbox | Year 2 | 2,500,000 | Both specifications to v0.1, sandbox development, GovStack adoption process, midterm evaluation |
| Phase 3: Adoption + Methodology | Year 3 | 1,500,000 | Specifications to v1.0, sandbox validation, GovStack formal adoption, methodology documentation, cohort transition |
Funding is structured as staged commitments with go/no-go gates between phases (see Section 11). BEINGS's Phase 1 aligns with V&P_Core's Tranche 1 (Establishment and Early Scale); Phases 2–3 align with V&P_Core's Tranche 2 (Acceleration). See Essay 27, The Ask.
Developer training ($1.2M): Recruitment and intensive training of 15–25 African software developers in GovStack specification methodology. Cost includes training program design ($200K), intensive workshops — 4 months, including GovStack expert instructors, venue, and participant support ($400K), mentored specification work — 5 months of supervised practice ($300K), and GovStack working group participation support for the full cohort over 3 years ($300K). Per-developer cost of $48K–$80K is comparable to professional technical certification programs and includes sustained engagement over the program period, not just initial training.
Learning Platform building block ($1.8M): The larger of the two specifications. Cost includes specification architects — 2–3 senior architects for 18–24 months ($800K), code analysis and specification extraction from RESPECT ($300K), GovStack community review and revision cycles ($200K), interoperation specification with existing building blocks — Identity, Payments, Data Exchange ($300K), and publication and governance documentation ($200K). The specification must embed curriculum alignment, outcome measurement, and content certification requirements — adding complexity beyond a typical infrastructure building block. Comparable: GovStack's nine first-wave building blocks were developed over approximately three years by 80+ experts; a single education-specific building block at $1.8M is proportionate.
EMIS Interoperability building block ($1.0M): Smaller scope than the Learning Platform — focused on interfaces between entrenched EMIS systems and DPI-Ed. Cost includes EMIS landscape survey across pilot countries ($200K), specification architects — 2 architects for 12–18 months ($400K), adapter pattern design and validation ($200K), and GovStack review, revision, and publication ($200K). The specification must accommodate diverse EMIS implementations through a thin-adapter architecture — requiring fieldwork to understand country-specific variations.
Conformity testing sandbox ($800K): Software development of automated and semi-automated compliance testing infrastructure. Cost includes sandbox architecture and development ($400K), test suite development for both building blocks ($250K), and documentation and maintenance ($150K). The sandbox must test API conformity, functional requirements, and interoperation with existing GovStack building blocks. GovStack's existing testing patterns (GovTest) provide a starting framework.
GovStack governance participation ($500K): Three years of sustained engagement with GovStack working groups, steering committees, and governance processes. Cost includes travel for cohort members and program leadership to GovStack events ($250K), diplomatic and political engagement to secure formal building block adoption ($150K), and legal review of specification licensing and intellectual property ($100K).
Methodology documentation ($300K): Technical writing, case study development, and peer review of the specification extraction methodology. Cost includes documentation team ($200K) and external review and publication ($100K). The methodology is a novel deliverable — no established template exists for "implementation-first, specification-second" GovStack specification development.
Program management ($400K): Spix Foundation project coordination over three years, including reporting, monitoring, Development Partner engagement, and integration with GovStack's specification governance timeline.
Independent evaluation ($200K): Midterm (Month 24) and final (Month 36) external evaluations. Evaluation criteria: specification quality and GovStack adoption status, conformity testing functionality, cohort capability, and methodology applicability.
Contingency (~10%) reflects uncertainty in GovStack's governance timeline (adoption processes may be faster or slower than anticipated), EMIS landscape diversity across pilot countries, and the novelty of the specification extraction methodology.
The program will be independently evaluated at Month 24 (midterm) and Month 36 (final) by an external evaluator nominated by the Development Partner. Evaluation criteria include: specification technical quality, GovStack governance engagement and adoption progress, developer cohort capability, conformity testing sandbox functionality, and methodology documentation quality.
Phase 1 → Phase 2 gate (Month 12): The developer cohort is trained and actively participating in GovStack working groups. The specification architecture for both building blocks is designed and published for review. The Learning Platform first draft is under development. EMIS scoping is complete with survey data from at least three pilot countries.
Phase 2 → Phase 3 gate (Month 24): Both specifications are at v0.1 and under GovStack community review. The conformity testing sandbox is under development and RESPECT's code is being tested against the draft specifications. GovStack's governing body has accepted both building blocks into its adoption pipeline. The midterm evaluation confirms specification quality and program viability.
If GovStack declines to adopt DPI-Ed building blocks or the adoption process stalls, the program will have produced four outputs with independent value: (a) the first formal specifications for education digital public infrastructure — usable by any country or organization building education DPI, regardless of GovStack adoption; (b) a trained cohort of African specification developers capable of participating in global DPI governance across sectors; (c) a conformity testing sandbox usable for verifying DPI-Ed compliance independently of GovStack; (d) a specification extraction methodology applicable to any DPI sector. The specifications and sandbox have value whether or not they carry the GovStack label.
| Risk | Mitigation |
|---|---|
| GovStack declines to adopt education building blocks | GovStack's founding partners (GIZ, BMZ, Estonia, ITU) have institutional interest in expanding the building block portfolio. Education is a high-demand sector. If adoption is delayed, the specifications retain independent value and can be published as AU-endorsed DPI-Ed standards. |
| GovStack governance processes take longer than anticipated | The three-year timeline mirrors GovStack's own first-wave development trajectory. Phase 3 contingency provides buffer. If formal adoption extends beyond Month 36, the specifications will be at v1.0 and usable; only the GovStack label will be pending. |
| Developer cohort lacks sufficient technical depth | Recruitment criteria will emphasize software engineering experience. Training combines intensive workshops with mentored specification work under GovStack expert supervision. Cohort members who do not achieve specification-writing capability can contribute to conformity testing or documentation. |
| RESPECT codebase is insufficiently mature for specification extraction | V&P_Core deployment in pilot countries provides operational validation. Specification extraction can proceed in phases — extracting well-established components first while platform-evolving components mature. |
| EMIS diversity across countries makes a common specification impractical | The specification uses a thin-adapter architecture specifically designed for the post-entrenchment landscape. The common API surface specifies interoperability requirements; country-specific adapters accommodate EMIS variation. This is the same pattern X-Road uses across Estonia, Finland, and Iceland. |
| Specification becomes detached from implementation reality | The "implementation-first" methodology is specifically designed to prevent this. Specifications are extracted from working code, not written from aspirational requirements. The conformity testing sandbox validates that the specification describes what RESPECT actually does. |
| Trained developers do not remain engaged after program ends | GovStack working group participation creates professional networks and career opportunities in global DPI governance. The specification maintenance role provides ongoing professional value. African developers participating in global standards governance is itself a durable outcome. |
GovStack specifications are maintained through GovStack's standing governance processes — working groups, community review, and versioned releases. Once BEINGS's building blocks are formally adopted, their maintenance follows GovStack's standard lifecycle. The trained African developer cohort will be positioned to participate in this ongoing governance, ensuring African voice in the specifications' evolution.
Essay 14 describes the trajectory: as Africa's DPI-Ed specification matures, it is expected to be incorporated into GovStack's global specification set, with governance shifting from AU-led stewardship to multi-stakeholder GovStack governance. BEINGS is the program that achieves this incorporation. Post-BEINGS, the specifications live within GovStack's global framework, maintained through GovStack's own institutional resources.
The specification extraction methodology is the program's scaling mechanism. Every DPI sector — health, agriculture, land registry, civil registration — faces the same challenge: working implementations exist, but formal GovStack specifications do not. BEINGS's methodology provides a replicable template for formalizing any working DPI into GovStack-compatible specifications. The methodology scales the investment far beyond education.
Africa's DPI-Ed has an implementation. It does not have a specification. BEINGS will create one.
The two building block specifications — Learning Platform and EMIS Interoperability — will convert Africa's DPI-Ed from notionally GovStack-compatible to formally specified within the global framework. When a country adopts a GovStack-compatible DPI stack, education will be an available building block. When a Ministry procures education technology, a GovStack-compliant DPI-Ed specification will define what compliance means. And because the specification is derived from RESPECT, the quality-assurance architecture that distinguishes a standards-based education ecosystem from an undifferentiated content marketplace will be embedded in the global standard.
The trained African developer cohort will be the first African professionals participating in GovStack specification governance — contributing to the specifications that will shape digital public infrastructure worldwide. The specification extraction methodology will be reusable across any DPI sector. And the conformity testing sandbox will provide the verification infrastructure that makes compliance testable, not just claimable.
Three years. Two specifications. One methodology. Africa's DPI-Ed, specified for the world.