A practical path from architecture to deployment. Each step produces a concrete delivery output — a validated user journey, a governance decision, a workflow definition, or a configuration artifact. The sequence mirrors how public services are actually delivered: from a clearly defined user need, through governance and system design, to deployment, measurement, and iterative improvement.
Before applying this playbook, governments should ensure a minimum set of institutional and operational conditions are in place. These are not prerequisites for full-scale deployment, but they are necessary to run a credible, governed, and accountable implementation.
A ministry or agency responsible for the end-to-end service, including outcomes, user experience, and AI-assisted decisions.
Authority to operate the service, including data use, decision-making authority, and compliance requirements.
Including auditability, escalation paths, and grievance redress processes.
Spanning policy, legal, operational, and technical roles — not just engineers.
Such as digital identity, data exchange, or a sector registry. The service is designed to reuse existing infrastructure, not operate in isolation.
Each step corresponds to a concrete delivery output — such as a validated user journey, a governance decision, a workflow definition, or a configuration artifact. The steps are intentionally ordered: later steps rely on decisions and artifacts produced earlier. Skipping steps typically results in weak governance, fragile automation, or unclear accountability. In the absence of clear ownership and accountability, AI-enabled services risk becoming technically functional but institutionally ungovernable.
The DPI-AI Framework is implementation-agnostic. What matters is that workflows are governed, auditable, and use open standards. Whether you write YAML by hand or build visually in OpenFn or n8n, the governance principles remain the same.
Define workflows as YAML or JSON. Run on any workflow engine (OpenFn, n8n, Prefect). Full control over every step, condition, and governance parameter.
Visual workflow builder. OpenFn for DPI-native workflows, n8n for broader integrations. Drag-and-drop steps, built-in connectors to DPGs, visual governance configuration.
Define your workflow as a YAML specification. This is the source of truth — it declares the steps, the AI Blocks invoked, the governance rules, and the audit configuration. Any compliant workflow engine can run it.
Deploy to any workflow engine that can parse this spec. Recommended open-source engines:
For teams without deep engineering capacity, or for rapid pilots, visual workflow builders let you compose DPI Workflows without writing code. Both OpenFn and n8n can implement the DPI-AI Framework patterns.
OpenFn is a Digital Public Good designed specifically for social sector data integration and workflow automation. It has pre-built "adaptors" (connectors) to leading DPGs: OpenCRVS, DHIS2, Mojaloop, Kobo Toolbox, CommCare, Salesforce, and more.
Why it fits the DPI-AI Framework: OpenFn workflows can be version-controlled as code (OpenFn v2 uses a portable workflow spec), run human-in-the-loop steps, integrate with identity and payments DPGs, and log every interaction for audit. You can also call AI Blocks via HTTP adaptors.
n8n is an open-source workflow automation tool that can be self-hosted on government infrastructure. With 400+ built-in nodes and an HTTP request node for custom integrations, it can connect to any AI Block via REST API and orchestrate complex multi-step workflows visually.
Why it fits the DPI-AI Framework: n8n supports conditional branching (low-confidence → human review), webhook triggers (citizen-initiated), error handling, and logging. Workflows can be exported as JSON for version control and sharing.
A Public Agent is a constrained AI-enabled interface — not an autonomous AI system. It can only activate approved workflows, must always offer human escalation, and cannot access data without consent. Here is how to design, configure, and govern one.
Before writing any code, define in plain language what the agent CAN and CANNOT do. This becomes the governance specification.
public_agent:
name: kilimo-bot
version: "1.0.0"
owner: ministry_of_agriculture
legal_basis: "Agricultural Support Act 2025, §12"
channels:
primary: whatsapp_business
fallback: [ussd, sms]
languages: [sw-KE, sw-TZ, en]
scope:
can_activate:
- agri_benefit_eligibility_workflow
- farmer_registration_workflow
- support_inquiry_workflow
cannot_activate:
- payment_reversal
- registry_write_direct
- any_workflow_not_listed
constraints:
data_access: consent_required_per_session
human_escalation: always_available
escalation_channels: [human_agent_chat, phone_0800724666]
max_session_turns: 12
pii_in_logs: redacted
audit_log: required
governance:
confidence_threshold: 0.82
below_threshold: escalate_to_human
response_language: match_user_language
fallback_message: "I'm not able to help with that. Call 0800 724 666."
Design for the lowest-connectivity citizen first. Build WhatsApp → USSD → SMS as your fallback stack.
Supports voice messages (critical for low-literacy users), images, and text. Use WhatsApp Business API with a verified government number. Required: Meta verification, local telecom agreement.
Works on any phone with no internet. Session-based (≤182 chars per screen). Design menus first, not conversation flows. Works offline, real-time. Required: USSD short code from telecoms regulator.
Use for notifications only — confirmation, case ID, payment alert. Not suitable for multi-turn conversation. Keep under 160 chars. Use shortcodes for replies.
translate() AI Block to convert all inputs to your processing language and outputs back to the citizen's language.
Model selection is a governance decision, not just a technical one. Every AI Block — including those powering your Public Agent — must declare the model it uses, where it runs, and under what conditions it can be replaced.
Fastest to deploy. Frontier capability for complex language and reasoning tasks. Data leaves your infrastructure — unsuitable for PII-heavy tasks without data processing agreements and legal basis.
Data stays on your infrastructure. Full sovereignty. Requires GPU servers (A100 or equivalent) for 70B+ models. Smaller 8B models run on consumer GPUs.
Run on a single CPU server or Raspberry Pi. Ideal for single-purpose tasks: classification, entity extraction, intent detection. Cheap, fast, governable. Best choice for low-resource deployments.
Start from an open base model and fine-tune on local dialect data, government forms, and domain-specific terminology. Highest accuracy for local contexts but requires labelled data and ML expertise.
provenance:
model: "qwen2.5-3b-instruct" # Declare the specific model and version
model_version: "3B-q4_K_M"
hosting: on_prem # sovereign_cloud | on_prem | external_api
infrastructure: "Ministry data centre, Nairobi"
replaceable: true # Can swap without rebuilding workflow
replaceability_conditions:
- "performance_below_threshold: accuracy < 0.88"
- "model_deprecated_by_vendor"
- "sovereignty_policy_change"
last_evaluated: "2026-03-01"
evaluation_dataset: "agri-sw-KE-test-v2"
Safeguards are not optional features to add later. They are structural components of the DPI Workflow, designed to prevent silent AI failures from reaching citizens. Every one of these must be in place before citizen contact.
Every AI Block must declare a minimum confidence score. Below the threshold, the system automatically escalates to a human — never delivers a low-confidence answer silently to a citizen.
confidence_threshold: 0.85
below_threshold_action: human_escalate
Escalation is not a fallback — it is a primary workflow step. Every agent interaction must have a defined escalation path with a case ID so the citizen can follow up. Never a dead end.
escalation_path: human_agent
case_id: auto_generated
timeout_before_escalate: 90s
Consent is not a checkbox in a form — it is a step in the workflow. Check it before any data access. Make it explicit, specific to purpose, and revocable.
consent.verify(citizen_id, purpose)
# blocks workflow if consent not given
Every AI inference, input hash, output, confidence score, and human decision must be logged. Logs must be immutable, time-stamped, and accessible for algorithmic audits.
audit.log(session_id, action,
confidence, outcome, actor)
Strip personally identifiable data from all logs at the point of capture — not in post-processing. ID numbers, names, and contact details must never appear in plain text in logs.
pii_handling: redact_from_logs
log_citizen_id: hashed_only
Any model in any AI Block must be replaceable without rebuilding the workflow. Declare this explicitly and test it. Digital sovereignty depends on it — vendor lock-in starts here.
replaceable: true
hosting: on_prem | sovereign_cloud
AI operates inside the DPI Workflow — not outside it. The workflow is the single source of truth. No AI output modifies a government record, triggers a payment, or affects a citizen's status without passing through the workflow's governance rules. The agent is the face. The workflow is the authority.
These test criteria correspond to the governance controls defined in Steps 3 and 6 of the roadmap. Every item maps to a governance specification that should already exist before deployment.
The Implementation Sandbox lets you apply these 9 steps interactively — design your service with the built-in tools, walk step-by-step through the implementation journey, and watch a complete working demonstration of the framework before writing a single line of code.
Build your DPI Workflow visually with the AI Block Composer, or walk through all 9 steps with the Service Architect wizard.
Walk through each of the 9 implementation steps in detail — what each step involves, the key decisions to make, and the governance requirements at every stage.
Watch a full end-to-end service delivery — AI Blocks, DPI systems, human approval, and payment — step by step on a simulated WhatsApp interface.