Spec 1: Worker Identity

DWS Spec 1: Worker Identity & Capability Model

Digital Worker Standard — DWS Specification

Version: 1.0 Tier: 1 — Core Primitive Status: Release Candidate Dependencies: None (root primitive)

1. Overview

A worker in DWS is not a model, not a prompt, and not a running process. It is a structured role specification that any compliant runtime can instantiate.

The Worker Descriptor is the unit of identity and capability declaration within the protocol. It answers four questions:

Who is this worker? Identity, version, domain, and role classification.
What can it do? Declared skills, tools, and artifact types.
What is it allowed to do? Authority level and boundary declarations.
How does it coordinate? Delegation rules, dependencies, escalation triggers, and communication protocol.

Worker descriptors are definition-time artifacts. They live in version control, are reviewed like code, and are tagged with semantic versions. A descriptor does not prescribe which model backs the worker or how the runtime schedules it. It declares the contract that the runtime MUST satisfy when instantiating the worker.

This separation is deliberate. Model selection is a deployment concern. Identity and capability are design concerns. DWS treats them accordingly.

Design Analogy

The relationship between a worker descriptor and a running worker instance mirrors the relationship between a Kubernetes pod spec and a running pod. The spec declares intent; the runtime fulfils it. The spec is portable across runtimes; the running instance is not.

2. Worker Descriptor Schema

2.1 Identity

Every worker descriptor MUST include an identity block. The identity block uniquely identifies the worker within a DWS-compliant system.

Field	Type	Required	Description
`name`	string	MUST	Human-readable identifier. Lowercase, hyphenated.
`version`	string	MUST	Semantic version (e.g. `1.2.0`).
`domain`	string	MUST	The problem domain this worker operates in (e.g. `software-engineering`, `financial-analysis`).
`role`	string	MUST	Role classification. One of the RECOMMENDED archetypes or a custom role.
`description`	string	SHOULD	One-line summary of what this worker does.
`tags`	array of strings	MAY	Free-form labels for filtering and discovery.

RECOMMENDED role archetypes:

coordinator — Orchestrates work across other workers. Does not produce implementation artifacts directly.
implementor — Produces artifacts (code, documents, analyses). The workhorse role.
verifier — Evaluates artifacts against declared intent. Independent of the implementor.
advisor — Provides recommendations but does not produce binding artifacts.

These archetypes are RECOMMENDED, not required. Implementations MAY define custom roles, but SHOULD document how custom roles map to the standard archetypes for interoperability.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "properties": {
    "name": {
      "type": "string",
      "pattern": "^[a-z][a-z0-9-]*$"
    },
    "version": {
      "type": "string",
      "pattern": "^\\d+\\.\\d+\\.\\d+$"
    },
    "domain": {
      "type": "string"
    },
    "role": {
      "type": "string"
    },
    "description": {
      "type": "string"
    },
    "tags": {
      "type": "array",
      "items": { "type": "string" }
    }
  },
  "required": ["name", "version", "domain", "role"]
}

2.2 Authority Level

Authority levels define what decisions a worker can make without human approval. DWS uses a spectrum model rather than a binary autonomous/manual switch.

Level	Label	Behaviour
0	`escalate-only`	Worker MUST escalate every decision to a human or coordinator. It may gather information and prepare recommendations, but MUST NOT act on them.
1	`restricted`	Worker MAY act within a narrow, explicitly enumerated set of operations. All other operations MUST be escalated.
2	`supervised`	Worker MAY act on most operations within its declared capabilities. High-impact operations (defined by the runtime) MUST be escalated.
3	`autonomous`	Worker MAY act on all operations within its declared capabilities without approval. It MUST still log decisions and SHOULD notify on high-impact actions.

The authority level is a ceiling, not a floor. A runtime MAY constrain a worker below its declared authority level based on deployment policy. A runtime MUST NOT grant authority above the declared level.

{
  "authority": {
    "level": "supervised",
    "restricted_operations": [],
    "escalation_target": "human-reviewer"
  }
}

