Roadmap
Current, next, later, and not-planned direction for Edictum runtime governance.
Right page if: you want the current public truth about what Edictum ships today, what is next, what is later, and what is not planned. Wrong page if: you need setup or API details -- use the surface-specific docs directly. Gotcha: runtime governance is the product center. The reference API/app stack is optional and does not make runtime decisions for agents.
This roadmap tracks public product direction, not every historical plan.
Edictum is runtime governance for AI agents. The product center is the runtime path: an attempted action becomes a decision, the decision allows, blocks, asks, warns, or redacts, and the decision is recorded.
Now
These surfaces are current public docs and shipped or actively documented behavior.
Runtime Decisions
- Pre-tool decisions before side effects happen
- Decision actions for
allow,block,ask,warn, andredact - Principal-aware evaluation
- Side-effect aware postcondition behavior
- Structured block reasons
- Dry-run evaluation for would-allow and would-block checks
Rulesets And Policy-As-Code
- Shared
kind: Ruleset/rules:YAML format across Python, TypeScript, and Go - Rule types:
pre,post,session, andsandbox - Operators and variable interpolation
- Built-in templates and reusable patterns
- Schema validation through the CLI and SDK loaders
- Observe mode for shadow testing rules before enforcement
Workflow Gates
kind: Workflowdocuments with ordered stages- Stage tool allowlists and glob patterns
- Entry, check, and exit conditions
- File-read, command, approval, and MCP-result evidence
- Terminal stages
- Workflow snapshots in decision records
- SDK setup paths are documented for Python, TypeScript, and Go, but full Workflow Gates parity is not claimed across all helpers and condition behavior. Verify the SDK version before relying on a specific workflow feature.
Human Approval Gates
askdecisions- Local and server-backed approval backends
- Approval timeout behavior that fails closed
- Approval records in the optional reference API/app stack
- Telegram interactive approval path
- Slack, Discord, and webhook notification channels as one-way notifications today
Audit, Evidence, And Reporting
- Structured audit events for decisions and execution outcomes
- Local audit sinks
- OpenTelemetry spans and metrics
- Server-backed event ingestion in the optional reference stack
- Run, session, principal, ruleset, and adapter correlation where the runtime supplies it
Replay And Blast-Radius Preview
- CLI replay for captured events
- Would-block analysis through observe and replay workflows
- Ruleset version history in the optional reference stack
- Server-side replay endpoint for ruleset comparison
SDKs And Framework Adapters
- Python SDK:
edictum - TypeScript SDK:
@edictum/core - Go SDK:
github.com/edictum-ai/edictum-go - Python adapter docs for LangChain/LangGraph, OpenAI Agents, Claude SDK, CrewAI, Google ADK, Semantic Kernel, Agno, and Nanobot
- TypeScript adapter docs for Vercel AI SDK, Claude Agent SDK, LangChain.js, OpenAI Agents SDK, and OpenClaw
- Go adapter docs for Google ADK Go, LangChainGo, Eino, Anthropic SDK Go, and Firebase Genkit
Gate CLI And Coding Assistants
- Canonical Go CLI
edictum validate,edictum check,edictum diff,edictum replay,edictum test, andedictum skill scanedictum gate init,gate run,gate check,gate status,gate audit, andgate sync- Local WAL for audit buffering
- Skill scanner docs
Reference API/App Stack
- Hosted beta at
app.edictum.aiandapi.edictum.ai - API keys, runs, agents, rulesets, events, approvals, audit feed, and notification channels
- SSE hot reload for server-backed rulesets
- Ruleset signing server-side
- Sample run and current API reference
The reference stack is optional. Enforcement still happens in the SDK runtime or Gate runtime.
Security And Compliance Starters
- Fail-closed behavior
- Defense-scope docs
- Adversarial testing guidance
- Secret redaction and data-protection patterns
- Destructive command and change-control patterns
- Compliance mapping as support material, not the headline
Next
These are the near-term cleanup and product-direction items.
- Keep docs, package metadata, examples, and repo READMEs aligned around runtime governance
- Expand
/docs/featuresinto deeper links as each feature page matures - Add a public-safe operational-agent pattern guide
- Add decision telemetry reference docs for audit, event, and OpenTelemetry attributes
- Add an OWASP Agentic starter controls page under security
- Improve ruleset inheritance and overlay docs when the SDK surface is ready to present publicly
- Tighten SDK parity tables so adapter support is explicit by language
- Improve replay examples around blast-radius preview before promoting stricter rules
- Clarify signed ruleset and decision-bundle proof flows as implementation stabilizes
Later
These are plausible directions but not current public promises.
- Saved blast-radius summaries grouped by tool, principal, run, and ruleset version
guard.summary()for local run summaries- Reporting query recipes and SQL sink guidance
- Signed decision bundle download from the reference stack
- More workflow conformance fixtures across SDKs
- Additional adapters where the underlying framework has stable hook points
- Self-hosting guidance for the reference API/app stack only when the public path is real and supportable
Not Planned
These are not current product promises.
- Making the hosted app the product center
- Moving runtime enforcement into the reference API/app stack
- Treating Workflow Gates as the whole product
- Claiming adapter parity where the SDKs do not actually match
- Reintroducing legacy ruleset syntax
- Public self-serve Stripe pricing in docs before the shipped billing path exists
- Public Docker Compose, Railway, or Render setup for the reference stack before there is a maintained public path
- Positioning Edictum as a broad AI governance platform instead of runtime governance for AI agents
Source Of Truth
Use the feature and surface-specific docs for implementation details:
Last updated on