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.
Hello World
The smallest useful model names an actor, an input shape, a capability, an outcome, and unconditional outcome causation.
language dcl 1.0
actor User is human
shape GreetingInput {
name: Text required
}
capability SayHello {
intent GreetingInput from User
outcome GreetingPrepared
when {
always GreetingPrepared
}
}
Expected outcome: GreetingPrepared.
Key concepts: actor, shape, intent, outcome, always.
Register Customer
Registration demonstrates a rule, ordered effects, an emitted event, and outcome selection for rejection, deferral, and acceptance.
language dcl 1.0
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
}
}
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.
language dcl 1.0
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
}
}
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.
language dcl 1.0
actor Operator is human
effect PublishInvoice is notification
effect PersistInvoice is persistence
policy InvoiceExecution {
performance {
throughput above 100 per minute
}
governance {
audit required
evidence required
}
confidence {
threshold 0.9
}
}
policy InvoiceSecurity {
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 {
InvoiceExecution governs capability
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
}
}
Expected outcomes: InvoiceAccepted or
InvoicePublishDeferred.
Key concepts: policy family, governance targets, observation metrics.
Agentic Customer Support
Agentic support models a support agent, tool-use effects, confidence thresholding, escalation, and a local support-question lifecycle without introducing model/provider/runtime semantics.
language dcl 1.0
actor Customer is human
actor SupportAgent is agent
actor CRMSystem is system
shape CustomerQuestion {
customerId: Uuid required
question: Text required
}
shape AnswerDraft {
customerId: Uuid required
answer: Text required
confidence: Number required
}
shape EscalationRequest {
customerId: Uuid required
reason: Text required
}
shape KnowledgeSearchResult {
summary: Text required
source: Text required
}
effect SearchKnowledgeBase is tool
effect CheckCustomerAccount is tool
effect CreateSupportTicket is invocation
effect NotifyHumanSupport is notification
event CustomerQuestionAnswered is AnswerDraft
event SupportQuestionEscalated is EscalationRequest
policy MinimumAnswerConfidence {
confidence {
threshold 0.8
}
}
policy SafeToolRetry {
reliability {
retry {
attempts 2
backoff exponential
}
idempotency required
}
}
policy AuditSupportAnswer {
governance {
audit required
evidence required
}
}
capability AnswerCustomerQuestion {
intent CustomerQuestion from SupportAgent
outcomes {
AnswerPrepared is AnswerDraft
Escalated
InsufficientConfidence
ToolUnavailable
}
effects {
SearchKnowledgeBase
CheckCustomerAccount after SearchKnowledgeBase
}
events {
emits CustomerQuestionAnswered
}
policies {
MinimumAnswerConfidence governs outcome AnswerPrepared
SafeToolRetry governs effect SearchKnowledgeBase
AuditSupportAnswer governs outcome AnswerPrepared
}
when {
SearchKnowledgeBase failed then ToolUnavailable
CheckCustomerAccount failed then Escalated
policy MinimumAnswerConfidence fails then InsufficientConfidence
otherwise then AnswerPrepared
}
lifecycle {
begin Received
step Investigating
step Answered
step Escalated
end Resolved
move Received to Investigating on outcome AnswerPrepared
move Investigating to Answered on event CustomerQuestionAnswered
move Investigating to Escalated on outcome Escalated
move Answered to Resolved on event CustomerQuestionAnswered
move Escalated to Resolved on event SupportQuestionEscalated
}
}
capability EscalateSupportQuestion {
intent EscalationRequest from SupportAgent
outcomes {
EscalationCreated
EscalationRejected
}
effects {
CreateSupportTicket
NotifyHumanSupport after CreateSupportTicket
}
events {
emits SupportQuestionEscalated
}
policies {
SafeToolRetry governs effect CreateSupportTicket
}
when {
CreateSupportTicket failed then EscalationRejected
otherwise then EscalationCreated
}
}
Expected outcomes: AnswerPrepared,
InsufficientConfidence, ToolUnavailable, or
EscalationCreated.
Key concepts: agent actor, tool effects, confidence policy, escalation lifecycle.
Context / Multi-file Example
Contexts let one area of the model depend on shared declarations owned by another context. Compile both files together.
language dcl 1.0
context Shared {
actor Customer is human
shape SharedOrderInput {
orderId: Uuid required
customerId: Uuid required
}
event SharedOrderSubmitted is {
orderId: Uuid required
}
}
language dcl 1.0
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.
language dcl 1.0
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 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
}
}
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.
language dcl 1.0
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 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
}
}
Expected outcomes: PaymentRequested or
PaymentExpired.
Key concepts: local lifecycle ownership, event waits, deadlines, terminal states.