When level is restricted, the restricted_operations array MUST enumerate the operations the worker is permitted to perform. When level is supervised, the restricted_operations array SHOULD enumerate operations that require escalation despite the otherwise broad authority.

2.3 Boundary Declarations

Boundary declarations define negative scope: what the worker is explicitly NOT responsible for. These declarations serve two purposes:

Prevent scope creep. Without explicit boundaries, workers tend to expand into adjacent responsibilities, particularly when backed by capable models.
Make handoff points explicit. If this worker is not responsible for security review, another worker (or human) must be. Boundaries create implicit dependency relationships.

Field	Type	Required	Description
`excluded_domains`	array of strings	SHOULD	Domains this worker MUST NOT operate in.
`excluded_artifact_types`	array of strings	MAY	Artifact types this worker MUST NOT produce.
`excluded_operations`	array of strings	MAY	Specific operations this worker MUST NOT perform.
`boundary_notes`	string	MAY	Free-text explanation for human reviewers.

{
  "boundaries": {
    "excluded_domains": ["security-audit", "compliance-review"],
    "excluded_artifact_types": ["deployment-manifest"],
    "excluded_operations": ["delete-branch", "merge-to-main"],
    "boundary_notes": "This worker reviews code for correctness and style. Security and compliance review are handled by dedicated workers."
  }
}

A runtime MUST enforce boundary declarations. If a worker attempts an operation that falls within its declared boundaries, the runtime MUST reject the operation and MAY escalate it.

2.4 Model Requirements

Model requirements are expressed as capability contracts, not model names. A worker descriptor MUST NOT reference a specific model (e.g. gpt-4, claude-opus-4-20250514). It declares what capabilities the backing model must provide. The runtime resolves these requirements to a concrete model at instantiation time.

Field	Type	Required	Description
`tool_use`	boolean	MUST	Whether the model must support tool/function calling.
`structured_output`	boolean	MUST	Whether the model must support structured (JSON) output.
`min_context_window`	integer	SHOULD	Minimum context window in tokens.
`modalities`	array of strings	MUST	Required input/output modalities. Values: `"text"`, `"code"`, `"image"`, `"audio"`, `"video"`.
`reasoning_capability`	string	MAY	Minimum reasoning tier. One of: `"basic"`, `"standard"`, `"advanced"`.

{
  "model_requirements": {
    "tool_use": true,
    "structured_output": true,
    "min_context_window": 128000,
    "modalities": ["text", "code"],
    "reasoning_capability": "standard"
  }
}

This design means the same worker descriptor can run against different model providers without modification. The runtime is responsible for mapping capability contracts to available models.

2.5 Guardrails

Guardrails are synchronous validation rules evaluated on worker inputs and outputs at runtime. They are distinct from verification (Spec 8): guardrails are fast, narrow checks that prevent obviously invalid or unsafe actions in real-time. Verification is deep, holistic, post-phase evaluation against intent.

Think of guardrails as the safety rails on a highway. They don’t evaluate whether you’re driving to the right destination (that’s verification) — they prevent you from going off a cliff.

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "array",
  "items": {
    "type": "object",
    "properties": {
      "guardrail_id": { "type": "string" },
      "name": { "type": "string" },
      "target": {
        "type": "string",
        "enum": ["input", "output"]
      },
      "type": {
        "type": "string",
        "enum": ["content_filter", "schema_validation", "policy_check", "custom"]
      },
      "enforcement": {
        "type": "string",
        "enum": ["block", "warn", "log"],
        "description": "block: action rejected, worker must retry or escalate. warn: action proceeds, warning event emitted. log: action proceeds, result logged only."
      },
      "data_classification": {
        "type": "string",
        "enum": ["public", "internal", "confidential", "restricted"],
        "description": "Classification level of data this guardrail protects. Used for compliance reporting (Spec 12)."
      },
      "validator": {
        "type": "object",
        "properties": {
          "type": {
            "type": "string",
            "enum": ["json_schema", "regex", "keyword_list", "tool_ref"]
          },
          "config": { "type": "object" }
        },
        "required": ["type", "config"]
      },
      "message": { "type": "string" },
      "applies_to": {
        "type": "object",
        "properties": {
          "phases": { "type": "array", "items": { "type": "string" } },
          "skills": { "type": "array", "items": { "type": "string" } },
          "artifact_types": { "type": "array", "items": { "type": "string" } }
        }
      }
    },
    "required": ["guardrail_id", "name", "target", "type", "enforcement", "validator", "message"]
  }
}

