DCL Language Reference

This reference describes DCL by language construct. It is based on the repository's primitive contracts, surface syntax direction, compiler duties, context semantics, policy semantics, and lifecycle documents, adjusted to the current compiler-supported language shape.

Current language: DCL v0.9. Status: Experimental. Compiler: 0.1.0.

Construct Index

Program

A DCL program is a set of source files compiled together into a validated semantic model. Files are authoring units; compiler meaning must not depend on file order or declaration order.

The compiler is the source of truth for example validity. It rejects errors such as undefined symbols, missing capability intent, missing outcomes, invalid policy concerns, and invalid lifecycle references.

Context

A context is a semantic ownership boundary. It is not a file, folder, package, deployment unit, or runtime module. A context groups declarations into an area of architectural responsibility.

Ownership

Every declaration belongs to exactly one context: capability, actor, event, effect, policy, and shape declarations are all owned by their containing context.

Dependencies

Dependencies are explicit. A context that uses declarations from another context must declare depends on ContextName. Visibility is not transitive: if A depends on B, and B depends on C, A does not automatically see C.

Cycles

Circular dependencies are invalid. Resolve cycles by extracting common declarations into a shared context, by using events between contexts, or by moving ownership to a higher-level capability.

language dcl 0.9

context Shared {
  actor Customer is human

  shape SharedOrderInput {
    orderId: Uuid required
    customerId: Uuid required
  }

  event SharedOrderSubmitted is {
    orderId: Uuid required
  }
}

language dcl 0.9

context Sales {
  depends on Shared

  effect PersistSalesOrder is persistence

  capability AcceptSalesOrder {
    intent SharedOrderInput from Customer

    outcomes {
      SalesOrderAccepted
      SalesOrderDeferred
    }

    effect PersistSalesOrder

    observe {
      event SharedOrderSubmitted count as shared_orders_submitted
      outcome SalesOrderAccepted count as sales_orders_accepted
    }

    when {
      PersistSalesOrder unresolved then SalesOrderDeferred
      otherwise then SalesOrderAccepted
    }
  }
}

Shape

A shape defines reusable structured data. Shapes are used by intent inputs, event payloads, and outcome payloads.

Built-in value types currently include Text, Boolean, Number, Date, DateTime, Uuid, Email, and Money.

Actor

An actor represents an initiating or participating party. Actors may be humans, systems, agents, scheduled processes, or authority contexts.

Event

An event is a named signal. Events may have structured payloads. Capability event declarations state which events the capability is an emission source for; they do not prescribe broker, topic, transport, or delivery semantics.

Lifecycle waits and transitions can reference events. In a local lifecycle, omitted event source means the owning capability when ownership is clear. In a supervising lifecycle, the source capability must be explicit.

Effect

An effect declares an externally meaningful action caused by a capability. Effects describe semantic change, not infrastructure mechanics.

Effects may be used singly or in an ordered effects block. after expresses explicit ordering. Current examples use effect classifications such as persistence and notification.

Policy

Policies express portable execution qualities. Authors declare policies and attach them to semantic boundaries. The compiler derives effective policy envelopes; authors do not write those envelopes directly.

Families

Supported policy families include reliability, availability, scalability, performance, security, compliance, governance, and data_protection.

Attachment Targets

Policies may govern capability, effect, outcome, event, and lifecycle boundaries when supported by the compiler.

Composition

Multiple policies can apply to the same boundary. The compiler derives the effective policy envelope, checks family/concern compatibility, detects conflicts, and records obligations in IR.

language dcl 0.9

actor Operator is human

effect PublishInvoice is notification
effect PersistInvoice is persistence

policy InvoicePerformance {
  family performance
  throughput above 100 per minute
}

policy InvoiceSecurity {
  family security
  authentication required
  authorization required
  encryption required
}

shape InvoiceInput {
  invoiceId: Uuid required
  customerId: Uuid required
}

event InvoicePublished is {
  invoiceId: Uuid required
}

capability PublishCustomerInvoice {
  intent InvoiceInput from Operator

  outcomes {
    InvoiceAccepted
    InvoicePublishDeferred
  }

  effects {
    PersistInvoice
    PublishInvoice after PersistInvoice
  }

  policies {
    InvoicePerformance governs capability
    InvoicePerformance governs effect PublishInvoice
    InvoiceSecurity governs event InvoicePublished
  }

  observe {
    capability duration as invoice_publish_duration
    effect PublishInvoice count failures as invoice_publish_failures
    event InvoicePublished count as invoices_published
    outcome InvoicePublishDeferred count as invoice_publish_deferred
  }

  when {
    PublishInvoice unresolved then InvoicePublishDeferred
    otherwise then InvoiceAccepted
  }
}

Capability

A capability is the main unit of DCL responsibility. It evaluates intent, enforces rules, applies policies, produces outcomes, and may cause effects, emit events, or own lifecycle state.

language dcl 0.9

actor User is human

shape GreetingInput {
  name: Text required
}

capability SayHello {
  intent GreetingInput from User

  outcome GreetingPrepared

  when {
    always then GreetingPrepared
  }
}

Intent

Intent is the transport-agnostic expression of a desired business action. It identifies the input shape and actor source for a capability.

Intent must belong to a capability. It does not imply HTTP, synchronous completion, queue semantics, or any specific runtime entry point.

Outcome

An outcome is a finite named result class. Outcomes represent success, rejection, deferral, expiry, failure, escalation, or other meaningful completions without treating failure as an exception by default.

Outcomes may drive lifecycle transitions, observations, policies, and future generated artifacts. The compiler rejects references to undeclared outcomes.

Rule

A rule is a named invariant or business condition. Rules may refer to input fields and named actor roles. Rule expressions prefer human-readable operators such as is true, is present, is less than, and is not equal to.

