Core vs Control Plane
Workflow Gates and enforcement live in the SDKs. Control Plane is an optional server surface for ruleset delivery, approvals, and event visibility.
Right page if: you are deciding whether you need the optional control-plane/server layer in addition to the SDKs. Wrong page if: you need the actual workflow format -- see https://docs.edictum.ai/docs/reference/workflows or https://docs.edictum.ai/docs/guides/workflow-gates. Gotcha: Workflow Gates do not run in Edictum Control Plane. They run in the SDK runtime.
Edictum is workflow-first now. The SDKs are the product. Control Plane is optional.
Core SDKs
The SDKs do the real enforcement work:
- rulesets
- Workflow Gates
- local approvals
- audit sinks
- adapters
No server is required to enforce behavior. That includes kind: Workflow.
Edictum Control Plane
Control Plane is a narrower, optional server surface:
- remote ruleset delivery
- centralized approvals for server-backed agents
- event feed and fleet visibility
- bundle/ruleset management
It does not implement Workflow Gates.
Workflow YAML stays local to the SDK runtime today.
Use this split
| Need | SDKs | Control Plane |
|---|---|---|
| Rulesets | Yes | Optional remote distribution |
| Workflow Gates | Yes | No |
| Tool-call enforcement | Yes | No |
| Local/offline use | Yes | No |
| Remote approvals and event feed | Optional | Yes |
| Fleet dashboard | No | Yes |
What to read
- Quickstart — get the core library running in 5 minutes
- Workflow Gates Runtime — runtime behavior and setup
- Workflow Reference — exact
kind: Workflowschema - Control Plane setup — only if you need the optional server layer
Last updated on