Runtimes MUST evaluate input guardrails before passing inputs to the worker. Runtimes MUST evaluate output guardrails before committing worker output as artifacts.

2.5.1 Enforcement Semantics

block — Reject and retry or escalate.

When a guardrail with enforcement: "block" triggers:

The runtime MUST reject the action and MUST NOT commit the output as an artifact.
The runtime MUST emit a guardrail.blocked event (Spec 11) containing the guardrail ID, the violation details, and the attempt number.
The runtime MUST pass structured feedback to the worker containing: the guardrail’s message, which guardrail triggered (guardrail_id), and sufficient detail for the worker to understand what was rejected and why.
The worker re-executes with this feedback as additional context.
If the worker produces output that triggers the same guardrail again, steps 1-4 repeat up to the configured retry limit.
The maximum number of guardrail retries is governed by max_guardrail_retries on the workflow phase (Spec 6). If not specified, the default is 3.
When retries are exhausted, the runtime MUST escalate per the worker’s escalation_target (Section 2.2) and MUST emit a guardrail.exhausted event.

Guardrail retries are distinct from verification retries (Spec 8). Guardrail retries occur within a single phase execution attempt; verification retries occur between complete phase executions. A single verification attempt may contain multiple guardrail retry loops.

warn — Proceed with warning.

When a guardrail with enforcement: "warn" triggers:

The action proceeds — the runtime MUST NOT reject the output.
The runtime MUST emit a guardrail.warned event (Spec 11).
Warning events MUST be included in the phase output metadata so that downstream verification gates (Spec 8) and approval gates (Spec 10) can observe them.

log — Silent observation.

When a guardrail with enforcement: "log" triggers:

The action proceeds — the runtime MUST NOT reject the output.
The runtime MUST emit a guardrail.logged event (Spec 11).
No other action is taken. Log-level guardrails are for telemetry and calibration only.

2.5.2 Evaluation Order

When multiple guardrails apply to the same target (input or output):

All guardrails for the target MUST be evaluated, regardless of enforcement level.
If any block-level guardrail triggers, the action is rejected, even if other guardrails passed.
Results from all triggered guardrails (block, warn, and log) MUST be included in the feedback to the worker during a retry, so that the worker can address multiple violations simultaneously.

Aspect	Guardrails	Verification (Spec 8)
Timing	Synchronous, inline	Post-phase, asynchronous
Scope	Narrow, specific checks	Holistic evaluation against intent
Evaluator	Runtime (automated rules)	Independent verifier worker
Speed	Milliseconds	Minutes
Purpose	Prevent unsafe/invalid actions	Evaluate quality of completed work
Context	No intent awareness	Intent-referenced

2.6 Capacity & Availability

In a business, employees have schedules, workload limits, and availability windows. Digital workers are no different. Capacity declarations enable runtimes to make intelligent scheduling decisions and prevent worker overload.

{
  "capacity": {
    "max_concurrent_tasks": 3,
    "priority_preemption": {
      "enabled": true,
      "min_priority_to_preempt": "critical",
      "preemption_behavior": "checkpoint"
    },
    "availability": {
      "windows": [
        { "days": ["monday", "tuesday", "wednesday", "thursday", "friday"], "start_time": "09:00", "end_time": "18:00" }
      ],
      "timezone": "America/New_York",
      "outside_hours_behavior": "queue"
    },
    "workload": {
      "report_interval": "PT5M",
      "overload_threshold": 0.85
    }
  }
}