Rules become meaningful when they participate in outcome causation, usually through a when branch such as a rule being violated.

When

The when block declares explicit outcome causation. It connects rule violations, unresolved effects, unconditional causation, and fallback causation to declared outcomes.

language dcl 0.9

actor Customer is human

effect PersistRegistration is persistence
effect SendVerificationMessage is notification

shape RegistrationInput {
  email: Email required
  acceptedTerms: Boolean required
}

event VerificationMessageSent is {
  email: Email required
}

capability RegisterCustomer {
  intent RegistrationInput from Customer

  outcomes {
    RegistrationAccepted
    TermsRejected
    VerificationDeferred
  }

  rule TermsAccepted: input.acceptedTerms is true

  effects {
    PersistRegistration
    SendVerificationMessage after PersistRegistration
  }

  events {
    emits VerificationMessageSent
  }

  when {
    TermsAccepted violated then TermsRejected
    SendVerificationMessage unresolved then VerificationDeferred
    otherwise then RegistrationAccepted
  }
}

Lifecycle

A lifecycle describes business progression over time. It has an owner, steps, transitions, optional waits, optional deadlines, optional recovery, and terminal states.

Local Lifecycle

A lifecycle declared inside a capability is owned by that capability. Current syntax prefers semantic phrases such as waits for event and requires decision from over authored kind metadata.

language dcl 0.9

actor Customer is human

shape PaymentInput {
  orderId: Uuid required
  amount: Money required
}

event PaymentReceived is {
  orderId: Uuid required
}

capability CollectPayment {
  intent PaymentInput from Customer

  outcomes {
    PaymentRequested
    PaymentExpired
  }

  when {
    always then PaymentRequested
  }

  events {
    emits PaymentReceived
  }

  lifecycle {
    begin AwaitingPayment

    step AwaitingPayment waits for event PaymentReceived {
      deadline 15 minutes causing outcome PaymentExpired
    }

    end Paid
    end Expired

    move AwaitingPayment to Paid
      on event PaymentReceived

    move AwaitingPayment to Expired
      on outcome PaymentExpired
  }
}

Supervising Lifecycle

A supervising lifecycle is owned by one capability and coordinated through contributor capabilities. Contributors may produce outcomes or events that cause movement, but they do not mutate lifecycle state directly.

Supervising lifecycle transitions must declare explicit sources. The compiler validates contributor existence, source outcomes/events, reachability, and unambiguous transition causes where possible.

language dcl 0.9

actor Customer is human
actor WarehouseOperator is human

effect ReserveStockRecord is persistence
effect CapturePaymentRecord is persistence
effect DispatchParcel is notification

shape OrderInput {
  orderId: Uuid required
  sku: Text required
  quantity: Number required
}

shape PickInput {
  orderId: Uuid required
}

event ParcelDispatched is {
  orderId: Uuid required
}

capability ReserveInventory {
  intent OrderInput from Customer
  outcomes {
    InventoryReserved
    InventoryUnavailable
  }
  effect ReserveStockRecord
  when {
    ReserveStockRecord unresolved then InventoryUnavailable
    otherwise then InventoryReserved
  }
}

capability CapturePayment {
  intent OrderInput from Customer
  outcomes {
    PaymentCaptured
    PaymentDeclined
  }
  effect CapturePaymentRecord
  when {
    CapturePaymentRecord unresolved then PaymentDeclined
    otherwise then PaymentCaptured
  }
}

capability ShipOrder {
  intent PickInput from WarehouseOperator
  outcomes {
    ShipmentStarted
    ShipmentBlocked
  }
  events {
    emits ParcelDispatched
  }
  effect DispatchParcel
  when {
    DispatchParcel unresolved then ShipmentBlocked
    otherwise then ShipmentStarted
  }
}

capability FulfilOrder {
  intent OrderInput from Customer
  outcome FulfilmentOpened

  when {
    always then FulfilmentOpened
  }

  supervises lifecycle OrderFulfilment {
    identity orderId

    contributors {
      ReserveInventory
      CapturePayment
      ShipOrder
    }

    begin Created

    step Created

    step AwaitingPayment {
      waits for outcome PaymentCaptured from CapturePayment
      waits for outcome PaymentDeclined from CapturePayment
    }

    step ReadyToShip requires decision from WarehouseOperator

    step Dispatching waits for event ParcelDispatched from ShipOrder

    end Completed
    end Failed

    move Created to AwaitingPayment
      on outcome InventoryReserved from ReserveInventory

    move Created to Failed
      on outcome InventoryUnavailable from ReserveInventory

    move AwaitingPayment to ReadyToShip
      on outcome PaymentCaptured from CapturePayment

    move AwaitingPayment to Failed
      on outcome PaymentDeclined from CapturePayment

    move ReadyToShip to Dispatching
      on outcome ShipmentStarted from ShipOrder

    move Dispatching to Completed
      on event ParcelDispatched from ShipOrder

    move ReadyToShip to Failed
      on outcome ShipmentBlocked from ShipOrder
  }
}

Observation

Observations declare metrics and trace points derived from language semantics. They can count outcomes, effects, events, failures, violations, durations, and lifecycle transitions.

Observation declarations are not runtime vendor configuration. They are semantic instrumentation requirements that generated artifacts or runtime projections can use later.

Compiler Diagnostics

The compiler is responsible for semantic correctness, not just syntax. It emits errors for invalid programs and warnings for valid but risky or suspicious programs.

Reference Sources

This page is distilled from the repository design documents for primitive contracts, surface syntax, compiler duties, context visibility/dependencies, policy composition, supervising lifecycles, lifecycle completion semantics, and the accepted v0.9 syntax decision record.