Skip to content

Latest commit

 

History

History
81 lines (66 loc) · 1.59 KB

File metadata and controls

81 lines (66 loc) · 1.59 KB

ACDL Runtime Model

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.

Execution process

Parse ACDL
  |
  v
Build system graph
  |
  v
Start roles, units, and listeners
  |
  v
Register workflows, policies, and metrics
  |
  v
Begin execution

Example system graph

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

What a runtime should do with ACDL

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

Runtime portability

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.