DPI Workflows

The Orchestration Layer

Workflows are recipes — AI Blocks are ingredients

A DPI Workflow defines the sequence, conditions, data flows, and safeguards that govern how a service is delivered. AI operates inside the workflow — never outside it. The workflow is the single source of truth for any service interaction.

The key principle: No AI output directly modifies authoritative records without passing through a governance step in the workflow. Confidence below threshold? Routes to human review. Exception detected? Escalates to caseworker. The workflow encodes accountability.

What a DPI Workflow connects

Public Agent

Receives citizen intent, initiates workflow invocation with consent token

DPI: Identity Verify

identity.verify(citizen_id) — authenticated against the national ID system

AI Block: Eligibility

ai.eligibility_verify() — returns eligible + confidence score

⚠ if confidence < 0.85 → human_escalate()

DPI: Data Exchange

data_exchange.get_social_record() — consented data pull from registry

DPI: Disburse

payments.disburse() — benefit payment via government rail

✓

Audit Log

Every step logged immutably — who, what, when, with what confidence

Why workflows are reusable assets

A workflow that chains together identity verification, eligibility determination, and payments is not only a service — it is also a sharable recipe.

Published in open repositories, such workflows can be adapted and reused by other governments, much like open-source code or containerised applications. Countries can borrow from each other's playbooks, install them with minimal effort, and adapt them to local policies.

This is how the DPI model extends to AI: not as configuration of black-box systems, but as governance-embedded code that can be inspected, audited, and evolved.

→ See how to implement workflows with OpenFn, n8n, or YAML

YAML Template

Generic DPI Workflow Template

A fully annotated YAML template for a social protection benefit disbursement workflow. Adapt the steps, blocks, and governance rules to any sector.

# Generic DPI Workflow Template — DPI-AI Framework
workflow:
  id: "benefit_disbursement_v1"
  version: "0.1.0"
  description: "Social protection benefit eligibility check and payment disbursement"
  domain: "social_protection"

  governance:
    owner_agency: "<Ministry of Social Welfare>"
    legal_basis: "<Social Protection Act § 12.3>"
    audit_logging: true
    human_oversight:
      required: true
      escalation_to: "caseworker_supervisor"
      retention_policy: "5y"
    accountability_note: "Public Agents orchestrate steps; institutional authority remains with government."

  actors:
    public_agent:
      id: "social_benefit_agent_v1"
      channels: ["whatsapp", "ussd", "voice"]
      languages: ["sw", "en", "am"]
    human_agent:
      id: "caseworker"
      role: "Benefit Caseworker"

  steps:
    - id: identity_verify
      type: dpi_block
      block: identity.verify
      inputs:
        identifier: "{{requester.identifier}}"
        consent_token: "{{requester.consent_token}}"
      on_fail: escalate_to_human
      on_success: eligibility_check

    - id: eligibility_check
      type: ai_block
      block: ai.eligibility_verify_v1
      inputs:
        citizen_id: "{{steps.identity_verify.output.verified_id}}"
        benefit_code: "{{request.benefit_code}}"
        consent_token: "{{requester.consent_token}}"
      confidence_threshold: 0.85
      on_low_confidence: human_review
      on_high_confidence: data_pull
      on_fail: escalate_to_human

    - id: human_review
      type: human_task
      assign_to: caseworker
      timeout: "48h"
      inputs:
        case_data: "{{steps.eligibility_check.output}}"
      on_approve: data_pull
      on_reject: notify_rejection

    - id: data_pull
      type: dpi_block
      block: data_exchange.get_social_record
      inputs:
        citizen_id: "{{steps.identity_verify.output.verified_id}}"
        consent_token: "{{requester.consent_token}}"
        purpose: "benefit_disbursement"

    - id: disburse
      type: dpi_block
      block: payments.disburse
      condition: "{{steps.eligibility_check.output.eligible == true}}"
      inputs:
        recipient_id: "{{steps.identity_verify.output.verified_id}}"
        amount: "{{benefit.amount}}"
        payment_ref: "{{workflow.id}}-{{run.id}}"

    - id: notify
      type: action
      channel: "{{requester.preferred_channel}}"
      message_template: "benefit_disbursement_confirmation"

  audit:
    log_all_steps: true
    pii_redaction: true
    immutable: true

Implementation Formats

Three ways to express a DPI Workflow

A workflow is a design decision — not a file format. The same service logic can be expressed as a portable YAML specification, deployed into a no-code engine, or packaged as a callable skill for an AI agent. Teams choose the format that matches their technical capacity and agent architecture.

📄

Format 01

YAML Specification

The canonical, engine-agnostic definition. Declares steps, AI Blocks, DPI dependencies, confidence thresholds, human escalation paths, and governance settings. Readable by humans and parseable by any workflow engine or agent runtime.

workflow_id: BENEFIT_CHECK_v1
steps: [identity_verify, eligibility_check,
  human_review, disburse]

Best for: documentation, sharing across teams, feeding into any engine or agent tool

🔌

Format 02

No-Code Workflow Engine

Deploy the YAML spec into a visual workflow engine. OpenFn (DPG-native, MCP server since June 2025), n8n (400+ integrations), or Prefect. Policy teams can inspect and adjust step logic without writing code. Changes are version-controlled and auditable.

openfn deploy --project BENEFIT_CHECK
# or import YAML into n8n UI

Best for: teams without deep engineering capacity, rapid iteration, operational monitoring

🤖

Format 03 · Emerging

Agent Skill

Package the workflow as a callable tool — a typed function that a Public Agent (LLM) can invoke directly via function calling, the Model Context Protocol (MCP), or a skill registry. The agent does not see the internal steps — it calls the workflow by name and receives a structured result.

// As an MCP tool:
tools: [{ name: "check_eligibility",
  description: "Verify citizen eligibility
  for a benefit program via DPI",
  inputSchema: { national_id, program_id }}]

Best for: agentic architectures where the Public Agent decides which workflow to call, multi-service orchestration, MCP-native deployments

Governance note: The workflow's safeguard steps (consent, human review, audit log) execute inside the skill — they are not bypassed by the agent calling it.

Design Patterns

Patterns for building governable workflows

Pattern 01

Confidence thresholds over hard decisions

Every AI Block output includes a confidence score. Below threshold: human review. Above threshold: proceed. The threshold is a governance parameter, not a technical constant.

Pattern 02

Human escalation as a first-class step

Escalation paths are designed into workflows, not bolted on as exception handlers. Human review is a workflow step — with a timeout, an assignee, and an audit trail.

Pattern 03

Share workflows as templates

Every workflow can be published as an open template. Countries adapt the policy parameters; the orchestration logic is reused. This is how DPI extends to AI at scale.

Pattern 04

Consent is a callable step

User consent is not a static checkbox — it is a callable, auditable function in the workflow. Consent is verified before any data access, and its scope defines what the workflow can do.

Pattern 05

Inclusion built into the workflow

Voice-first interfaces, multilingual translation, USSD fallback — these are orchestrated as steps, not add-ons. The workflow decides which channel and language to use based on citizen context.

Pattern 06

AI operates inside governance

The workflow is the locus of control. AI Blocks are called from within the workflow — they cannot bypass governance steps, modify records directly, or act outside defined scope.

→ See the full implementation guide — YAML spec, no-code engines, and agent skill deployment