Runtimes MUST respect max_concurrent_tasks when assigning work. Runtimes SHOULD check availability.windows before scheduling. When outside_hours_behavior is queue, tasks MUST be queued and executed when the next availability window opens. When redirect, the runtime MUST find an alternative worker with the same role. Runtimes MUST emit a lifecycle.worker_capacity_changed event (Spec 11) when a worker’s effective capacity changes.

3. Capability Declaration

3.1 Skills

Skills are discrete units of learned behaviour (defined in Spec 3). A worker descriptor references skills by name and version.

Field	Type	Required	Description
`skill_name`	string	MUST	Reference to a skill defined in the skill registry.
`skill_version`	string	MUST	Semantic version of the skill definition.
`configuration`	object	MAY	Overrides for default skill parameters.

{
  "skills": [
    {
      "skill_name": "code-review",
      "skill_version": "1.0.0",
      "configuration": {
        "languages": ["typescript", "python"],
        "severity_threshold": "warning"
      }
    }
  ]
}

A worker SHOULD declare all skills it is expected to exercise. Runtimes MAY reject workers that invoke skills not listed in their descriptor.

3.2 Tools

Tools are external capabilities accessed via the Model Context Protocol (MCP). Each tool reference identifies an MCP-compliant tool server and its purpose within this worker’s operation.

Field	Type	Required	Description
`tool_uri`	string	MUST	URI of the MCP tool server.
`required`	boolean	MUST	Whether the worker can function without this tool.
`purpose`	string	SHOULD	Why this worker needs this tool.

{
  "tools": [
    {
      "tool_uri": "mcp://github.com/tools/git",
      "required": true,
      "purpose": "Read repository contents and diff information for code review."
    }
  ]
}

When required is true, the runtime MUST NOT instantiate the worker if the tool is unavailable. When required is false, the runtime SHOULD instantiate the worker and the worker MUST degrade gracefully.

3.3 Artifact Types

Artifact types declare what this worker produces and what it consumes. This creates a typed contract for the worker’s inputs and outputs.

{
  "artifacts": {
    "produces": ["review-report", "inline-comment-set"],
    "consumes": ["source-code", "diff", "test-results"]
  }
}

The artifact type system enables runtimes to validate that worker pipelines are well-typed: every artifact produced by one worker has a consumer, and every required input has a producer.

4. Coordination Interface

4.1 Delegation Rules

Delegation rules define which worker roles this worker can assign work to. These rules constrain the coordination graph and prevent unbounded delegation chains.

{
  "delegation_rules": [
    {
      "role_name": "test-runner",
      "max_delegations": 3,
      "conditions": ["review_contains_testable_changes"]
    }
  ]
}

A worker MUST NOT delegate to roles not listed in its delegation rules. A runtime MUST enforce max_delegations limits.

4.2 Dependency Declarations

Dependency declarations identify worker roles that must exist in the runtime for this worker to function. They differ from delegation rules: dependencies describe workers this worker receives work from or coordinates with, while delegation rules describe workers this worker sends work to.

{
  "dependencies": [
    {
      "role_name": "coordinator",
      "required": true,
      "purpose": "Receives review assignments and priority signals."
    }
  ]
}

When a required dependency is missing from the runtime, the runtime MUST NOT instantiate the worker.

4.3 Communication Protocol

Workers communicate through structured messages. The full message specification is defined in Spec 7: Coordination Protocol. This section defines the message types a worker descriptor MUST support.

Message Type	Direction	Description
`request`	Outbound	A structured ask from this worker to another.
`response`	Inbound	A reply to a request. Includes the produced artifact or an error.
`notification`	Either	An informational signal that does not require a response.
`escalation`	Outbound	A signal that the worker has reached a decision point it cannot resolve within its authority level.

4.4 Escalation Triggers

Escalation triggers define structured conditions under which a worker MUST escalate to its escalation target. These triggers are evaluated by the runtime, not by the worker itself, ensuring that escalation cannot be suppressed.

