Spec 7: Coordination Protocol

DWS Spec 7: Coordination 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)

1. Overview

This specification defines how multiple workers operate together without chaos. It covers task decomposition, dependency management, conflict detection and resolution, state synchronisation, and escalation.

The coordination protocol separates “multiple workers running independently” from “a team of workers collaborating effectively.” Without coordination, parallel worker execution produces conflicts, duplicated work, and inconsistent outputs. With it, workers operate as a structured team with clear task boundaries, dependency awareness, and conflict resolution.

DWS coordination uses a lightweight coordinator model by default: a designated coordinator worker manages task assignment and conflict resolution, while other workers communicate through the coordination layer rather than directly. For simple two-worker workflows, the coordinator role MAY be implicit (handled by the runtime). For complex multi-worker workflows, an explicit coordinator worker is RECOMMENDED.

1.1 Teams

A team is a named group of workers that operate together on related work. Teams provide a scoping mechanism for coordination: workers within a team share awareness of each other’s tasks and artifacts, while workers in different teams are isolated unless explicitly connected via contracts.

{
  "team": {
    "name": "contract-review-team",
    "members": [
      { "role": "coordinator", "worker_ref": "review-coordinator" },
      { "role": "implementor", "worker_ref": "contract-analyst" },
      { "role": "verifier", "worker_ref": "review-verifier" }
    ],
    "visibility": "team_only"
  }
}

Teams are optional. Workers that are not assigned to a team operate in the default coordination scope (the full job spec).

2. Task Decomposition

2.1 Task Schema

A task is an assignable unit of work derived from an intent artifact (Spec 4).

{
  "type": "object",
  "required": ["task_id", "intent_ref", "assigned_worker", "expected_output", "status"],
  "properties": {
    "task_id": { "type": "string", "format": "uuid" },
    "intent_ref": { "type": "string" },
    "assigned_worker": {
      "type": "object",
      "required": ["role"],
      "properties": {
        "role": { "type": "string" },
        "worker_id": { "type": "string" }
      }
    },
    "input_artifacts": {
      "type": "array",
      "items": { "type": "string" }
    },
    "expected_output": {
      "type": "object",
      "properties": {
        "artifact_type": { "type": "string" },
        "description": { "type": "string" }
      }
    },
    "dependencies": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["task_id", "type"],
        "properties": {
          "task_id": { "type": "string" },
          "type": { "type": "string", "enum": ["hard", "soft", "output"] },
          "description": { "type": "string" }
        }
      }
    },
    "deadline": { "type": "string", "format": "date-time" },
    "status": {
      "type": "string",
      "enum": ["pending", "assigned", "in_progress", "blocked", "completed", "failed", "cancelled"]
    },
    "priority": { "type": "string", "enum": ["critical", "high", "medium", "low"] }
  }
}

2.2 Decomposition Strategies

Strategy	Description
`by_component`	Decompose by system component or service boundary.
`by_skill`	Decompose by required skill. Each task maps to one skill.
`by_phase`	Decompose by workflow phase. Each task maps to one phase.
`by_domain`	Decompose by domain area.

2.3 Validation

Runtimes MUST validate task decomposition:

All requirements from the parent intent MUST be covered by at least one task.
No circular dependencies.
Every task MUST have an assigned worker role that exists in the job spec.

3. Dependency Management

3.1 Dependency Types

Type	Behaviour
`hard`	Blocks execution. The dependent task MUST NOT start until the dependency completes.
`soft`	Informational. The dependent task SHOULD use the dependency’s output but MAY proceed without it.
`output`	Requires a specific artifact from the dependency. Blocks until the artifact is available.

3.2 DAG Validation

Runtimes MUST validate that the dependency graph is a valid DAG (no cycles). Topological ordering determines execution sequence for hard and output dependencies.

3.3 Dynamic Dependencies

Dependencies MAY be discovered during execution. When a worker identifies a new dependency, it emits a coordination.dependency_discovered event. The runtime evaluates whether the dependency can be satisfied and either resolves or escalates it.

4. Conflict Detection & Resolution

4.1 Conflict Types

Type	Description
`artifact`	Two workers produce conflicting modifications to the same artifact.
`decision`	Two workers make contradictory decisions about the same aspect of the work.
`resource`	Two workers compete for the same limited resource (e.g., an external API rate limit).

4.2 Locking Model

DWS uses optimistic locking by default. Workers read artifact state, perform work, and attempt to commit. If the artifact has changed since the read, the commit fails and the worker must resolve the conflict.

Pessimistic locking (exclusive access) is available for artifacts that cannot tolerate concurrent modification:

