Spec 5: Outcome Artifacts

DWS Spec 5: Outcome Artifacts

Digital Worker Standard — DWS Specification

Version: 1.0 Tier: 1 — Core Primitive Status: Release Candidate Dependencies: Spec 4 (Intent Artifacts), Spec 6 (Workflow & Phases), Spec 11 (Events & Telemetry)

1. Overview

Outcome artifacts are the structured representation of what a worker produces and where it goes. They replace implicit output handling with codified, verifiable delivery contracts that close the loop between intent and execution.

An outcome artifact captures the primary output, its delivery channels, its success criteria, its escalation routing, and its failure handling. It is the unit against which the runtime evaluates output readiness before delivery. Without structured outcome, a worker’s output is undefined: it cannot be independently verified, cannot produce an auditable trail, cannot route work to downstream systems, and cannot be governed as an accountable entity.

Intent and Outcome are the two poles of a DWS worker’s execution contract:

Intent — the structured objective coming in: what the worker is asked to do, by whom, and what success looks like
Outcome — the structured result going out: what the worker produced, where it is routed, whether it succeeded, and what happens when it doesn’t

An outcome definition is part of the worker’s definition-time specification, authored alongside Intent, Skills, and Workflow. The runtime is responsible for the mechanics of delivery. The Outcome spec defines the what, where, success criteria, and failure handling. The runtime handles the how.

2. Outcome Artifact Schema

An outcome artifact is a JSON file stored in the outcomes/ directory of a job spec. Each outcome artifact defines the output contract for a specific workflow or workflow phase.

2.1 Required Fields

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["id", "name", "version", "workflow_ref", "primary_output", "delivery_channels", "success_criteria"],
  "properties": {
    "id": {
      "type": "string",
      "pattern": "^[a-z][a-z0-9-]*$"
    },
    "name": { "type": "string" },
    "version": {
      "type": "string",
      "pattern": "^\\d+\\.\\d+\\.\\d+$"
    },
    "workflow_ref": {
      "type": "string",
      "description": "Format: '{workflow-name}' or '{workflow-name}:{phase-id}' for phase-specific outcomes."
    },
    "primary_output": {
      "type": "object",
      "required": ["type", "format", "description"],
      "properties": {
        "type": {
          "type": "string",
          "enum": ["document", "structured_data", "code_change", "decision", "analysis", "notification", "trigger", "none"]
        },
        "format": { "type": "string" },
        "schema_ref": { "type": "string" },
        "description": { "type": "string" }
      }
    },
    "delivery_channels": {
      "type": "array",
      "minItems": 1,
      "items": { "$ref": "#/$defs/delivery_channel" }
    },
    "success_criteria": {
      "type": "array",
      "minItems": 1,
      "items": { "$ref": "#/$defs/success_criterion" }
    },
    "retention_policy": {
      "type": "object",
      "properties": {
        "retain_output": { "type": "boolean", "default": true },
        "retention_days": { "type": "integer", "minimum": 1 },
        "data_classification": {
          "type": "string",
          "enum": ["public", "internal", "confidential", "restricted"],
          "description": "Classification of the output artifact. Governs retention and export rules. See Spec 13."
        }
      },
      "description": "How long output artifacts are retained and under what classification."
    },
    "escalation_routing": { "$ref": "#/$defs/escalation_routing" },
    "failure_handling": { "$ref": "#/$defs/failure_handling" }
  }
}

2.2 Output Format Values

Output Type	Valid Formats
`document`	`markdown`, `pdf`, `docx`, `html`, `plain_text`
`structured_data`	`json`, `csv`, `yaml`
`code_change`	`diff`, `commit`
`decision`	`structured_decision`
`analysis`	`markdown`, `json`, `html`
`notification`	`plain_text`, `html`
`trigger`	The event type string (e.g., `build.requested`)
`none`	`any`

3. Delivery Channel Types

The delivery_channels array defines where output is routed after production. Channels are attempted in priority order (lower number = higher priority). Channels with the same priority are attempted in parallel.

3.1 Channel Types

Type	Description
`source_reply`	Respond via the same channel the intent arrived on. No target configuration required.
`system_write`	Write to a named external system (CRM, ticketing, database). Target: `{ "system": "salesforce" }`.
`downstream_worker`	Pass output as intent to another DWS worker. Target: `{ "worker_ref": "contract-reviewer:legal-review" }`.
`human_approver`	Route to a named person or role for review. Target: `{ "role": "compliance-officer" }`.
`event_stream_only`	Log to the event store only. No active delivery.
`webhook`	POST the outcome envelope to a URL. Target: `{ "url": "https://hooks.example.com/outcomes" }`.

3.2 Conditional Delivery

Any channel may include a conditions array. When conditions are defined, the channel is only used if all conditions evaluate to true. Otherwise, the channel is skipped and the next channel by priority is tried.

3.3 Failure Cascading

When delivery to a channel fails:

Action	Behaviour
`fallback_to_next`	Try the next channel by priority. If no more channels remain, escalate.
`escalate`	Trigger the escalation routing defined on the outcome.
`abort`	Fail the workflow. Emit an `outcome.delivery_failed` event.

4. Success Criteria

Outcome success criteria evaluate output quality: whether the output is ready for delivery. They are evaluated after the primary output is produced and before any delivery channel is invoked.

Outcome success criteria reuse the same success_criterion schema as Intent (Spec 4):

	Intent Success Criteria	Outcome Success Criteria
Evaluates	Business objectives	Output quality
Defined by	The requester	The worker designer
When evaluated	After execution completes	After output produced, before delivery
Blocks	Workflow completion	Output delivery

Both must pass before the workflow can reach completed state.

5. Escalation Routing

