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

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 how to implement workflows with code (YAML) and no-code tools (OpenFn, n8n)