EdictumRuleset Management
Remote ruleset delivery, version history, drift detection, and replay in Edictum Control Plane.
Right page if: you need the live control-plane surface for uploading rulesets, viewing version history, replaying events, or checking drift. Wrong page if: you need the YAML syntax for writing rules -- see https://docs.edictum.ai/docs/rulesets/yaml-reference. For hot-reload and agent sync, see https://docs.edictum.ai/docs/control-plane/concepts/hot-reload. Gotcha: the control plane stores and serves rulesets. It does not execute Workflow Gates.
Edictum Control Plane is the optional server layer for remote ruleset delivery, approvals, and fleet visibility. Agents still enforce rules locally; the server gives you upload, history, replay, and drift tracking.
What It Stores
The live backend stores versioned rulesets. Each deployed ruleset record includes:
| Field | Description |
|---|---|
name | Ruleset name, used by agents to subscribe and by the UI to group versions |
version | Monotonic version number |
yaml_content | Full YAML text |
revision_hash | SHA-256 hash of the YAML |
signature | Ed25519 signature of the deployed ruleset |
public_key | Public verification key |
deployed_at | Deployment timestamp |
deployed_env | Environment the ruleset was deployed to |
Ruleset Endpoints
The public API is ruleset-centric:
| Method | Path | Purpose |
|---|---|---|
GET | /v1/rulesets | List rulesets in the current workspace |
GET | /v1/rulesets/{name} | Fetch the current ruleset by name |
PUT | /v1/rulesets/{name} | Upload or replace a ruleset |
GET | /v1/rulesets/{name}/versions | View version history |
GET | /v1/rulesets/{name}/versions/{version} | Fetch one saved version |
GET | /v1/rulesets/{name}/current | Fetch the deployed YAML for the current environment |
GET | /v1/rulesets/{name}/replay | Replay events against a ruleset version range |
The UI uses the same data to render ruleset history, deployment status, and the diff view.
Upload Flow
Uploading a ruleset is simple:
- Author
rules.yamllocally. - Validate it with the core CLI.
- Upload it to
PUT /v1/rulesets/{name}. - The server stores a new version and pushes
rulesets.updatedover SSE.
That is the current public flow. There is no public rule library or composition API on the docs site.
Drift Detection
Agents report their current policy_version hash. The control plane compares that hash with the latest deployed ruleset for the agent's environment.
| Status | Meaning |
|---|---|
current | Agent hash matches the deployed ruleset |
drift | Agent hash differs and the agent is stale |
unknown | Agent did not report a ruleset hash |
Drift is visible on the fleet monitoring page, and agents pick up the latest ruleset on the next SSE reconnect.
Replay
Replay is the server-side way to compare a candidate ruleset against a baseline event window. The docs API exposes it at:
GET /v1/rulesets/{name}/replay
Use it to compare verdict changes before promoting a new version.
Current Control Plane Docs
Setup
Boot the optional server and create the first admin/API key.
Connecting Agents
Connect Python, TypeScript, or Go agents to the server-backed ruleset path.
Approvals
Track human review for action: ask.
Hot Reload
Watch agents sync the latest deployed ruleset over SSE.
Security
The control plane is a security-critical surface.
- Human auth: Clerk-backed operator traffic in the hosted app
- API keys: workspace-scoped and one-way hashed
- Workspace isolation: API reads and writes stay scoped
- Ruleset signing: server-backed rulesets can be signed and verified
- Fail closed: agents keep enforcing locally when remote coordination fails
Next Steps
Last updated on