Field	Type	Description
`confidence_below`	float (0.0-1.0)	Escalate when the worker’s reported confidence drops below this threshold.
`timeout_exceeded`	string (duration)	Escalate when the worker has not completed its task within this duration (ISO 8601).
`scope_exceeded`	boolean	Escalate when the worker detects that the task requires capabilities outside its declaration.
`conflict_unresolved`	boolean	Escalate when the worker receives conflicting signals and cannot resolve them.
`human_requested`	boolean	Escalate when a human has explicitly requested review.

All escalation triggers are OPTIONAL. If no triggers are declared, the runtime SHOULD apply sensible defaults based on the worker’s authority level.

5. Lifecycle

5.1 Definition-Time Artifacts

Worker descriptors are definition-time artifacts. They are not generated at runtime. They live in version control alongside the project they serve. This means:

Worker descriptors are reviewed through the same pull request process as code.
Changes to worker capabilities are tracked in commit history.
Teams can audit who changed a worker’s authority level and when.
Rollback is a git revert, not a platform operation.

5.2 Versioning

Worker descriptors MUST use semantic versioning (MAJOR.MINOR.PATCH).

MAJOR: Breaking changes to the worker’s contract (see Section 5.3).
MINOR: New capabilities added, authority widened, new skills declared.
PATCH: Bug fixes to configuration, documentation updates, metadata changes.

5.3 Backward Compatibility

The following changes are breaking (require a MAJOR version bump):

Removing a skill from the skills array.
Removing an artifact type from produces.
Narrowing the authority level (e.g. autonomous to supervised).
Adding entries to excluded_domains or excluded_operations.
Reducing max_concurrent_tasks.

The following changes are non-breaking (MINOR version bump):

Adding a new skill.
Adding a new artifact type to produces or consumes.
Widening the authority level (e.g. restricted to supervised).
Adding a new tool reference.
Adding new delegation rules.
Increasing max_concurrent_tasks.
Adding guardrails.

5.4 Deprecation Protocol

When a worker descriptor is being retired:

Field	Type	Required	Description
`deprecated_at`	string (ISO 8601 date)	MUST	Date the worker was marked deprecated.
`replacement`	string	SHOULD	Name and version of the replacement worker.
`sunset_date`	string (ISO 8601 date)	SHOULD	Date after which the runtime MAY refuse to instantiate.
`migration_guide`	string	MAY	URI to a migration guide document.

A runtime SHOULD log a warning when instantiating a deprecated worker. A runtime MAY refuse to instantiate a worker past its sunset_date.

For full lifecycle management (draft, testing, staging, production, deprecated, retired), see Spec 14: Lifecycle & Versioning.

6. Key Design Decisions

Resolved

Decision	Resolution	Rationale
Worker identity is model-agnostic	Capability contracts, not model names	Worker descriptors must be portable across providers. Coupling to a model name creates vendor lock-in.
Authority uses a spectrum model	Four levels: `escalate-only`, `restricted`, `supervised`, `autonomous`	Binary autonomous/manual is too coarse. Real workflows require graduated trust.
Standard role taxonomies	RECOMMENDED archetypes, not required	Mandating specific roles would break domain-specific workflows. Recommending archetypes gives interoperability without rigidity.
Boundary declarations are explicit negative scope	Part of the worker descriptor	Positive-only capability declarations invite scope creep. Explicit boundaries force designers to think about handoff points.
Escalation triggers are runtime-evaluated	Runtime evaluates, not the worker	A worker cannot be trusted to reliably escalate on its own. The runtime observes behaviour and enforces triggers externally.
Guardrails vs verification	Separate mechanisms	Guardrails are fast, narrow, synchronous safety checks. Verification is deep, independent, holistic evaluation. Both are needed.

7. Example

A complete worker descriptor for a code review worker:

