UNITYZM TECHNOLOGIES · LUSAKA
The ledger stays.
The compute can travel.
UnityZM is a sovereign economic platform for Zambia — identity, payments, settlement, tax, commerce and logistics on a single runtime. It is live and serving tenants today.
The mission is to soften and harmonise the Zambian and wider African economy — removing the shocks and friction between the people who make, move, sell and settle. That is a decade of work, not a product launch.
This is what it is, how it is built, and precisely which workloads we would place on Oracle Cloud Infrastructure.
01 · PRIMITIVES
An economy's vocabulary is finite. Build it once.
Most platforms grow as a portfolio — a payments product, then invoicing, then logistics, each with its own data model and its own auth. Integration then becomes a tax paid forever.
UnityZM made the opposite decision at the start. Every capability is a Primitive: a standalone, supervised service implementing one economic function behind one shared interface. Payments is a primitive. So is tax. So is a delivery, a warehouse shelf, and a clinic appointment slot.
Because they share an interface, any primitive can talk to any other without knowing where it runs — same machine, same city, or a lean node at a border post.
THE CONTRACT
Four functions, no exceptions: primitive_type/0 for identity,
primitive_layer/0 for its position in the trust hierarchy,
issue_token/1 to sign proof it acted, and
validate_envelope/1 to check every inbound message at the boundary.
TWO CONSEQUENCES
Trust is structural, not procedural. A primitive cannot accept work it is not entitled to, because validation runs before any domain logic does.
Every state transition is signed. The audit trail is not a log written afterwards — it is the accumulated signatures of every primitive that touched the transaction.
THE CATALOGUE — 62 IMPLEMENTED TYPES
A haulage business, a certification authority and a district clinic are the same platform wearing different configuration — not three products.
TRUST IS TIERED, AND AUTHORITY ONLY FLOWS DOWN
| LAYER | DESIGNATION | HOLDS |
|---|---|---|
| 0 | Root authority | Sovereign · central bank · tax authority · regulator · registry |
| 2–4 | Identity & trust | Digital ID providers, compliance validators |
| 10–11 | Network services | Settlement routing, finance gateways, comms |
| 12 | Finality | Settlement engine, forensic ledgers |
A commerce primitive cannot mint currency, because there is no path by which it could ask.
02 · HOW IT LAYERS
The commercial stack and the technical stack are the same stack.
UnityZM sells at four altitudes. Each is a different buyer and a different contract — but all four are served by one running platform.
| TIER | WHAT IS BOUGHT | WHO BUYS | MAPS TO |
|---|---|---|---|
| 1 · Network | Access to the settlement, identity and tax rails | Banks, mobile-money operators, authorities | Network + trust layers |
| 2 · Platform | A configured cockpit — orders, dispatch, stock, settlement | Enterprises and operators | Experience + domain layers |
| 3 · Edition | A licensed, deployable instance for their own estate | Institutions, partners, other markets | Substrate — same image, different estate |
| 4 · API | Metered calls into settlement, KYC, balance, webhooks | Developers and integrators | Domain layer, exposed and metered |
These are layers rather than a menu because tier 2 customers become tier 1 volume. An operator running dispatch on the cockpit settles through the network by default. That is not cross-selling; it is architecture.
A new commercial tier is not a new build. Tier 3 exists because of one environment variable and a signed partition licence.
The same mechanism that lets us run a lean node at a border post lets us license a whole edition to an institution. The commercial model is downstream of the deployment model — which is why three consequences follow that shape what we need from a cloud partner.
LAYERS SEPARATE AT THE SUBSTRATE
Data and trust carry the residency constraints. Experience, build and AI carry none. That boundary is enforced by the architecture, not by a policy we wrote — which is why hybrid is genuinely available to us rather than aspirational.
LOAD IS NOT EVEN ACROSS LAYERS
Data and trust are steady and modest. Experience and AI are spiky and occasionally enormous. One machine large enough for the second means overpaying permanently for the first.
TIER 3 MULTIPLIES ESTATES
Every licensed edition is another cluster to build, test and support — from the same team. This is exactly where an elastic build fleet stops being a nice-to-have.
03 · WHY ELIXIR / ERLANG / PHOENIX
In this market, the runtime choice is a pricing decision.
Erlang was built to run telephone switches that could not go down, on expensive hardware, maintained by small teams. That is our problem statement almost word for word.
ONE MODEST NODE, HIGH CONCURRENCY
The BEAM schedules millions of lightweight processes pre-emptively across cores. In practice the whole platform serves live tenants from a modest VPS, and edge nodes are 4–8 GB ARM64 boxes. That is the difference between a viable Zambian price point and an unviable one.
PARTIAL FAILURE, NOT OUTAGE
Every primitive runs under a supervisor. A crash in invoicing restarts invoicing — it does not touch settlement. A node's blast radius is fixed at boot by its assigned role.
DISTRIBUTION IS IN THE RUNTIME
Location transparency is native; Horde adds a CRDT-backed registry for cluster-wide discovery. We never had to buy or build a service mesh — for a self-funded company, that is a whole category of cost never incurred.
LOCAL SURVIVABILITY
A worker node partitioned from the master keeps operating on local authority and reconciles on reconnect. Where links to a border post are genuinely intermittent, that is not exotic — it is Tuesday.
WHAT WE GIVE UP — BEFORE YOU ASK
| TRADE-OFF | HOW WE HANDLE IT |
|---|---|
| Small talent pool | We hire for fundamentals and train Elixir. It also acts as a filter, and OTP's constraints make junior code safer than the same engineer's Node or Python would be |
| Wrong language for numeric / ML compute | We do not pretend otherwise. This is precisely why AI inference is a cloud workload for us and not a BEAM workload |
| Fewer vendor SDKs | Most SDKs are thin HTTP wrappers; we implement against the API. It does mean we would call OCI over plain REST, with no Oracle SDK for our runtime |
THE STACK
| CONCERN | CHOICE | WHY THIS ONE |
|---|---|---|
| Runtime | Elixir 1.20 / OTP 27 | Concurrency, supervision, native distribution |
| Web & UI | Phoenix + LiveView | Server-rendered real-time; one codebase, no separate frontend team; diffs over a socket suit thin pipes |
| Distributed registry | Horde | CRDT process registry — location transparency across nodes |
| Background work | Oban | Durable Postgres-backed queue; survives restarts |
| System of record | PostgreSQL | Transactional core; also backs the job queue |
| Ephemeral & pub/sub | Redis | Cache, ephemeral state, cross-node signalling |
| Edge & offline | SQLite | Lean nodes where a full server is unwarranted |
| Packaging | Docker | Identical artefact on VPS, on-prem or any cloud — no proprietary service dependency |
Portability is a design property, not a migration project. We can place a workload on OCI because nothing in our stack is welded to where it currently runs.
04 · THE MESH
One platform, many nodes — across ten provinces.
All three tiers run the identical release artefact. A lean node is not a cut-down product — it is the same platform with a narrowed supervision tree and a signed licence saying which role it may be.
ONE ORDER, THREE PROVINCES
A wholesaler in Chipata orders stock from a supplier in Ndola, moved by a haulier registered in Lusaka.
| # | WHERE | WHAT HAPPENS | PRIMITIVES |
|---|---|---|---|
| 1 | Chipata | Buyer places the order | order · catalogue · pricing |
| 2 | Chipata → Lusaka | Identity and KYC tier resolved; trust level gates the value | identity · compliance |
| 3 | Lusaka core | Funds locked in escrow — held, not paid | escrow · account · ledger |
| 4 | Ndola | Supplier sees a funded order, picks and confirms stock | inventory · fulfilment |
| 5 | Lusaka | Carrier matched, priced, dispatched | logistics · capacity |
| 6 | On the road | Position pings, corridor to corridor | location · zone |
| 7 | Chipata | Delivery confirmed with proof at the edge node | fulfilment · document |
| 8 | Lusaka core | Escrow releases, commission taken, tax computed and filed, ledger hash-chained | settlement · tax_authority · audit |
One transaction, three provinces, four parties, one traceable record — and the tax event is produced by the transaction that moved the goods, not reconstructed from paperwork a month later.
NOW BREAK THE NETWORK
At step 7, the link between Chipata and Lusaka drops. The Chipata node keeps working: it captures proof of delivery against local storage, signs it with its node identity, and queues it. The driver is not blocked. On reconnect the envelope replays, escrow releases, settlement completes.
What is not permitted: Chipata cannot declare finality alone. Settlement lives at trust layer 12 and stays in Lusaka.
The edge can always capture truth. Only the core can declare it final.
05 · ORDER TO DELIVERY
We don't take over a business. We close the gaps between its steps.
The classic enterprise play arrives with a system of record and asks the business to reorganise around it. In this market that is dead on arrival — and rightly so. The capital lands before the benefit, and it discards how the operator actually works.
The business is usually not broken. The seams are.
Walk a real order today: the customer orders on WhatsApp. Stock is checked on a spreadsheet, or by walking to the shelf. Payment goes to a personal mobile-money number. Dispatch is a phone call. Delivery is a photo of a signed paper note. The invoice is retyped. Tax is reconstructed at month-end from paperwork.
Every individual step works. The losses are entirely in the handoffs — and no single-purpose product fixes a handoff, because a handoff belongs to neither system on either side of it.
EVERY ECONOMIC SERVICE HAS THE SAME SHAPE
| STAGE | HAULAGE | SEED CERTIFICATION | CLINIC |
|---|---|---|---|
| Discover | Available capacity | Certified lots | Available services |
| Verify | Licence, KYC tier | Grower registration | Patient identity |
| Commit | Funds held in escrow | Fee held | Cover confirmed |
| Allocate | Truck + driver | Inspector + window | Clinician + slot |
| Prove | Proof of delivery | Certificate + lot event | Record of care |
| Account | Invoice filed, hash-chained | Regulator sees the lot | Audit trail |
Same stages, same primitives, different configuration. This is why unrelated industries do not require forking the product.
A CLIENT IS CONFIG, NOT CODE
There is not a single client's name anywhere in the codebase — not a table, a route, a module, or a CSS class. A client is a descriptor: a database record plus their ingested data. Generic code renders it.
Onboarding the next operator in the same line of business is a config change and a data import — zero lines of code.
WE MEET THE RAILS THAT EXIST
Bridges to what the market already uses: MTN MoMo, Airtel Money, Zamtel, banks, card networks, ZRA Smart Invoice, USSD.
We are not asking anyone to abandon mobile money. We are asking that the payment land against the order instead of in a spreadsheet.
START AT ONE GAP
An operator adopts the gap that hurts most — usually dispatch visibility or reconciliation. The spine fills in behind it as trust builds. No big-bang migration, no stop-the-business cutover.
WHAT WE ARE NOT
Not an ERP — no company-wide HR, CRM or group accounting, and we say so in writing to prospects. Not a payment processor. Not a replacement for the operator's judgement. Being explicit about the boundary is what makes the rest believable.
06 · THE MISSION
Soften and harmonise.
To reduce the shocks and the friction between the people who make, move, sell and settle — so that participating in the formal economy stops being a cost and starts being an advantage.
Two verbs carry the whole thing, and they are chosen carefully.
SOFTEN — REMOVE THE HARD EDGES
An economy that runs mostly on cash has sharp edges, and people fall off them daily. Softening means replacing each cliff with a gradient — and this is not aspiration, it is what the mechanisms already do:
| THE HARD EDGE | THE GRADIENT WE PUT IN ITS PLACE |
|---|---|
| Trust is binary — pay first or ship first | Escrow. Funds held, visible to both sides, released on proof. Strangers can trade |
| Identity is all-or-nothing | Trust tiers 0–10. Enter at the tier you can evidence and climb as you trade. Nobody is turned away at the door |
| Systems are online-or-dead | Offline-first edge nodes. Poor connectivity degrades the platform; it does not stop the business |
| Tax is reconstructed at month-end | The invoice files itself as the goods move. No shock, no penalty, no reason to stay informal |
| No transaction history exists | History accrues by trading. The precondition for credit that most Zambian businesses cannot access today |
HARMONISE — MAKE THE PARTS AGREE
Today the parts do not speak to each other. Mobile-money operators interoperate poorly, banks are separate estates, the tax authority reconstructs after the fact, the regulator sees things late, and cross-border is paperwork at a barrier.
Harmonising means the same participants settling on the same network under the same identity — so agreement is structural instead of reconciled. One network. One identity. One double-entry ledger that physically refuses a movement that does not balance. Tax and audit as products of the transaction rather than archaeology performed on it later.
Zambia borders eight countries, and our corridors already end at other economies. The same primitives that harmonise a domestic corridor harmonise a regional one. That is the ten-year shape of this: the same platform, more borders.
NOT JUST SERVICES — RESEARCH AND DATA
Zambia's economy has never been measured at transaction granularity. Policy is made on surveys, estimates and lagging indicators. Meanwhile a platform carrying orders, deliveries, invoices, settlements and corridor movements holds the most accurate picture of real economic activity anyone has had of this economy.
WHAT IT COULD ANSWER
Corridor throughput and where freight actually slows. Price formation by district over time. Informal-sector activity made visible without being made punishable. Seasonal and agricultural flows at a granularity that helps a planner. Credit signal for businesses with years of honest trading and no bank history.
THREE COMMITMENTS, STATED FIRST
Consent and anonymisation are prerequisites, not later features. The data stays sovereign — it is Zambian economic data and does not become someone else's asset. And research is not a monetisation strategy in disguise: the moment it is, the trust that makes the data accurate disappears.
This is why the AI and GPU conversation is a mission conversation rather than a feature conversation. Research at this granularity is embeddings, clustering, time-series and inference over a growing corpus — precisely the workload our runtime is wrong for and elastic cloud is right for. Without capacity we do not currently have, it does not happen at all.
WIDEN WITHOUT DISTURBING DAILY LIFE
The failure mode for national infrastructure is well documented: a mandated cutover, a system that does not work on day one, and an economy that pays for the transition in lost trade. We have designed explicitly against it.
A national rail must never make somebody's Tuesday worse.
| HOW WE WIDEN | WHY IT DOES NOT DISTURB |
|---|---|
| Adopt one gap first | The operator keeps their whole existing process; we close the seam that hurts most |
| Cash keeps working | We are additive to cash, not a replacement. Nobody is forced digital |
| Existing rails stay | Bridges to the operators, banks and the tax authority. We ask no one to abandon what they use |
| Config, not code | A new tenant or region is a descriptor and a data import — no redeployment that could break someone live |
| Kill-switch and maintenance windows | When something must go down it is scoped, scheduled and announced — never a surprise |
| Backward compatibility as an invariant | A feature reaches a tenant only when their descriptor opts in |
Growth is quiet by construction. We widen by being adopted — one gap and one operator at a time — not by being mandated.
07 · WHY OCI
Three needs: early adoption, usage capacity, AI acceleration.
EARLY ADOPTION
The platform is built. The constraint is no longer engineering — it is capacity bought ahead of revenue.
Onboarding an operator means a configured estate, seeded data, a UAT environment and a parallel-run period: weeks of infrastructure consumed before the first invoice. Self-funded, that cost is the actual throttle on how fast we can say yes. Not demand. Not engineering. And every tier-3 licence multiplies estates to build, test and support from one team.
USAGE CAPACITY
Our load is not shaped like our steady state.
| PEAK | TRIGGER | SHAPE |
|---|---|---|
| Settlement runs | Month-end netting and reconciliation | Hours, heavy, predictable |
| Tax filing | ZRA deadlines | Days — everyone at once |
| Seasonal | Harvest and certification windows | Weeks |
| Build & test | Every release, every new edition | Bursty, embarrassingly parallel |
The BEAM handles concurrency well on modest hardware, which is exactly why buying permanently for the peak is such poor economics for us. We would be paying for 40× headroom that sits idle most of the month.
There is a second capacity argument, and we should raise it before you do: a single Lusaka cluster is a concentration risk. A warm standby is the cheapest credible DR available to us — encrypted, with keys held sovereign, and with certain tenants excluded from replication entirely rather than fudged.
AI ACCELERATION
Our AI posture today is deliberately frugal: all traffic passes through an internal provider-agnostic router; an intent router answers routine requests on fast deterministic paths and escalates to a model only when genuinely required; usage is metered token → credit → kwacha with double-entry ledger integration, so cost is attributable per tenant and an agent's wallet refuses to overspend before the model can.
That design cuts spend at source. What it cannot do is these five things — all of which need real compute:
1 · TENANT-FACING INFERENCE AT VOLUME
With predictable latency as tenant count grows. The current path is not a production-grade answer at scale.
2 · PII-BOUND INFERENCE
Some tenant data cannot leave the sovereign boundary — which means self-hosted small models on GPU in a defined, contractually bounded location.
3 · EMBEDDINGS AT CORPUS SCALE
For knowledge-graph and search across tenant document estates.
4 · DOCUMENT EXTRACTION
Invoices, delivery notes and customs paperwork photographed at a border post on a poor connection.
5 · LANGUAGE ADAPTATION
Small-model adaptation to Zambian language and idiom, so the platform speaks the way its users actually speak. Occasional GPU-heavy work, not continuous.
08 · WHAT RUNS WHERE
State stays. Compute travels.
SOVEREIGN — ALWAYS
- System of record — identity, wallets, ledgers
- Settlement finality (trust layer 12)
- Layer-0 authorities — tax, central bank, regulator interfaces
- Identity, KYC and PII — encrypted at the domain boundary
- Live tenant cockpits — latency to Zambian users
- Edge and lean nodes — offline-first at the tenant
CANDIDATES FOR OCI
- Build and CI fleet — parallel, bursty, zero data sensitivity
- Batch settlement and reconciliation peaks
- Corridor telemetry and route computation
- AI inference — non-PII
- Embeddings and search indexing
- Model adaptation — occasional, interruption-tolerant
- Warm DR standby — encrypted, keys sovereign
WHY THIS BOUNDARY IS CREDIBLE
Every vendor hears "we'll keep the sensitive part on-prem" from every prospect. What makes ours different is that the boundary is enforced in code, not in policy:
DECLARED PER PRIMITIVE
Trust layers 0–12 are declared by primitive_layer/0 and validated at
every service boundary by validate_envelope/1.
ROLE FIXED AT BOOT
A node's role is set by UNITYZM_NODE_ROLE plus a partition licence
signed by the root CA. Role mismatch and the node refuses to start.
BOUND TO HARDWARE
Nodes carry a forensic boot lock tied to host hardware identity. A stolen disk image will not boot on unknown hardware.
A burst node cannot silently become a settlement node because someone changed an environment variable. It is not permitted to boot into that role.
09 · THE ASKS
Three questions, in the order they matter to us.
GPU options at our scale
We are not asking about H100 clusters. We are asking what the bottom of the ladder looks like, and how it climbs.
- What is the smallest credible inference footprint — a single-GPU shape, or is bare metal the entry point?
- Is fractional or time-shared GPU available, or is the smallest unit a whole card?
- Billing granularity, and minimum commitment?
- Are preemptible instances available? Our inference and adaptation work is interruption-tolerant, which should make us a good fit for cheaper capacity.
- Could we start on CPU inference with small quantised models and migrate as volume justifies it?
Connectivity between our infrastructure and OCI
Our core stays in Lusaka. The burst path has to be dependable.
- Which is the nearest region, and what round-trip latency should we plan for from Lusaka?
- Is FastConnect reachable through any carrier with Zambian presence, or only via a Johannesburg point of presence?
- If direct interconnect is impractical at our size, what site-to-site VPN posture would you recommend — and what should we realistically expect from it?
- Egress terms. Results return to the sovereign core by design, so egress is a structural line item for us, not an edge case.
- Our edge images are already ARM64 — are Ampere shapes a drop-in? If so, our build fleet moves with no rebuild.
- We call plain REST from Elixir. Can we assume everything we need is reachable without a vendor SDK?
Startup and partner programmes
Our profile does not match the template most startup programmes assume.
- What fits a self-funded, revenue-generating company rather than a VC-backed pre-revenue one?
- Typical credit levels and term — and what happens at the cliff when credits expire?
- Is there an ISV or partner track? Our licensing model means that as we grow we bring other companies' workloads onto OCI, not only our own.
- Anything specific for sovereign or national-infrastructure platforms in emerging markets?
- Would Oracle want a reference case — a hybrid sovereign-core / cloud-burst deployment in a market where the pattern is not yet established? We are willing to be documented.
10 · WHERE WE ACTUALLY ARE
The honest grading.
We publish our own assessment of how complete this is, because velocity without disclosure is marketing. The disclosure is what makes the velocity trustworthy.
A real platform, roughly 6/10 complete, with hardening waves between here and go-live. Not "40 person-years of production-grade, done". The solo-plus-AI build bought breadth and speed and deferred some hardening — that is real debt, not a free lunch.
That gap between breadth and hardening is the reason for this conversation. A meaningful part of the remaining work is literally infrastructure.
Disaster recovery. A transport mesh between nodes. Load headroom for the peaks we can already predict. GPU capacity for the five AI workloads we cannot currently attempt. These are not features we need to invent — they are capacity we need to place.
WHAT WE WOULD LIKE TO AGREE TODAY
| HORIZON | WHAT WE WOULD RUN | SHAPE |
|---|---|---|
| Now → 3 months | Build fleet, first inference footprint | Smallest viable; ARM compute, interruption-tolerant |
| 3 → 9 months | Batch burst, warm DR standby | Scheduled and predictable; DR sized for restore-time |
| 9 months + | Per-edition estates as licences land | Grows with signed contracts, not with hope |
WHAT KIND OF CUSTOMER THIS MAKES US
We are not a startup looking for a runway. We are infrastructure looking for a decade.
| MISSION PROPERTY | WHAT IT MEANS FOR A CLOUD PARTNER |
|---|---|
| Ten-year horizon, not a funding cycle | Consumption that compounds — not a spike, then churn |
| Expansion along real corridors | Every border is more estates, more compute, more settlement volume |
| Research and data as a core pillar | A structurally growing, GPU-shaped, elastic workload |
| Adoption is config-shaped | Capacity converts almost directly into onboarded tenants |
| The sovereign core is permanent | Hybrid is our end state, not a stepping stone. We will not "eventually move everything" — and we would rather say so than imply otherwise |
That last row deserves to be said plainly. Some vendors want hybrid to be a phase. For us it is the architecture, permanently. A partner comfortable with that gets a customer who grows steadily for a decade — and should know it now rather than later.
The ledger does not move. Identity, tax and settlement finality stay on infrastructure we control — that is the product, not a preference. Everything else has no residency constraint at all, and that is what we would like to place with you.
WHO IS BUILDING IT
PHILIP CHANI — CO-FOUNDER & PRINCIPAL ENGINEER
Architecture and engineering — the primitives model, the settlement network, and the node mesh. LinkedIn →
YIMBANJI M. — CO-FOUNDER
Zambian-owned and Zambian-built. The platform is developed and operated from Lusaka, on infrastructure we control. LinkedIn →