Examples

These examples are executable language assets. The source shown here is kept in website/src/examples and checked with the current DCL compiler before publication.

Flagship example: E-Commerce Platform

A multi-context example showing customer ordering, warehouse fulfilment, delivery, events, policies, and lifecycle progression.

Open the E-Commerce Platform example.

Open in Playground

Hello World

The smallest useful model names an actor, an input shape, a capability, an outcome, and unconditional outcome causation.

hello-world.dcl
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
  }
}

Open in Playground

Expected outcome: GreetingPrepared.

Key concepts: actor, shape, intent, outcome, always then.

Register Customer

Registration demonstrates a rule, ordered effects, an emitted event, and outcome selection for rejection, deferral, and acceptance.

register-customer.dcl
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
  }
}

Open in Playground

Expected outcomes: RegistrationAccepted, TermsRejected, or VerificationDeferred.

Key concepts: rule violation, effect ordering, event emission, fallback outcome.

Leave Request

Leave approval shows actor roles inside a capability and rules that refer to those roles and the input shape.

leave-request.dcl
language dcl 0.9

actor Employee is human
actor Manager is human

shape LeaveRequestInput {
  employeeId: Uuid required
  daysRequested: Number required
}

capability RequestLeave {
  intent LeaveRequestInput from Employee

  actors {
    requester: Employee
    approver: Manager
  }

  outcomes {
    LeaveRequested
    SelfApprovalRejected
    DurationRejected
  }

  rules {
    ApproverIsDifferent:
      actors.requester is not equal to actors.approver

    DurationWithinLimit:
      input.daysRequested is less than 21
  }

  when {
    ApproverIsDifferent violated then SelfApprovalRejected
    DurationWithinLimit violated then DurationRejected
    otherwise then LeaveRequested
  }
}

Open in Playground

Expected outcomes: LeaveRequested, SelfApprovalRejected, or DurationRejected.

Key concepts: actor roles, rule blocks, semantic rejection outcomes.

Policy Example

Policies attach operational concerns to a capability, effect, or event without naming a runtime implementation.

policy-example.dcl
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
  }
}

Open in Playground

Expected outcomes: InvoiceAccepted or InvoicePublishDeferred.

Key concepts: policy family, governance targets, observation metrics.

Context / Multi-file Example

Contexts let one area of the model depend on shared declarations owned by another context. Compile both files together.

context-shared.dcl
language dcl 0.9

context Shared {
  actor Customer is human

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

  event SharedOrderSubmitted is {
    orderId: Uuid required
  }
}
context-sales.dcl
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
    }
  }
}

Expected outcomes: SalesOrderAccepted or SalesOrderDeferred.

Key concepts: contexts, dependencies, visibility, shared ownership.

Supervising Lifecycle

A supervising capability coordinates contributors and moves a lifecycle forward based on contributor outcomes and emitted events.

supervising-lifecycle.dcl
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
  }
}

Open in Playground

Expected terminal states: Completed or Failed.

Key concepts: contributors, sourced outcomes, sourced events, lifecycle completion.

Payment Processing

Payment collection demonstrates a local lifecycle that waits for an event and uses a deadline to cause an expiry outcome.

payment-processing.dcl
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
  }
}

Open in Playground

Expected outcomes: PaymentRequested or PaymentExpired.

Key concepts: local lifecycle ownership, event waits, deadlines, terminal states.