Designing Edict: a policy language for AI
Jun 5, 2026 · 8 min read
Governance that lives in a document can't be enforced. Here's how we designed a declarative language so a control is the runtime, not a recommendation.
Every governance product eventually faces the same fork: configuration or language. Configuration is easy to ship and impossible to reason about once you have more than a dozen rules. A language is harder to build and the only thing that scales to an enterprise's real policy surface.
We chose a language. Edict expresses governance as declarative policy - versioned, reviewed, and tested like any other code. A policy binds to a principal, denies or redacts specific classes of data, scopes which tools an agent may call, and escalates ambiguous cases to a model-graded review. The same artifact that an engineer reviews in a pull request is the artifact that runs in the request path.
The design constraint we kept returning to: a policy must be explainable. When DataStrict blocks a request, an auditor should be able to read the exact rule that fired and the exact finding that triggered it. That rules out opaque scoring as the primary mechanism - determinism first, models only where the rules genuinely can't decide.
We'll open the grammar over the coming releases. For now, the shape of a policy and how it's adjudicated lives on the control layer page - and the same example renders, enforcing, in the product.
Further reading
