#OpenGov Mesh — Specification

#How to read this document

This specification has two audiences and is layered accordingly.

Part I (sections 1-10) — “Why adopt” is written for a non-technical reader: a minister, a permanent secretary, a CIO, or a donor. It is pedagogical, concise, and concrete. It explains the problem the Mesh solves, the trade-offs that shaped the design, and what a sponsor government commits to and gets in return. About 10 pages.

Part II (sections 11-14) — “Technical executive overview” is written for a solution architect or engineering lead. It compresses the entire technical design into a navigable map, with a quickstart and the federation primitive explained. About 5 pages.

Parts III through VIII (sections 15-46) — “Detailed specification” are written for the development team that implements the Mesh. They contain the wire protocols, data models, API surfaces, sequence diagrams, schemas, and acceptance criteria. About 60-90 pages.

A reader who reads only Part I should leave with enough understanding to decide whether to fund a pilot. A reader who reads Parts I-II should be able to defend the design in a CTO-level review. A reader who reads the whole document should be able to implement the Mesh from scratch without further consultation.

The document is intended to be self-contained: every claim it makes can be either traced to a referenced standard (RFC, OpenAPI, eIDAS) or verified against a runnable command in Part VIII.

#Conventions

The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174 when, and only when, they appear in all capitals.

JSON examples use RFC 8259 strict JSON. Schemas reference JSON Schema 2020-12. HTTP signatures are RFC 9421. Cryptographic primitives use Ed25519 (RFC 8032) and X25519 for key agreement where applicable.

Code blocks marked # evidence are commands you can run against the MVP reference implementation; their expected output is given in Part VIII.

#Table of contents

Part I — Why adopt the OpenGov Mesh (pedagogical)

1. The problem in one citizen story
2. The cost of doing nothing
3. What X-Road got right, what it left undone
4. What the Mesh adds
5. What it changes for each actor
6. Regulatory & compliance map
7. What it costs and what we ask of a sponsor government
8. Honest limitations — what the Mesh does not do
9. Why now
10. The adoption path

Part II — Technical executive overview

11. Architecture in one page
12. The five planes — brief
13. The federation primitive — brief
14. Project governance & licence trajectory

Part III — Trust Plane (detailed)

15. PKI hierarchy and root authority
16. Member registry & transparency log
17. Enrolment protocol
18. Certificate format & signing profile
19. Revocation (OCSP + CRL) & rotation
20. Federation primitive (cross-signing & trust manifest)
21. Trust Plane API surface
22. Operational profile (HSM, backup/DR, witnesses, ceremonies, recovery)
23. Forward references — coupling with other planes

Part IV — Transport Plane (detailed) — to be written in subsequent commits

24. Sidecar architecture
25. Message envelope & wire format
26. RFC 9421 signature profile
27. Replay protection & idempotency
28. Store-and-forward with NATS JetStream
29. Circuit breaker, rate limiting, retry
30. Federation routing
31. Transport Plane API surface

Part V — Catalog Plane (detailed) — to be written in subsequent commits

32. OpenAPI 3.1 + AsyncAPI 3.0 publication
33. Versioning & breaking-change detection
34. Pact contract testing
35. Search, discovery, public mirror
36. Catalog Plane API surface

Part VI — Observability Plane (detailed) — to be written in subsequent commits

37. OpenTelemetry semantic conventions for gov.mesh.*
38. Audit event format & hash chaining
39. Verification CLI & replay protocol
40. Archival to S3-compatible storage
41. Provisioned dashboards

Part VII — Consent Plane (detailed) — to be written in subsequent commits

42. Consent record schema
43. Ledger storage & hash chaining
44. USSD flow protocol
45. SMS notifications
46. eIDAS 2.0 SD-JWT-ready wallet format
47. Citizen self-service & right-to-be-forgotten

Part VIII — Integration, federation E2E, operations, acceptance — to be written in subsequent commits