{
  "identity": {
    "name": "code-reviewer",
    "version": "1.0.0",
    "domain": "software-engineering",
    "role": "verifier",
    "description": "Reviews pull requests for correctness, style, and maintainability.",
    "tags": ["code-quality", "pull-request"]
  },

  "authority": {
    "level": "supervised",
    "restricted_operations": ["approve-merge", "request-changes-blocking"],
    "escalation_target": "engineering-lead"
  },

  "boundaries": {
    "excluded_domains": ["security-audit", "performance-benchmarking"],
    "excluded_artifact_types": ["deployment-manifest", "infrastructure-config"],
    "excluded_operations": ["merge-to-main", "delete-branch", "modify-ci-config"],
    "boundary_notes": "Reviews code for correctness and style only. Security review, performance analysis, and deployment decisions are out of scope."
  },

  "model_requirements": {
    "tool_use": true,
    "structured_output": true,
    "min_context_window": 128000,
    "modalities": ["text", "code"],
    "reasoning_capability": "standard"
  },

  "skills": [
    {
      "skill_name": "code-review",
      "skill_version": "1.0.0",
      "configuration": {
        "languages": ["typescript", "python", "go"],
        "style_guides": ["project-style-guide-v2"],
        "severity_threshold": "warning"
      }
    },
    {
      "skill_name": "test-coverage-analysis",
      "skill_version": "1.0.0"
    }
  ],

  "tools": [
    {
      "tool_uri": "mcp://github.com/tools/git",
      "required": true,
      "purpose": "Read repository contents, branches, and diffs."
    },
    {
      "tool_uri": "mcp://github.com/tools/github-api",
      "required": true,
      "purpose": "Read pull request metadata, post review comments."
    },
    {
      "tool_uri": "mcp://internal/tools/linter",
      "required": false,
      "purpose": "Run project linters for automated style checks."
    }
  ],

  "artifacts": {
    "produces": ["review-report", "inline-comment-set", "review-summary"],
    "consumes": ["source-code", "diff", "test-results", "pull-request-metadata"]
  },

  "delegation_rules": [
    {
      "role_name": "test-runner",
      "max_delegations": 2,
      "conditions": ["diff_contains_testable_changes"]
    }
  ],

  "dependencies": [
    {
      "role_name": "coordinator",
      "required": true,
      "purpose": "Receives review assignments and priority signals."
    }
  ],

  "communication": {
    "sends": ["response", "notification", "escalation"],
    "receives": ["request", "notification"]
  },

  "escalation_triggers": {
    "confidence_below": 0.7,
    "timeout_exceeded": "PT15M",
    "scope_exceeded": true,
    "conflict_unresolved": true,
    "human_requested": true
  },

  "guardrails": [
    {
      "guardrail_id": "guard-no-pii",
      "name": "PII Output Filter",
      "target": "output",
      "type": "content_filter",
      "enforcement": "block",
      "data_classification": "restricted",
      "validator": {
        "type": "regex",
        "config": {
          "patterns": ["\\b\\d{3}-\\d{2}-\\d{4}\\b"],
          "description": "Blocks output containing SSN patterns."
        }
      },
      "message": "Output must not contain personally identifiable information."
    }
  ],

  "capacity": {
    "max_concurrent_tasks": 5,
    "priority_preemption": {
      "enabled": true,
      "min_priority_to_preempt": "critical",
      "preemption_behavior": "pause"
    },
    "availability": {
      "windows": [],
      "timezone": "UTC",
      "outside_hours_behavior": "queue"
    }
  }
}

8. References

Model Context Protocol (MCP): Tool definition format and tool server specification. The tool_uri field in worker descriptors follows MCP addressing conventions.
Kubernetes Pod Spec: Structural analogy for the relationship between worker descriptors and worker instances.
RFC 2119: Key words for use in specifications. This document uses MUST, SHOULD, and MAY as defined in RFC 2119.
Semantic Versioning 2.0.0: Versioning scheme used for worker descriptors.
DWS Spec 3: Skill Specification: Defines the skill registry referenced by worker capability declarations.
DWS Spec 7: Coordination Protocol: Defines the full message specification referenced by the communication protocol section.
DWS Spec 14: Lifecycle & Versioning: Defines the full worker lifecycle from draft through retirement.