Escalation routing defines how the worker communicates when it hits an authority boundary, a confidence threshold, or a verification failure.

5.1 Escalation Targets

Target Type	Description
`role`	Route to a role (e.g., `compliance-officer`). Runtime resolves the person.
`named_person`	Route to a specific person.
`channel`	Route to a delivery channel defined on this outcome.

5.2 Escalation Formats

Format	Description
`structured_decision_request`	Structured prompt with options and a recommendation.
`plain_summary`	Prose summary of the situation.
`full_context`	Complete execution context passed to the escalation target.

5.3 Escalation Triggers

Trigger	Fired When
`authority_boundary_hit`	Worker reaches the boundary of its authority level.
`confidence_below_threshold`	Worker’s confidence in its output falls below threshold.
`verification_failed`	The Verification Framework rejects the output.
`success_criteria_unmet`	Blocking outcome success criteria fail.
`delivery_failed_all_channels`	All delivery channels attempted and all failed.
`cost_ceiling_exceeded`	Execution costs exceed the configured ceiling.
`human_requested`	A human explicitly requests escalation.

6. Failure Handling

6.1 Execution Failure

When the worker fails before producing output:

Action	Behaviour
`escalate`	Trigger escalation routing.
`retry`	Re-execute up to `max_retries` times, waiting `retry_delay` between attempts.
`abort_with_event`	Fail the workflow. Emit `outcome.delivery_failed`.

6.2 Success Criteria Failure

When output is produced but blocking success criteria fail:

Action	Behaviour
`escalate`	Trigger escalation routing. Payload includes output and failing criteria.
`deliver_with_flag`	Route to delivery channels with `status: "delivered_with_flag"`.
`abort_with_event`	Discard the output and fail the workflow.

7. The Outcome Envelope

When the runtime delivers output, it wraps it in an Outcome Envelope: a standard structure carrying the output plus execution metadata.

{
  "type": "object",
  "required": ["outcome_id", "intent_ref", "worker_ref", "execution_id", "status", "produced_at", "primary_output", "success_criteria_results", "delivery_channel_id", "event_ref"],
  "properties": {
    "outcome_id": { "type": "string" },
    "intent_ref": { "type": "string" },
    "worker_ref": { "type": "string" },
    "execution_id": { "type": "string" },
    "status": {
      "type": "string",
      "enum": ["succeeded", "failed", "escalated", "delivered_with_flag"]
    },
    "produced_at": { "type": "string", "format": "date-time" },
    "primary_output": {
      "type": "object",
      "properties": {
        "type": { "type": "string" },
        "format": { "type": "string" },
        "content": {}
      }
    },
    "success_criteria_results": {
      "type": "array",
      "items": {
        "type": "object",
        "required": ["dimension", "passed"],
        "properties": {
          "dimension": { "type": "string" },
          "passed": { "type": "boolean" },
          "evidence": { "type": ["string", "null"] }
        }
      }
    },
    "delivery_channel_id": { "type": "string" },
    "event_ref": { "type": "string" }
  }
}

8. Relationship to Intent

Intent is the work order. Outcome is the delivery receipt.

	Intent	Outcome
Direction	Inbound	Outbound
Defines	What to do, success criteria, constraints	What was produced, where it goes, quality criteria
Authored by	The requester	The worker designer
Lifecycle	Evolves through git + event-sourced mutations	Static definition; runtime produces envelopes against it

A worker without an Intent has no objective. A worker without an Outcome has no delivery contract. Together, they make a worker independently verifiable and auditable.

9. Verification Integration

9.1 Pre-Delivery Verification

After the worker produces output and before any delivery channel is invoked, the verifier evaluates output against all blocking: true Outcome success criteria.

Worker completes execution and produces primary output.
Runtime emits outcome.produced event.
Verifier evaluates output against Outcome success criteria.
If all blocking criteria pass: emit outcome.verification_passed, proceed to delivery.
If any blocking criterion fails: emit outcome.verification_failed, follow failure handling.

9.2 Dual Verification Gates

Gate	Evaluates	When	Blocks
Pre-delivery	Outcome success criteria	After output produced, before delivery	Output delivery
Post-execution	Intent success criteria	After delivery completes	Workflow completion

Both gates must pass for the workflow to reach completed state.

10. Outcome Events

Event Type	When Emitted
`outcome.produced`	Primary output ready.
`outcome.verification_passed`	All blocking criteria pass.
`outcome.verification_failed`	Blocking criteria fail.
`outcome.delivery_attempted`	Runtime begins delivery to a channel.
`outcome.delivery_succeeded`	Delivery confirmed.
`outcome.delivery_failed`	Delivery failed.
`outcome.escalated`	Escalation triggered.
`outcome.escalation_responded`	Human response received.
`outcome.escalation_timed_out`	Response window expired.
`outcome.completed`	All delivery channels resolved.

11. Key Design Decisions

Decision	Resolution	Rationale
Outcome as definition-time object	Part of the worker spec, not generated at runtime.	Keeps the output contract auditable and version-controlled.
Success criteria reuse	Same schema as Intent.	Avoids unnecessary divergence and tooling complexity.
Delivery channel resolution	Channels define what and where; runtime resolves how.	Connection details are environment config, not spec.
Envelope as delivery unit	All channels receive a standardised envelope.	Downstream systems need execution metadata.

12. References

Spec 4: Intent Artifacts — Intent defines the input contract; Outcome defines the output contract.
Spec 6: Workflow & Phases — Workflows reference outcomes via workflow_ref.
Spec 8: Verification Framework — Evaluates both intent and outcome success criteria.
Spec 11: Events & Telemetry — All outcome lifecycle events are emitted to the event stream.
Spec 13: Security Model — Governs data classification for output artifacts.