Design a complete DPI-AI service in 9 guided steps — starting with government preconditions, through use case selection, journey mapping, governance, channel inclusion planning, AI Block selection, workflow generation, and Public Agent configuration to a ready-to-hand-over service specification.
1 · Preconditions
2 · Use Case
3 · Journey
4 · Governance
5 · Channels
6 · AI Blocks
7 · Workflow
8 · Agent
9 · ✓ Ready
Confirm your government is ready to proceed
Three institutional gates — ownership & mandate, team composition, and infrastructure access. Without these in place, AI-enabled services risk becoming technically functional but institutionally ungovernable. The DPI rail is required. Service-level decisions (consent flows, confidence thresholds, audit) are confirmed separately in Step 4.
Select a service to design
Filter by sector, region, and complexity, then pick a use case. You can customise the journey and AI Blocks in the next steps.
Sector
Region
Complexity
Map the citizen journey
Define the touchpoints from first contact to service delivery. These are the steps the Public Agent orchestrates — add, remove, or reorder as needed.
Governance & safeguards
Service-level governance decisions — confirmed before AI Block selection. These five items cover how this specific service will handle consent, uncertainty, escalation, data privacy, and auditability. Institutional ownership and legal mandate were confirmed in Step 1.
Tick each item your team has addressed. Unchecked items will be flagged as deployment risks in your downloaded specification.
🛡️ Safeguards are selected in the next AI Blocks step. At least one safeguard block (bias check, consent verify, human review, etc.) is recommended for every service. They are pre-selected based on your use case.
View UN Safeguards Framework ↗
Access channels — leave no one behind
Select every channel through which citizens will access this service. Design for the most excluded user first. A service that only works on a smartphone excludes the people most likely to need it.
⚠ Inclusion check: At least one low-barrier channel — USSD, SMS, or an in-person assisted option — must be available alongside any smartphone-dependent channel. Consider who in your target population lacks internet access, a smartphone, or WhatsApp.
Region-appropriate channels are pre-selected based on your earlier filter. Adjust to match your actual deployment context.
Select AI Blocks
We’ve pre-selected the AI Blocks typically used for your chosen service — review them and adjust to match your context. Add or remove blocks based on what your team has available and what the service actually needs.
🧩 Foundational — General-purpose functions (translation, speech-to-text, OCR, summarisation). Most services need at least one.
⚙️ Sector-Specific — Policy and operational logic: identity verification, eligibility checks, payments, registry lookups. Pre-filtered to your region and use case. Regional DPI systems sourced from dpimap.org ↗
🛡️ Safeguards — Governance blocks insertable at any workflow point. At least one safeguard is recommended for every service. Based on the UN DPI Safeguards Framework ↗
Your DPI Workflow specification
This is your service design output. The diagram on the left shows how the Public Agent, AI Blocks, and DPI systems connect. The specification on the right is the machine-readable definition of your service.
You don’t need to understand the code — just download or copy it and share with your implementation team. Switch between Code / Custom (portable YAML for any tech stack) and No-Code / OpenFn (ready-to-deploy for OpenFn users).
Architecture Overview
Select a use case to see the architecture diagram
Portable YAML spec for any tech stack or implementation team.
The Public Agent is the citizen-facing interface. It orchestrates the interaction — collecting intent, triggering the DPI Workflow, and delivering results. It is not a decision-maker; it is a constrained, accountable extension of government. Channels were configured in Step 5.
Languages supported
Escalation path
Agent persona (optional)
The name or persona the citizen interacts with. Cosmetic only — does not affect workflow logic.
Constraints (locked — accountable by design)
AI Model — underlying LLM powering this agent
Affects capability, cost, and data residency. For government deployments consider on-premises or regional cloud options.
✅
Service design complete
Your DPI-AI service specification is ready to hand over to your implementation team. Below is a summary of what you designed and the steps needed to go from specification to a live service.
⚠️ The YAML is a design specification — not a deployed service
Downloading this file is the end of the design phase, not the beginning of operation. Complete these steps with your implementation team before any citizen contact.
🗄️
1. Deploy your DPI rails first
Identity, payments, and data exchange must be live before the workflow can execute. The YAML assumes they exist.
🔧
2. Configure a workflow engine
Hand this YAML to your tech team. They translate it into engine-specific config using OpenFn, n8n, or Prefect.
⚖️
3. Confirm legal & accountability
Designate the legally accountable service owner, confirm the mandate, and ensure grievance redress pathways are in place.
🧪
4. Test before citizen contact
Run a full synthetic test suite — every block, every fallback, every safeguard. No citizen interaction before all tests pass.
🚀
5. Run a supervised pilot first
Start with 100–1,000 citizens under full human oversight. Measure against your defined metrics. Only scale when stable.