Spec 10: Approval & Handoff

DWS Spec 10: Approval & Handoff Protocol

Digital Worker Standard — DWS Specification

Version: 1.0 Tier: 2 — Orchestration Status: Release Candidate Dependencies: Spec 1 (Worker Identity), Spec 6 (Workflow & Phase Model), Spec 9 (Human-Worker Interaction)

1. Overview

This specification defines two “transfer of control” primitives that business processes require:

Approval gates — explicit human decision points where a designated person must sign off before work proceeds. Distinct from verification (Spec 8), which is quality evaluation by workers.
Handoffs — worker-to-worker transfer of an ongoing task or conversation with full context. Distinct from delegation (Spec 7), which assigns new tasks.

Both are normal-flow control transfers. Verification evaluates quality. Delegation assigns work. Escalation handles failures. Approval and handoff are neither: they are structured transfers of authority and responsibility during the normal course of business.

2. Approval Gate Schema

An approval gate is a checkpoint where a designated human must explicitly approve before work proceeds. Unlike verification gates, approval is about authority (“I approve this expenditure”), not quality (“this code is correct”).

{
  "type": "object",
  "required": ["gate_id", "name", "approvers", "materials"],
  "properties": {
    "gate_id": { "type": "string" },
    "name": { "type": "string" },
    "position": {
      "type": "object",
      "properties": {
        "workflow_id": { "type": "string" },
        "phase_id": { "type": "string" },
        "placement": { "type": "string", "enum": ["phase_exit", "workflow_exit", "checkpoint"] }
      }
    },
    "approvers": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "type": { "type": "string", "enum": ["role", "named_person"] },
          "value": { "type": "string" }
        }
      }
    },
    "quorum": {
      "type": "object",
      "properties": {
        "strategy": { "type": "string", "enum": ["any", "all", "n_of_m"] },
        "min_approvers": { "type": "integer", "minimum": 1 }
      }
    },
    "materials": {
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "artifact_type": { "type": "string" },
          "description": { "type": "string" },
          "required": { "type": "boolean", "default": true }
        }
      },
      "description": "Artifacts presented to the approver for their decision."
    },
    "decision_options": {
      "type": "array",
      "items": { "type": "string" },
      "default": ["approve", "reject", "request_changes"]
    },
    "delegation": {
      "type": "object",
      "properties": {
        "allowed": { "type": "boolean", "default": false },
        "max_delegation_depth": { "type": "integer", "default": 1 },
        "allowed_delegates": {
          "type": "array",
          "items": { "type": "string" },
          "description": "Roles or people who may receive delegated approval authority."
        }
      },
      "description": "Whether the designated approver can delegate their approval authority to someone else."
    },
    "sla": {
      "type": "object",
      "required": ["max_wait"],
      "properties": {
        "max_wait": { "type": "string", "description": "ISO 8601 duration." },
        "reminder_interval": { "type": "string" },
        "on_timeout": { "type": "string", "enum": ["escalate", "auto_approve", "abort"], "default": "escalate" }
      }
    }
  }
}

2.1 Approval Decisions

{
  "decision_id": "dec-001",
  "gate_id": "compliance-approval",
  "approver": { "type": "named_person", "value": "compliance-officer" },
  "decision": "approve",
  "comment": "Reviewed. Meets regulatory requirements.",
  "conditions": [],
  "timestamp": "2026-04-10T14:30:00Z"
}

Conditional approvals allow work to proceed while conditions resolve in parallel. The worker is responsible for satisfying conditions before final output delivery.

2.2 Approval SLA

When max_wait expires without a decision:

Action	Behaviour
`escalate`	Route to the next approver in the chain or to a supervisor.
`auto_approve`	Approve automatically. Use with caution; only for low-risk gates.
`abort`	Fail the workflow.

reminder_interval sends periodic reminders to the approver before the SLA expires.

3. Handoff Protocol

A handoff transfers control from one worker to another with full context. It differs from delegation (Spec 7): handoff transfers full control (departing worker is done), delegation assigns a subtask (departing worker waits).

3.1 Handoff Types

Type	Description
`conversation`	Human switches from worker A to worker B. Transfer summary, pending items, relevant artifacts.
`task`	Worker A transfers ongoing task to worker B. Transfer all artifacts, pending items, workflow context.
`role`	Worker A yields its role to worker B for the remainder of the workflow. Transfer everything from task handoff plus role-specific knowledge.

3.2 Context Transfer

The context transfer package:

{
  "handoff_id": "ho-001",
  "type": "task",
  "from_worker": "contract-analyst",
  "to_worker": "senior-contract-analyst",
  "context_transfer": {
    "summary": "Completed initial analysis of sections 1-4. Section 5 (indemnification) requires specialist review.",
    "artifacts": ["partial-analysis-report"],
    "pending_items": ["Review indemnification clause", "Check limitation of liability"],
    "knowledge_entries": ["ke-client-preferences-001"],
    "workflow_context_snapshot": "wf-snap-001"
  },
  "reason": "specialization",
  "acknowledgment_required": true
}

3.3 Handoff Protocol Steps

Initiate: Emit interaction.handoff_initiated event.
Validate: Receiving worker exists, has required role and capabilities, has capacity.
Package: Departing worker creates summary. Runtime assembles context transfer.
Transfer: Receiving worker instantiated with context.
Acknowledge: If required, receiving worker confirms readiness.
Complete: Control transfers. Departing worker released. Emit interaction.handoff_completed.

3.4 Failed Handoff

If the handoff fails (receiving worker unavailable, rejects, or times out):

Emit interaction.handoff_failed event.
Departing worker resumes work.
Runtime attempts alternative worker with same role.
If no alternative, escalate.

3.5 Context Boundaries

What MUST be transferred varies by handoff type, but in all cases:

MUST NOT transfer: Internal reasoning, model invocations, tool call history.
MUST transfer: Summary of work state, pending items, relevant artifacts.

The departing worker’s internal state is private. The handoff summary is the structured assessment of work state, not a dump of the reasoning trace.

4. Execution Checkpoints

When an approval gate activates, the runtime creates a checkpoint: a persisted snapshot of execution state that survives runtime restarts.

The checkpoint includes:

Completed phases and their outputs
Current phase output (pending approval)
All artifacts produced so far
Knowledge entries created during execution
Cost accumulation to date
Sequence number for event ordering

Checkpoints are emitted as workflow.checkpoint_created events and can be restored via workflow.checkpoint_restored.

5. Key Design Decisions

Decision	Resolution	Rationale
Approval vs verification	Separate mechanisms	Approval is about authority. Verification is about quality. A compliance officer approving a report is not evaluating code quality.
Handoff vs delegation	Separate concepts	Handoff transfers full control. Delegation assigns a subtask and waits. They have different context transfer requirements.
Approval SLA required	`max_wait` is a required field	Unbounded approval waits create stalled workflows. Every gate must have a timeout plan.
Handoff summary required	Departing worker must produce a structured summary	Artifacts alone are insufficient. The summary provides actionable context beyond what the artifacts contain.
Approval delegation	Optional, off by default	Some organisations need approval authority to be delegable. Others require strict sign-off from designated approvers.

6. References

Spec 1: Worker Identity — Authority levels determine which workers can approve at which gates.
Spec 6: Workflow & Phases — Approval gates and handoff transitions are defined within workflows.
Spec 8: Verification Framework — Verification gates evaluate quality; approval gates evaluate authority. Both may exist on the same phase.
Spec 9: Human-Worker Interaction — Approval gates are a specific type of human-worker interaction.
Spec 11: Events & Telemetry — Approval and handoff events.