48. SmartLink integration (mesh:// connector)
49. Federation E2E scenario (Lesotho ↔︎ South Africa)
50. CLI & runbooks
51. Deployment (docker-compose) & benchmarks
52. Acceptance criteria with executable evidence

#Part I — Why adopt the OpenGov Mesh

Read this part if you are deciding whether to fund a pilot. No prior technical knowledge is assumed.

#1. The problem in one citizen story

Tšepo lives in Maseru. He lost his national identity card and went to the Ministry of Home Affairs to ask for a replacement. The clerk asked for the original birth certificate. Tšepo did not have it; it had burned with the rest of the family papers in 2024.

The clerk explained the procedure: Tšepo must request a copy of the birth certificate from the Civil Registry, which is housed in a building twelve kilometres away. The Civil Registry will issue the copy, but it asks for a tax-clearance certificate from the Lesotho Revenue Authority — because the office wants to be sure that the requester is up to date with the small administrative fee. The Revenue Authority will issue the tax clearance, but it asks for proof of residential address — a document that the local chief issues — which itself requires a current ID, the very thing Tšepo came in to replace.

Tšepo will spend three working days, two minibus rides, and roughly 240 maloti to obtain a card that costs the state 35 maloti to print.

The agencies involved already hold every piece of information needed to serve Tšepo in fifteen minutes:

• Home Affairs holds Tšepo’s birth-certificate digital index.
• The Revenue Authority holds his tax history.
• The chief’s office holds his attested residency.

They do not talk to each other. Each agency built its own database in its own decade with its own vendor; the systems are not connected; nobody trusts the others’ data; and there is no infrastructure that lets one office verify a fact held by another office in a way that is auditable, consented to by Tšepo, and legally reliable.

Tšepo’s story is repeated millions of times a year in every country we work with. The Mesh exists to end it.

#2. The cost of doing nothing

The cost of agency silos is rarely measured because nobody is responsible for measuring it. When it is measured, the result is striking.

These numbers are not estimates of what the Mesh saves. They are the cost of the status quo. The Mesh captures a fraction of these costs and converts them into a one-time investment in shared infrastructure. The fraction captured depends on adoption breadth, on the mandate strength, and on the quality of the implementation. The fraction is never zero, and in countries that have made comparable investments (Estonia, Denmark, India for authentication, Brazil for tax, Singapore for benefits) the return has been broadly accepted as positive within five years of full deployment.

The status-quo costs also accumulate. Every year a country waits, more bespoke point-to-point integrations are built between two specific agencies to solve two specific problems. Each of these integrations is sunk cost that has to be migrated or retired when a Mesh is later introduced. The later a country adopts a Mesh, the larger the migration debt — and the weaker the political case, because incumbents have learned to live with the silos.

#3. What X-Road got right, what it left undone

We owe a great deal to X-Road. It was the first widely deployed national data-exchange layer; it has run continuously since 2001; the Estonian public sector is unimaginable without it; the Nordic Institute for Interoperability Solutions (NIIS) maintains it as open-source under EUPL. The Mesh reuses many of its ideas. Where the Mesh diverges, the divergence is grounded in twenty-five years of operational evidence — about what X-Road was built for, and what it was not.

#What X-Road got right

#What X-Road left undone

These are not criticisms of X-Road’s authors — every system reflects the era it was built in. They are observations of what a country adopting a data-exchange layer in 2026 should expect, and what X-Road as currently shipped does not provide.

The Mesh is X-Road as it would have been designed in 2026, with twenty-five years of operational hindsight, on top of the standards that did not exist when X-Road was conceived (OpenTelemetry, RFC 9421 HTTP Message Signatures, OpenAPI 3.1, AsyncAPI 3.0, eIDAS 2.0 wallet, CloudEvents). It is not a fork or a competitor of X-Road. Where a country has adopted X-Road and is satisfied, the Mesh adds no value. Where a country is choosing today, the Mesh offers a path that is lighter to operate, federated without institutional gatekeepers, and consent-native by design.

#4. What the Mesh adds

The Mesh is structured as five planes, each addressing a concern that in X-Road is either absent or bolted on.

#4.1 Trust Plane

The Trust Plane is the national PKI — the certificate authority, the member registry, the timestamping authority, and the transparency log that records every change to the registry in a way that is independently verifiable.

What the Mesh adds beyond X-Road’s equivalent:

• Light-weight enrolment — a member is added with a CSR signed by the national CA in minutes, not days. The heavy bilateral accord remains necessary as a legal artefact, but it does not gate the technical enrolment.
• Federation by cross-signing — two countries’ Mesh roots can sign each other’s roots through a documented, time-bounded trust manifest. No central authority is involved. The cross-signing can be revoked unilaterally by either side at any time.
• Public transparency log — every change to the member registry (additions, revocations, key rotations) is appended to a Merkle log whose root is published daily. Any third party — opposition party, press, oversight body — can verify that the registry has not been tampered with retrospectively.

#4.2 Transport Plane

The Transport Plane is the secure wire that carries every message between agencies. It runs as a small sidecar process on each agency’s network — the equivalent of X-Road’s Security Server, but lightweight.

What the Mesh adds:

• Compact deployment footprint — the full per-agency stack (sidecar + Redis for replay + NATS for store-and-forward) fits in ~250–300 MB of RAM and deploys on a 1 GB VM or a Raspberry Pi 4. The comparison point is X-Road’s Security Server appliance, which requires 4–8 GB RAM minimum. The Mesh sidecar is on the same order of magnitude as a typical reverse proxy, not a Java enterprise appliance. Part IV §24 specifies the exact footprint and the cost/complexity case for the chosen Python stack.
• RFC 9421 HTTP Message Signatures — the modern IETF standard, replacing the WS-Security era cryptography of X-Road. Native to OpenAPI tooling.
• Store-and-forward by default — when a recipient agency is offline (a chronic reality in countries with mountainous geography or intermittent power), the message queues in NATS JetStream and is delivered when the link returns. The sender does not need to know the recipient’s availability. (Tier-specific: the Tier-B clustered deployment, Part IV §28.2, additionally survives a 5-min NATS partition without operator action; the Tier-A standalone deployment survives sender-side process crashes and peer-side outages but cannot survive a partition between sidecar and the colocated NATS daemon — that window fails dispatch. Sponsors choose the tier in the MoU.)
• CloudEvents for asynchronous flows — when a payment lands at the Revenue Authority, a CloudEvent travels to the Civil Registry, Customs, and the agency that issued the licence — all via the Mesh, all signed, all audited.

#4.3 Catalog Plane

The Catalog Plane is the directory of services that any member can publish and any other member can discover.

What the Mesh adds:

• OpenAPI 3.1 native — services are described in the same language developers already use everywhere else.
• AsyncAPI 3.0 for events — symmetrical treatment of synchronous and asynchronous services.
• Breaking-change gates — a publisher cannot publish a new version that breaks existing consumers without an explicit migration window declared in the catalogue. The breaking-change detector is invoked at publication time and the publication is rejected if violated.
• Pact-style contract testing — consumers register their expectations, and the catalogue refuses to certify a service as production-ready unless its publisher has run all consumer expectations and they pass. Drift is impossible by construction.
• Public mirror — the entire catalogue is mirrored to a public repository (signed JSON), so an outside observer can audit what the national government has exposed and to whom.

#4.4 Observability Plane

The Observability Plane is the audit trail and the operational telemetry.

What the Mesh adds:

• OpenTelemetry-native — uses the modern observability standard, with semantic conventions for the government domain (gov.mesh.*) documented in this spec.
• Hash-chained audit log — every audit event references the hash of the previous one, making any retrospective tampering immediately detectable. The chain head is published daily, alongside the registry Merkle root.
• Verifiable replay — mesh-cli audit verify replays the chain and confirms integrity. Any auditor — a court, an opposition party, a donor — can run it.
• Provisioned dashboards — the MVP ships with a Grafana stack that shows latency, error rate, signature rejections, audit volume, and per-agency activity, out of the box.

#4.5 Consent Plane

The Consent Plane is the part that has no analogue in X-Road and that, in the eIDAS 2.0 era, is no longer optional.

What the Mesh adds:

• First-class consent records — a citizen consents to a specific agency processing a specific class of their data for a specific purpose, for a specific period. Every cross-agency request the Mesh carries references a consent ID that is checked at the wire level before the request is delivered.
• USSD-first — citizens give consent over USSD on feature phones. In countries where 50%–80% of citizens cannot give consent on a smartphone, this is the difference between a consent regime that exists on paper and one that exists in fact.
• SMS notifications — every consent grant, every cross-agency request involving the citizen’s data, generates an SMS. The citizen is always informed.
• eIDAS 2.0-ready wallet integration — for citizens with smartphones, consent is portable as an SD-JWT verifiable credential, ready for the eIDAS 2.0 wallet ecosystem.
• Right-to-be-forgotten propagation — when a citizen revokes consent or invokes erasure, the revocation propagates as a signed event to every agency that ever held a reference. No silent retention.

#5. What it changes for each actor

#6. Regulatory & compliance map

The Mesh is designed to satisfy, by construction, the requirements of the following regulatory frameworks. Each row maps a regulation to the Mesh component that addresses it.

The Mesh is not a substitute for compliance certification; it is a substrate that makes compliance evidence available by default.

#7. What it costs and what we ask of a sponsor government

The Mesh is offered to a sponsor government under a bilateral pilot agreement during the pre-pilot phase. The agreement defines the following commitments on each side.

#What UNCTAD provides

• The Mesh reference implementation (source code, Docker images, deployment scripts) under the pre-pilot licence.
• The full specification (this document) in the sponsor’s working language(s).
• A two-person UNCTAD engagement team for the duration of the pilot, funded by UNCTAD’s own resources, providing remote support and at least two on-site missions.
• Training of the sponsor’s operational team on the Trust Plane, Transport Plane, and Observability Plane (minimum five engineers, two operators).
• Co-publication of any pilot evaluation report.

#What the sponsor government commits to

• A named executive sponsor at minister or PS level, accountable for the pilot’s political progression.
• A named operational owner (typically the head of the national government computing centre or equivalent) accountable for the deployment’s continuous operation.
• A legal mandate for at least three pilot agencies to participate — this can be a memorandum of understanding signed by the executive sponsor; it does not require legislation in the pilot phase.
• Three pilot agencies participating in a defined, bounded set of cross-agency operations. UNCTAD does not select; the sponsor does.
• A root-CA-operating party — typically the national government computing centre — that will operate the Trust Plane root in production. During the pilot the root may run in a UNCTAD-provided sandbox; for production deployment the sponsor must designate the national operator.
• Dedicated infrastructure: roughly two virtual machines (4 cores, 8 GB RAM each) plus three small sidecars (1 core, 1 GB each, one per participating agency). Total monthly compute cost in commercial cloud is on the order of USD 500.
• Observability hosting — either co-located with the above, or routed to a national logging facility if one exists.
• A public co-communication moment at the conclusion of the pilot (joint press release, blog post, or conference presentation), contingent on the pilot meeting its agreed acceptance criteria.

#Indicative pilot envelope

A six-month bilateral pilot covering three agencies, one cross-agency synchronous operation, one cross-agency asynchronous operation, and one USSD consent flow, with the federation primitive demonstrated against a second mocked country, fits within a budget of approximately USD 250 000–400 000 all-inclusive. Of this, UNCTAD typically funds 60%–70% from its own resources or partner-donor pooled funds; the sponsor covers infrastructure, civil-servant time, and the legal/operational mandate. The exact envelope is settled in the bilateral agreement.

The Mesh cannot succeed in a pilot whose budget is significantly below this band. We would rather decline a pilot than under-resource it.

#8. Honest limitations — what the Mesh does not do

A specification that does not state its limitations is unreadable.

We list these because over-promising is the single most common failure mode of government-IT specifications, and because a sponsor who reads them and still chooses to adopt is a sponsor who can be supported.

#9. Why now

The Mesh has been technically possible for at least five years. Three forces converging in 2026 make it strategically unavoidable.

1. eIDAS 2.0 wave (2024–2026). The European Union’s eIDAS 2.0 regulation has produced a generation of wallet-compatible standards (SD-JWT-VC, OpenID4VP, OpenID4VCI). Countries adopting these now will carry forward; those who do not will rebuild later at higher cost. The Mesh is wallet-compatible at the consent plane.

2. AfCFTA Digital Trade Protocol (signed 2024, ratification phase). The African Continental Free Trade Area’s digital trade protocol commits signatory countries to digital interoperability across borders. The protocol does not specify the technical fabric. The Mesh — with its bilateral federation primitive that requires no continental institution — fits the political reality of AfCFTA ratification better than any centrally-governed alternative.

3. The end of the SOAP era. Government systems built before 2010 are reaching end-of-life simultaneously across many countries. The replacement decisions being made in 2026–2028 will determine the national integration fabric for the next twenty years. Choosing X-Road today is choosing 2001-era ergonomics. Choosing a bespoke vendor stack is choosing lock-in. Choosing the Mesh is choosing a 2026 standard under a public-good licence trajectory.

A country that adopts in 2026 is choosing infrastructure for 2026–2046. The choice is real, the window is open now, and it will not stay open.

#10. The adoption path

Adoption proceeds through five gates. Each gate is binary: either passed or not. UNCTAD will not take a country past a gate that has not been passed.

A sponsor government and UNCTAD evaluate jointly at each gate. Failure at G0 or G1 means the sponsor is not ready, and we say so. Failure at G2 or G3 means the implementation is not ready, and we say so. We have no interest in deployments that do not work, and the worst possible outcome for the Mesh as a public good is a high-profile deployment that fails because it was launched before its political and operational preconditions were in place.

#Part II — Technical executive overview

Read this part if you are a CIO or solution architect. It compresses the whole technical design into a navigable map.

#11. Architecture in one page

                                 Public mirror (signed JSON, daily)
                                         ▲
                                         │
                  ┌──────────────────────┴───────────────────────────┐
                  │           TRUST PLANE (national)                  │
                  │  • Root + Issuing CA (step-ca, Ed25519)           │
                  │  • Member registry (PG, Merkle log, daily anchor) │
                  │  • TSA bridge (national QTSP)                     │
                  │  • OCSP responder + CRL publisher                 │
                  │    (mesh-internal services — see Part III §19.1;  │
                  │     step-ca alone does not serve OCSP/CRL)        │
                  │  • Federation manifest store (cross-signed peers) │
                  └─────────────┬────────────────────────────────────┘
                                │ signed cert chains, revocations,
                                │ federation manifests, TSA tokens
              ┌─────────────────┼─────────────────────┐
              │                 │                     │
       ┌──────▼──────┐    ┌─────▼──────┐       ┌──────▼──────┐
       │  Agency A   │    │  Agency B  │       │  Agency C   │
       │  ┌────────┐ │    │ ┌────────┐ │       │ ┌────────┐  │
       │  │Sidecar │◄┼────┼─┤Sidecar │◄┼───────┼─┤Sidecar │  │
       │  └───┬────┘ │mTLS│ └───┬────┘ │RFC9421│ └───┬────┘  │
       │      │      │    │     │      │       │     │       │
       │  ┌───▼────┐ │    │ ┌───▼────┐ │       │ ┌───▼────┐  │
       │  │  App   │ │    │ │  App   │ │       │ │  App   │  │
       │  └────────┘ │    │ └────────┘ │       │ └────────┘  │
       └─────────────┘    └────────────┘       └─────────────┘
              │                 │                     │
              └─────────────────┴─────────────────────┘
                                │ OTel traces + signed audit events
                                ▼
                  ┌──────────────────────────────────┐
                  │    OBSERVABILITY PLANE            │
                  │  • OTel collector → Loki/Tempo    │
                  │  • Audit ledger (PG, hash chain)  │
                  │  • Daily root anchor (public)     │
                  │  • Cold archive (MinIO at MVP;    │
                  │     S3 / Azure / GCS via per-     │
                  │     cloud adapter at production — │
                  │     §40.2.3 feature parity)       │
                  │  • Grafana dashboards (provisioned)│
                  └──────────────────────────────────┘
                                │ purpose checks, citizen lookups
                                ▼
                  ┌──────────────────────────────────┐
                  │       CONSENT PLANE               │
                  │  • Consent ledger (PG, hash chain)│
                  │  • USSD gateway (pluggable: AT…)  │
                  │  • SMS notifier (pluggable)       │
                  │  • SD-JWT VC issuer (eIDAS 2.0)   │
                  │  • Citizen self-service API + UI  │
                  └──────────────────────────────────┘
                                │ OpenAPI/AsyncAPI publication
                                ▼
                  ┌──────────────────────────────────┐
                  │       CATALOG PLANE               │
                  │  • OpenAPI 3.1 + AsyncAPI 3.0     │
                  │  • Semver + breaking-change gate  │
                  │  • Pact contract test broker      │
                  │  • Search/discovery API + UI      │
                  │  • Public mirror (signed JSON)    │
                  └──────────────────────────────────┘

       Federation primitive (cross-country):
                                ▲
                                │ cross-signed CA roots,
                                │ bilateral trust manifest,
                                │ OCSP+log mutual mirroring
                                ▼
                  ┌──────────────────────────────────┐
                  │   PEER MESH (e.g. South Africa)   │
                  │   — same five planes, sovereign — │
                  └──────────────────────────────────┘

#12. The five planes — brief

The MVP ships with all five planes implemented in production-grade Python, with a single configuration surface for swapping in country- specific real services (national CA root, real USSD aggregator, real mobile-money provider, real wallet). Substitution is by configuration, never by code change.

#13. The federation primitive — brief

The federation primitive is the single most important architectural choice in the Mesh. Most of its design budget goes here.

Mechanism. Two Meshes A and B publish their root CA certificates. Their respective root CAs cross-sign each other, producing two cross- certificates. Each Mesh adds the other’s cross-cert to its own trust store. The result: a member of A presenting a leaf cert chained to A’s root is trusted by a sidecar in B, because the validation walks A’s leaf → A’s root → B’s cross-signature → B’s local trust anchor.

Trust manifest. Cross-signing alone is not enough — it grants raw PKI trust without policy. Each cross-signing is paired with a trust manifest — a signed JSON document that declares which services may be called across the federation, at what rate, with what audit obligations, with what data classifications, and for how long. The manifest is published in both Meshes’ Trust Planes and is checked by every sidecar at request time.

Revocation. Either side can revoke the cross-signing unilaterally. The revocation is signed, propagated to both transparency logs, and takes effect at the sidecar layer at the next manifest refresh (typically 5 minutes).

Audit symmetry. Every cross-mesh request produces audit entries in both Meshes, with mutual hash chaining: each Mesh’s audit entry references the other’s. A third party auditing one Mesh can verify the other’s claim of the exchange.

Why this is novel. X-Road’s federation requires all participants to be members of NIIS, which carries institutional and legal weight. The Mesh’s federation is purely technical and bilateral; there is no institution to join. Two countries that wish to federate need only a bilateral data-sharing agreement — which they would need anyway.

The federation primitive is the only part of the Mesh that is, in itself, a contribution beyond X-Road’s design heritage. Everything else is X-Road’s ideas, modernised. This one is new.

#14. Project governance & licence trajectory

The OpenGov Mesh is governed by the UNCTAD eRegistrations team during the pre-pilot and pilot phases. The governance is intentionally narrow and centralised in this period, because the project’s primary risk is not under-adoption but premature divergence into incompatible country forks.

The governance widens through three phases.

#Phase 1 — Pre-pilot (current)

• UNCTAD owns the spec, the implementation, and the trademark.
• The licence is restricted (LICENSE.md).
• Contributions accepted from authorised pilot partners under CLA.
• Decisions taken by UNCTAD eRegistrations team, in consultation with any active pilot sponsor.

#Phase 2 — First pilot stable (target: MVP + 12 months)

• The first national pilot has reached G3 and operates without UNCTAD direct intervention for at least six months.
• The certification & training programme is established at UNCTAD, capable of certifying integrators, country deployments, and individual operators.
• Re-licensing event: from UNCTAD pre-pilot licence to AGPLv3. Trademark retained by UNCTAD.
• Governance structure published: a technical steering committee (3–5 seats, UNCTAD-chaired, with rotating seats from pilot countries and the OpenGov community) takes the technical decisions. UNCTAD retains a documented veto on changes that would compromise inter-country compatibility.

#Phase 3 — Multi-country production

• More than three countries operate the Mesh in production, with at least two federated bilateral pairs.
• The technical steering committee is expanded.
• The trademark is retained by UNCTAD; certification continues to be operated by UNCTAD.
• A neutral foundation (e.g. an existing OSS foundation, or a new UN-system arrangement) is evaluated as the long-term steward. Any transfer of governance to such a foundation requires unanimous consent of the technical steering committee and a minimum public consultation of six months.

The trajectory is published here so a sponsor government investing in a pilot today knows the long-term destination of the asset they are helping to build. The trajectory is committed; deviations require public announcement with at least six months notice.

The AGPLv3 + certification programme combination is intentional. AGPL ensures that any commercial integrator who embeds the Mesh in a paid offering must contribute improvements back to the public good. The certification programme ensures that country deployments and integrators meet a minimum operational standard, protecting the reputation of the Mesh from being damaged by under-resourced deployments. Apache 2.0 was considered and rejected for this reason: it would have permitted commercial integrators to embed the Mesh without contributing back, which conflicts with UNCTAD’s mandate to operate international public goods.

#Detailed Specification — Parts III–VIII

The detailed technical specification is split across separate files in the parts/ directory. Each part is independently readable and can be implemented from its own contents plus this front matter for shared conventions and context.

Each Part declares its own Spec version header that bumps independently of this document’s Document version — Parts evolve at different cadences as their normative content changes. The current SPEC.md version (the front-matter “Document version” above) reflects the most recent change to this overview document itself, not the highest-numbered Part version. To find the Part versions in effect, read each Part’s front matter directly. Numbered cross-references between parts use the form [§N.M](parts/part-x-...md#nm-...) where §N.M is the global section number.