One of the most important words in AI governance right now is “deterministic.” It means: given the same input, the system produces the same output, every time, without exception. A coin flip is not deterministic. A weather forecast is not deterministic. A fire suppression system is – and that is why you trust it.
The enforcement layer behind Ethosure achieves determinism through a technology called CEL – the Common Expression Language. Understanding what CEL is and why it matters is the key to understanding why Ethosure’s decisions are trustworthy.
What CEL Is…
CEL is an open-source expression evaluation language developed at Google and now part of the Cloud Native Computing Foundation. Think of it as a very precise, very fast calculator for yes/no questions about structured data.
A spreadsheet formula evaluates numbers and returns a result. CEL evaluates facts about an action and returns a policy decision. The formula `=IF(A1 > 100, “over budget”, “ok”)` is deterministic – every time A1 is 101, you get “over budget.” CEL works the same way, but the inputs are things like “the command being proposed,” “the file path being edited,” and “the list of staged files,” and the outputs are decisions like ALLOW, BLOCK, ESCALATE, or TRANSFORM.
CEL in the coding-ethos architecture
In the coding-ethos project, CEL sits in the control plane – the part of the system that decides what is allowed. The architecture assigns each role to the right tool:
Go collects facts. The Go programming language is used to gather structured information about an agent’s proposed action. When an agent wants to run a shell command, a Go program parses that command into its components – the binary, the arguments, the flags. When an agent proposes editing a file, Go reads the file’s current state and the proposed change. The result is a clean, typed set of facts.
CEL evaluates policy over those facts. The compiled policy bundle – a JSON file called `policy-bundle.json` – contains CEL expressions for each policy rule. When a Git hook or agent hook fires, it hands the collected facts to the CEL evaluator along with the applicable policy expressions. CEL evaluates each expression and returns a decision.
A concrete example: one policy checks whether a proposed shell command contains `–no-verify`, a flag that bypasses Git hooks. The CEL expression for this is essentially: “does the command argument list contain this string?” Given the facts for a command that includes `–no-verify`, the answer is yes, and the decision is BLOCK. Given facts for a command that does not include it, the answer is no, and that particular rule does not fire. Same logic, same policy, predictable result.
Why CEL must stay pure
The coding-ethos project has an explicit constraint on CEL that is worth understanding: CEL remains pure and deterministic. This means CEL expressions cannot read files from disk, make network calls, invoke external tools, or consult AI models. CEL receives structured facts and evaluates logical expressions over those facts. That is all.
This constraint is not a limitation – it is a guarantee. It is what makes the system auditable. If CEL could call an AI model to make its decisions, two things would happen. First, the same action could produce different decisions on different days, because AI models are probabilistic and can change over time. Second, you would lose the ability to explain a decision: “the model said so” is not an answer an auditor accepts.
By keeping CEL pure, every decision is explainable: “Action X was blocked because CEL expression Y evaluated to true given fact set Z.” Every component of that sentence can be inspected, logged, and reproduced.
This is why the coding-ethos documentation is explicit: “Probabilistic/embedding-based enforcement is explicitly disallowed in the enforcement path.” Embeddings and vector search exist in the system, but only for code-intelligence search features – never as the source of a policy decision.
How CEL interacts with the rest of the system
CEL does not operate alone. The full flow for a policy decision looks like this:
- An agent proposes an action – a command, a file edit, a Git operation.
- A Go evaluator collects structured facts about that action.
- The compiled policy bundle is loaded (it is a JSON file, not code).
- CEL evaluates the applicable policy expressions against the facts.
- The system returns one of four dispositions: ALLOW, TRANSFORM, ESCALATE, or BLOCK.
- The decision and its evidence are recorded in the evidence ledger as a SARIF finding and appended to the JSONL audit log.
The same CEL evaluation happens whether the action comes from a human developer committing code via a Git hook, or from an AI agent making a tool call that the agent hook intercepts. One policy bundle, one evaluation engine, one evidence format.
What this means for your compliance team
From a compliance perspective, CEL-based enforcement produces decisions that can be characterized precisely:
- Traceable: every decision points back to a specific policy ID, which points back to a specific engineering principle.
- Reproducible: given the same facts and the same policy bundle, an auditor can re-run the evaluation and get the same result.
- Version-controlled: policy bundles are versioned. If a rule changes, you know exactly when it changed and what the old rule was.
- Independent of the AI model: a new version of the underlying AI assistant does not change the policy decisions, because CEL does not involve the AI model in enforcement.
This last point matters enormously as AI providers update their models. Your controls do not drift when the model does.
