Spec 9: Human-Worker Interaction

DWS Spec 9: Human-Worker Interaction Model

Digital Worker Standard — DWS Specification

Version: 1.0 Tier: 2 — Orchestration Status: Release Candidate Dependencies: Spec 1 (Worker Identity), Spec 4 (Intent Artifacts), Spec 6 (Workflow & Phase Model)

1. Overview

DWS’s existing model treats humans as either authors (they write intents, review PRs, commit definitions) or escalation targets (workers get stuck and flag a human). Real business work is neither. A human and a digital worker operating together looks more like pair work than a vending machine: the human provides direction, asks questions, gives feedback on drafts, and the worker does the same in return.

This specification defines how workers interact with humans during normal execution, not just when they fail. It introduces three interaction modes, a structured check-in system, feedback channels for mid-task human input, and a question protocol for workers that need clarification without escalating.

Key Terms

Interaction Mode: How closely a human is involved during worker execution. Distinct from authority level (Spec 1), which defines what a worker is allowed to do.
Check-In: A structured progress report from worker to human.
Feedback Channel: A mechanism for humans to provide input to workers during execution.
Question: A structured request from a worker to a human for information or preference, distinct from escalation.

2. Interaction Modes

Interaction modes define the degree of human involvement during a workflow phase. They are set per-phase in the workflow definition (Spec 6), because the same worker may operate autonomously in one phase and collaboratively in another.

Interaction mode is not the same as authority level. Authority (Spec 1) defines what the worker is allowed to do. Interaction mode defines how closely a human is involved while the worker operates.

Mode	Description	Human Involvement
`autonomous`	Worker operates independently. Human receives results at phase completion. Check-ins at milestones only.	Minimal: review output after completion.
`collaborative`	Worker and human work together. Worker asks questions, shares drafts, requests feedback. Human provides direction mid-task.	Active: ongoing dialogue during execution.
`supervised`	Human monitors in real-time. Worker pauses at key decision points for human input before proceeding.	High: human approves key decisions inline.

2.1 Schema

{
  "type": "object",
  "required": ["mode"],
  "properties": {
    "mode": { "type": "string", "enum": ["autonomous", "collaborative", "supervised"] },
    "check_in_policy": { "type": "object" },
    "feedback_channels": {
      "type": "array",
      "items": { "type": "string", "enum": ["inline", "review", "annotation", "directive"] }
    },
    "notification_preferences": {
      "type": "object",
      "properties": {
        "channel": { "type": "string", "enum": ["email", "slack", "dashboard", "webhook"] },
        "frequency": { "type": "string", "enum": ["immediate", "batched", "daily_digest"] },
        "urgency_threshold": {
          "type": "string",
          "enum": ["all", "warnings_and_above", "escalations_only"],
          "description": "Minimum urgency level for notifications to be sent."
        }
      },
      "description": "How and when humans are notified about worker activity."
    }
  }
}

3. Check-In Policy

Check-ins are structured progress reports from worker to human.

3.1 Frequency

Time-based: ISO 8601 duration (e.g., PT15M for every 15 minutes).
Event-based: Triggered by specific events: phase_entry, artifact_produced, decision_point, confidence_drop, milestone, error_recovered, cost_threshold.

3.2 Format

{
  "status": "in_progress",
  "progress_percentage": 65,
  "current_activity": "Reviewing authentication module for SQL injection patterns.",
  "blockers": [],
  "decisions_pending": [],
  "artifacts_produced": ["partial-review-report"],
  "next_milestone": "Complete security review of remaining 3 modules.",
  "estimated_completion": "PT45M"
}

3.3 Channel

Check-ins are delivered via: event (emits interaction.check_in event), webhook, or inline (direct message in collaborative mode).

4. Feedback Channels

Channel	Description	When Used
`inline`	Synchronous direct message during execution.	Collaborative and supervised modes.
`review`	Asynchronous review of completed artifacts.	All modes.
`annotation`	Line-level or section-level comments on specific parts.	Collaborative mode, especially for document/code review.
`directive`	Priority or direction changes mid-task.	All modes. Overrides current approach without requiring a new intent.

4.1 Feedback Acknowledgment

Workers MUST acknowledge received feedback with one of:

Status	Meaning
`accepted`	Will incorporate the feedback.
`noted`	Acknowledged but not changing approach (with reason).
`deferred`	Valid feedback but belongs in a later phase.
`conflicts`	Conflicts with constraints. May escalate.

5. Question Protocol

Workers may need information or preferences from humans without escalating.

5.1 Question Types

Type	Description
`clarification`	Worker needs information the intent didn’t provide.
`preference`	Worker needs a human to choose between valid options.
`confirmation`	Worker wants to verify its understanding before proceeding.

5.2 Urgency

blocking — Worker pauses until answer arrives or timeout expires.
non_blocking — Worker continues with default_action. Answer is incorporated if it arrives before phase completion.

5.3 Question vs Escalation

A question is normal workflow. An escalation is a failure or limit condition. Questions are configurable as blocking or non-blocking. Escalations are always blocking.

6. Artifact Visibility

Mode	In-progress artifacts	Drafts	Final artifacts
`autonomous`	Hidden	Unavailable	Visible after phase exit
`collaborative`	Visible on request	Available for review	Visible after phase exit
`supervised`	Always visible	Encouraged for continuous feedback	Visible after phase exit

7. Human Availability

Humans signal their availability to the runtime:

Status	Meaning
`available`	Normal operations. All interaction types.
`busy`	Non-blocking questions only.
`away`	Queue everything until return.
`do_not_disturb`	Escalations only.

When a human is away or do_not_disturb, workers in collaborative or supervised mode SHOULD fall back to autonomous behaviour for non-critical interactions.

8. Key Design Decisions

Decision	Resolution	Rationale
Separate interaction mode from authority level	Different concepts, different configuration	A worker with `authority: autonomous` and `interaction_mode: collaborative` can make decisions independently but keeps a human informed.
Push-based check-ins	Worker pushes progress to human, not human polling	Reduces human overhead. Pull is available but not the default pattern.
Question vs escalation	Separate protocols	Questions are normal workflow. Escalations are failure conditions. Merging them makes every question feel like a crisis.
Worker as sole artifact producer	Humans provide feedback; workers incorporate it	Avoids concurrent editing conflicts. Clear ownership of the artifact.

9. References

Spec 1: Worker Identity — Authority levels constrain what workers can do; interaction modes constrain how closely humans are involved.
Spec 6: Workflow & Phases — Interaction modes are set per-phase.
Spec 10: Approval & Handoff — Approval gates are a specific type of human interaction at decision points.
Spec 11: Events & Telemetry — Interaction events: check_in, question_asked, question_answered, feedback_received.