OpenGov Mesh
PILOT · SOMALIA Manifesto Spec Onboarding

First Tier-A pilot · Somalia

OpenGov Mesh for Somalia.

A federated business-registration and licensing architecture for the Federal Government and the Federal Member States — where every cross-border handoff is verified, not trusted.

Somalia already registers companies. What it lacks is a sovereign, verifiable way for the centre and the states to exchange the data between them. The Mesh is that substrate — placed beneath the Federal Ministry of Commerce & Industry and each Federal Member State, not on top of the registration form.

Not a new form. A trustworthy boundary.

The brief · in plain terms

What the Mesh does for Somalia, in 100 seconds.

1:42 · narrated explainer · the federal ↔ state exchange, explained without jargon

The thesis

The problem isn't the app. It's the monopoly beneath it.

Somalia's registration system already serves roughly nine thousand companies. The need is not a better workflow. The need is that the federal data exchange runs as a single shared, vendor-held platform — forcing every Federal Member State to trust the centre and the vendor with its licensing autonomy and its fee revenue, and making the whole country single-point-fragile.

The fix is not to replace the form. It is to put a sovereign, verifiable exchange substrate underneath the Federal MoCI ↔ FMS relationship — so each state keeps its own authority and can prove, for itself, that every exchange was legitimate.

The Federal MoCI ↔ FMS boundary is exactly the trust boundary OpenGov Mesh was built for.

Two complementary layers

The service, and the exchange.

One layer runs the registration. The other lets institutions exchange its results without anyone having to trust the centre. They are designed to be adopted independently.

Vertical · the service

  • BPA designs the name-reservation → incorporation → licensing workflow.
  • GDB holds the company registry and the per-FMS fee and activity tables.
  • DS is the trilingual applicant portal — Somali, Arabic, English.
  • Each FMS becomes a tenant-institution: its own fees, activities, licence templates, signatories and payment account — ending the "every change routes through the vendor" bottleneck.

Horizontal · the exchange

  • The five planes — Trust, Transport, Catalog, Observability, Consent.
  • The federal → state incorporation-to-licence handoff becomes a signed, consent-bounded, Merkle-anchored exchange.
  • National ID (NIRA) verification and Ministry of Finance payment confirmation each become signed exchanges.
  • The receiving party independently verifies every exchange — no implicit trust in the centre or the vendor.

The architecture

Incorporation in the centre. Licensing in the state. Verified across the gap.

A company is born once, federally, and licensed where it operates — and the handoff between the two carries its own proof.

  1. DS portaltrilingual · so / ar / en · name reservation
  2. Federal MoCIincorporation · certificate + 11-digit UBI
  3. Mesh handoffsigned · consent-bounded · Merkle-anchored · routed by State
  4. FMS licensingtenant-institution · own fees & templates

The first real exchange — the two-peer pilot — runs between the Federal MoCI node and the Jubbaland node: an incorporation certificate flowing federal → state as a signed, verifiable, store-and-forward message. Each further state onboards simply by standing up its own node. Beyond registration, identity and payments join through the Mesh Catalog as audited, consent-bounded exchanges: NIRA for national ID, MoF and mobile money (EVC-Plus, Salaam Bank) for payment confirmation.

  • Jubbaland ✓ onboarded
  • Hirshabelle pending
  • Galmudug pending
  • South West pending
  • Puntland pending
  • Banaadir / BRA pending

Phased path

Four phases. The pilot is phase two.

The vertical is rebuilt first so there is something real to exchange; the Mesh leg follows, federal and Jubbaland first.

  1. P0

    Assess & extract

    the Geneva mission

    Secure the full database export MoCI can authorise; confirm whether the legacy system exposes an API (this decides migrate-vs-integrate); capture per-FMS configuration — fees, activities, templates — starting from the Jubbaland sample.

    Decision gate · integration surface vs export-and-rebuild

  2. P1

    Rebuild the vertical on OpenGov

    eRegistrations

    A BPA workflow with FMS-jurisdiction routing; a GDB registry with per-FMS tables; the trilingual DS portal; each FMS configured as a tenant-institution.

    The service, sovereign and multi-tenant

  3. P2

    Mesh exchange — Federal + Jubbaland

    the two-peer pilot

    The incorporation certificate flows federal → state as a signed, verifiable, store-and-forward exchange. Each new FMS onboards by standing up its node.

    The real pilot · the trust boundary, working

  4. P3

    Institutions API via the Catalog

    identity & payments

    NIRA verification and MoF / EVC-Plus / Salaam payment confirmation become audited, consent-bounded exchanges. Then the registry itself becomes a catalogued provider that banks and tax authorities can consume.

    From one exchange to an ecosystem

Decisions for the mission

Five questions the pilot must answer.

Named plainly, because each one gates work downstream. The Mesh is honest about what is not yet resolved.

Vendor source-code lock-in
The legacy system's code is vendor-held. Resolving integration-surface vs export-and-rebuild gates everything downstream.
Identity not live
NIRA is a stored, staff-verified field today. It needs a verifiable anchor; the Mesh path is SD-JWT-VC plus USSD / SMS — but NIRA must expose something verifiable.
Payments manual
Wallet top-up today; the MoF API is built but not live. Keep the wallet as fallback and add gateway confirmation as the Mesh-mediated path — both on one audit trail.
Connectivity
Intermittent links and thin power on the FMS legs. Store-and-forward is non-negotiable — designed in from day one, not bolted on.
Node topology
Per-FMS nodes vs a central node with crypto-separation. For federal politics, lean to true per-FMS nodes for maximum sovereignty — starting Federal + Jubbaland.

What the data shows

The shape of the registry is already Mesh-ready.

The join key and the routing key both already exist in the data — and the volumes sit comfortably in the affordable-hardware tier.

  • ~8,972 / 12,332Companies / licences — comfortably Tier-A scale
  • 11-digit UBIThe company ↔ licence join key across the whole registry
  • State fieldAlready the FMS routing key — jurisdiction is in the data
  • Tier-AAffordable-hardware scale — no datacentre required

A phase-2 data request stands open: the standard export omits beneficial-ownership, capital, payment and attachment entities — needed to model the full lifecycle.

Begin

Somalia would be the first Tier-A pilot.

Start where the trust boundary already is: the Federal MoCI and one Federal Member State. The vertical first, then the signed exchange between them.

This is for the Federal Ministry of Commerce & Industry, the Federal Member State licensing authorities, and the partners funding the first two-peer leg. Bring the political mandate and the Jubbaland configuration; the Mesh brings the verifiable substrate.