ACDL is designed to be consumed by an operational runtime.
That runtime may be ACE, or another engine specialized for software systems, robotics, logistics, infrastructure, or other domains.
Parse ACDL
|
v
Build system graph
|
v
Start roles, units, and listeners
|
v
Register workflows, policies, and metrics
|
v
Begin execution
System
|
|- Units
| |- Intake
| |- Planner
| '- Dispatch
|
|- Roles
| |- Classifier
| |- Planner
| '- Executor
|
|- Tools
| |- Retrieval Tool
| '- Actuation Tool
|
|- Capabilities
| |- Classify Request
| |- Generate Plan
| '- Execute Plan
|
|- Workflows
| '- Fulfillment Workflow
|
'- Governance
|- Policy
'- Kill Switch
A runtime should:
- parse each Markdown definition
- validate required fields and references
- build a connected system graph
- start execution loops based on schedules and subscriptions
- register event listeners and routes
- apply governance policies and kill-switch rules
- expose KPIs for monitoring and optimization
ACDL is most powerful when the specification layer is stable and the runtime layer is pluggable.
That means the same ACDL concepts can be mapped into different execution environments:
- ACE for Cairo-native agentic systems
- robotics runtimes for embodied systems
- infrastructure runtimes for deployment systems
- simulation runtimes for testing and modeling
This separation is what allows ACDL to be both expressive and portable.