Policy as Code and Release Decisions
How evidence, policy and accountability converge into a decision somebody owns.
Policies tend to fail at the point where prose meets a pipeline.
Consider a policy that reads: high-risk agents require human oversight. It is correct, and no deployment system can act on it. Written in a form a gate can evaluate, the same requirement becomes something else entirely.
IF risk_tier = high
AND required_signoff != approved
THEN BLOCKThis does not mean every ethical judgment becomes an if-statement. It means the parts that can be explicit should be executable and versioned, and human judgment stays exactly where the policy puts it — with a record that it happened.
What an executable policy has to state#
Eight elements cover most cases: the scope it governs, the thresholds an agent must meet, which breaches block rather than review, which controls must be passing, which roles sign off and who may not, how long evidence stays valid, how an exception is recorded and expired, and the policy’s own version and effective date.
That last element is easy to omit and awkward to be without. A reviewer needs to know not only what evidence existed but which rule set turned it into a decision.
What that looks like in practice#
A ProofAgent governance profile declares the agent’s risk context and lets a deterministic classifier derive the rest — the tier, the obligations, the frameworks in scope, and the guardrails.
agent_governance_profile:
name: "Vendor Payment Exception — production"
fail_on: block
intake:
use_case: creditworthiness
autonomy_level: L3
data_sensitivity: pii
region: eu
human_oversight: false
takes_consequential_actions: trueSix answers produce a high-risk tier with its reasons attached, a minimum score, a blocking severity, a sign-off requirement, a re-evaluation cadence, and the frameworks that apply.
The platform-side profile is more granular, and its shape is worth copying whatever tooling you use.
| Element | Example | Read as |
|---|---|---|
min_final_score | 8.5 | overall floor |
min_<metric> | min_safety: 9.0 | per-metric floor |
hard_metrics | ["safety"] | a breach here blocks; others review |
block_rules | phantom_tool_call, pii_leak, unsafe_action | finding types that block |
block_severity | critical | the severity at which those rules bite |
review_severities | ["high", "critical"] | findings that force review |
max_metric_regression | 1.5 | tolerated drop against the baseline |
Read in plain terms: require 8.5 overall, require safety at 9.0 and treat a shortfall there as a block rather than a review, send a low tool-use score to review, and block outright on any critical phantom tool call, personal-data leak, or unsafe action.
One enterprise-wide threshold is almost never right. Inheriting a baseline and adding requirements as risk rises — more adversarial turns, stronger context thresholds, mandatory controls, shorter freshness windows, additional approvers — is what turns a risk tier from a label into a constraint.
Because a policy is production logic, it deserves test cases: given this evidence package, expect a pass; given a critical control failure, expect a block; given a missing approval, expect a review. Determinism is what makes that possible, and a gate whose rule ordering varies cannot be tested or explained afterward.
The gate, and the three things it can say#
A release gate has one job: turn evidence and policy into a recorded decision.
A PASS means the required evidence and controls satisfy the release policy — for this version, this environment, this user population, this data class, this tool set. It is not a certificate that the agent cannot fail, and a PASS for a pilot does not authorize enterprise deployment.
A REVIEW means the policy requires human judgment. A named person with authority accepts a stated residual risk, in writing, with an expiry. It is neither a failure nor a formality.
A BLOCK means a release condition failed. The block names the exact reason and the remediation or missing evidence that would clear it.
Underneath, the ProofAgent gate engine evaluates five checks and takes the highest outcome, where BLOCK beats REVIEW beats PASS.
| Check | Triggers when | Outcome |
|---|---|---|
| Block rule | a listed finding type occurs at or above the blocking severity | BLOCK |
| Overall threshold | the final score is missing or below the floor | BLOCK |
| Metric threshold | a per-metric score is missing or below its floor | BLOCK if the metric is hard, else REVIEW |
| Severity findings | any finding sits at a review severity | REVIEW |
| Regression | a metric dropped against the baseline beyond tolerance | BLOCK if configured, else REVIEW |
Three details decide whether the gate can be trusted. Missing scores are treated as below threshold, so the gate fails closed rather than open. Severity is ranked rather than compared as text, so an unrecognized value ranks lowest and a typo cannot promote a finding. And every check that fired is recorded with a machine-readable key and a human-readable reason, because that list is the evidence behind the decision.
A decision is a record, not a status light#
Four properties make a release decision useful months later. It is scoped, naming the environment, population, data classes, and tools it authorizes. It is versioned against the agent version, the composition record, and the policy. It is evidence-backed, linked to the run that qualified it. And it is recorded with requester, approver, role, timestamp, notes, and the rule that fired.
For higher-risk agents, separation of duties means the builder cannot be the sole approver, and the system should enforce that rather than trusting it.
Two more things belong in the record. Exceptions, which real organizations need — an incident forcing temporary use outside the cadence, a control partly satisfied with compensating safeguards, a pilot approved for a limited population — recorded with an owner, a scope, an expiry, and a follow-up, so that they return to review automatically rather than persisting quietly. And the reversal path: how to remove credentials, disable tools, revert a model or prompt, restore a prior version, together with how long that actually takes when somebody tries it.
The test worth applying to the whole arrangement is simple. Could an independent reviewer reproduce the reason this exact agent version was allowed to operate on the day it was released?
A release decision should always be traceable to the evidence and policy that produced it.
Convert your release intent into rules a gate could execute, then test the reversal path. Both are quick, and both tend to reveal that the current process depends on somebody remembering something.