{
  "lock": {
    "artifact_id": "contract-draft-v1",
    "holder_worker": "contract-analyst",
    "lock_type": "exclusive",
    "expires_at": "2026-04-10T12:00:00Z"
  }
}

4.3 Resolution Strategies

Strategy	Behaviour
`priority_based`	Higher-priority worker’s version wins.
`timestamp_based`	First write wins. Later writes must merge or defer.
`merge`	Runtime attempts to merge both changes. Requires merge-compatible artifact types.
`escalate_to_human`	A human resolves the conflict.

Default: timestamp_based for artifacts, escalate_to_human for decisions.

5. State Synchronisation

5.1 Progress Signalling

Workers report progress via coordination.task_progress events.

5.2 Shared State

Workers access shared state through the coordination layer, not directly. The runtime provides a read-modify-write interface with version checks (optimistic concurrency).

5.3 Awareness Model

Workers within a team can see:

Other workers’ roles and task assignments
Artifact state and availability
Task status and progress

Workers MUST NOT see:

Other workers’ reasoning or intermediate state
Other workers’ model invocations or tool call history

This boundary preserves context isolation (required for independent verification in Spec 8) while enabling coordination.

5.4 Worker-to-Worker Contracts

Worker-to-worker contracts formalise expectations between dependent workers. A contract specifies what one worker promises to deliver and what another worker expects to receive.

{
  "contract_id": "analyst-to-verifier",
  "name": "Analysis Output Contract",
  "version": "1.0.0",
  "parties": [
    { "role": "implementor", "obligation": "producer" },
    { "role": "verifier", "obligation": "consumer" }
  ],
  "artifact_guarantees": {
    "artifact_type": "analysis-report",
    "required_fields": ["$.findings", "$.summary", "$.methodology"],
    "format_version": "1.0.0"
  },
  "delivery_sla": {
    "max_duration": "PT2H",
    "on_breach": "escalate"
  },
  "quality_baseline": {
    "min_scores": { "completeness": 0.8, "accuracy": 0.9 },
    "required_dimensions": ["completeness", "accuracy"]
  }
}

Contracts are stored in the contracts/ directory of the job spec. The dws validate command checks that all contract parties exist and that artifact types match producer capabilities.

6. Escalation Protocol

6.1 Escalation Triggers

Escalation triggers are evaluated by the runtime, not by the worker:

Trigger	Condition
`confidence_below`	Worker’s reported confidence drops below threshold.
`timeout_exceeded`	Task duration exceeds configured limit.
`scope_exceeded`	Task requires capabilities outside the worker’s declaration.
`conflict_unresolved`	A conflict cannot be resolved by the configured strategy.
`human_requested`	A human explicitly requests escalation.
`repeated_failure`	The worker has failed the same task multiple times.

6.2 Escalation Targets

Escalation follows a priority chain:

Coordinator worker — if one exists in the team.
Human operator — if the coordinator cannot resolve.
Fallback workflow — a predefined workflow for handling escalations.

6.3 Escalation Context

The escalation payload includes:

The task that triggered escalation
Attempted actions and their outcomes
Conflicting parties (if applicable)
Recommended actions from the escalating worker

6.4 Resolution Actions

Action	Description
`override`	The escalation target makes the decision directly.
`reassign`	The task is reassigned to a different worker.
`abort`	The task is cancelled.
`modify_intent`	The intent is modified to make the task achievable.

7. Key Design Decisions

Decision	Resolution	Rationale
Lightweight coordinator	Default coordinator model, explicit for complex workflows	Avoids coordination overhead for simple two-worker scenarios while supporting complex multi-worker teams.
Optimistic locking default	Workers assume no conflict; resolve on commit	Most worker interactions do not involve concurrent artifact modification. Optimistic locking reduces coordination overhead in the common case.
Awareness boundary	Workers see task state, not reasoning	Preserves verification independence (Spec 8) while enabling coordination.
Contract enforcement	Validated at definition time, checked at runtime	Contracts are structural guarantees, not runtime suggestions.

8. References

A2A (Agent-to-Agent Protocol) — For cross-organisational worker coordination, see Spec 15 (Interoperability).
Spec 1: Worker Identity — Worker roles and delegation rules.
Spec 4: Intent Artifacts — Tasks are derived from intents.
Spec 6: Workflow & Phases — Coordination operates within the workflow phase structure.
Spec 8: Verification Framework — Context isolation requirements constrain the awareness model.
Spec 11: Events & Telemetry — All coordination events are emitted to the event stream.