What the platform is

The Pamodzi e-Services framework (also called the GSB e-Services platform) is how the Government of the Republic of Zambia delivers public e-services. A citizen, a business or a civic organisation finds a service, applies, pays and receives the result through one national portal. The ministry, department or agency (MDA) that owns the service designs it and processes applications in its back office.

This lesson gives you the big picture: who uses the platform, what it is made of, and the principles that shape every decision about it.

One product for every MDA

The platform is one reusable product. The same code is deployed for every MDA. When a new MDA joins, or an MDA adds a service, nobody writes a new application: they configure the platform.

That has consequences you will meet throughout this course:

• Core code is MDA-neutral. Core code, core data, core screens and core wording never name a specific ministry.

  A check (npm run check:mda) fails the build when they do.

• Ministry-specific functions are modules. A function only one MDA needs, such as government rentals or forestry

  licensing, lives in an optional module that can be switched on for that MDA.

• Services are configuration. A service is a form, a process, fees, required documents and output templates,

  designed in the back office.

The scale today

The master test report of 21 October 2026 covers 421 live services from 45 MDAs, migrated from the legacy GSB platform. On that date all 421 passed five checks on the test installation:

Check	What "complete" means
Form	The full application form, with every field converted
Workflow	The process converted step for step, with the same roles and decisions
Outputs	The certificate, licence or letter with every printed field filled
End-to-end test	An automated journey exists for the service and passed on its last run
Documentation	Generated documentation with numbered screenshots of every step

The legacy portal listed 572 entries, because each council service appeared once per council. On this platform each council service exists once and the citizen chooses the council. Two legacy entries were events that had ended.

The five checks show that the migration is complete. They do not replace each MDA's own sign-off: each MDA still checks its services' fees, steps and documents against its regulations.

Who uses it

User	Where they work	Typical tasks
Citizen or business	National public portal (ZamPortal)	Find a service, apply, upload documents, pay, follow progress, download a licence
Case officer, supervisor, executive	Back office	Review applications, inspect, decide, issue documents
Finance officer	Back office, POS app	Counter payments, reconciliation, refunds
Service designer	Back office	Design forms, processes, fees and templates
Administrator	Back office	Users and roles, modules, settings, federation
Data Protection Officer	Back office	Data subject requests, data-sharing approvals, open data decisions
Developer or partner system	Partner API, federation	Integrate, read registers under agreement, verify documents
Anyone	Portal verification page	Check that a document is genuine and valid

The components

Component	Repository	In one sentence
National public portal	public-portal-ui	The single citizen-facing website for every service of every MDA
Back office	back-office-ui	The staff application for casework, design and administration
Platform API	zcm-backend	Node.js and PostgreSQL; holds the rules, the workflow engine and the policy decision point
POS app	GSB-POS	An Android app for counter and field work
Identity	ZamPass, moving to Pamodzi Pass	National single sign-on with OpenID Connect
Payments	ZamPay	The government payment gateway: invoices, online payment, receipts
National Data Registers	inside zcm-backend	Reference data with field-level sensitivity and controlled sharing
NGDR	through a geo provider adapter	The National Geospatial Data Repository, for maps, parcels and areas
End-to-end kit	e2e	Automated tests and generated documentation for every service
Developer Hub	Pamodzi-HUB	Guides, API reference, service evidence, training and access requests

Pamodzi Pass is being built to replace ZamPass. Its core is written; the bridge from ZamPass and the switch-over of the e-Services platform are still planned. Until then, citizens and staff sign in with ZamPass.

Seven principles

1. One national portal. There is exactly one public portal. It reads as one government portal, not a set of

   ministry sites. It has no ministry-specific pages, menus or wording; service-specific content comes from data.

2. Services are configuration, not code. Code is written only when a genuinely new capability is missing, and then

   it is built so every MDA can use it.

3. The core stays generic; ministry features are modules.
4. Federation. An MDA may run its own back office, API and database (a node). The national portal (the hub)

   relays to it. Data stays with its owner.

5. Security first. Every request is authorised on the server. Personal data is handled under the Data Protection

   Act No. 3 of 2021.

6. Evidence, not claims. Every service has an end-to-end test, and the same run generates its documentation.
7. Built to scale and to include. Pages work at 375 px width on a slow mobile connection, are keyboard-accessible,

   and use plain English with translations into Nyanja, Bemba and Tonga.

Example: one service, end to end

Take a fictional "Example Trading Permit" owned by an MDA:

1. The MDA's service designer builds the form, the process (review, inspection, approval, payment, issue), the fee and

   the permit template in the back office.

2. The service appears on the national portal from the catalogue, with its service passport.
3. A citizen signs in, applies, uploads documents and pays through ZamPay.
4. Officers process the case step by step in the back office and approve it.
5. The platform issues a sealed permit with a QR code. The citizen downloads it from "My licences / permits".
6. A bank officer scans the QR code and the verification page confirms it is genuine and valid.
7. The end-to-end test plays all of this with synthetic data and writes the service's documentation.

The next lessons look at each part in turn.

Check your understanding

• Why does the platform keep core code free of ministry names?
• What are the five checks every migrated service passed, and what do they not replace?
• Which component would a partner system use, and which would a citizen use?
• What is the difference between a hub and a node, in one sentence each?
• Which identity provider do citizens use today, and what is planned?