Policy-as-code
Compliance and operational rules expressed as executable, versioned, testable code that enforces itself at runtime - rather than as a document nobody quite follows.
Policy-as-code means the rules a system must follow - content policies, data-access policies, escalation rules, human-in-the-loop thresholds - are code, not a PDF. Each policy is versioned, owned, tested in CI, and enforced at runtime as a pre- or post-inference check.
Why it replaces policy-as-PDF
A Confluence page describing what the system should do has no runtime effect. It drifts, it gets misread, and it doesn't survive staff turnover. Policy-as-code is the opposite: it enforces the rule on every call, tests the enforcement in CI, and produces an auditable record that the rule was applied.
What a policy-as-code stack usually contains
- A policy repo with named owners per policy.
- Runtime hooks - pre-inference filtering, post-inference validation, tool-call authorisation.
- Tests that deliberately try to violate each policy, and fail the build if the violation is not caught.
- A change process that requires compliance or risk review before a policy update ships.
Why governance becomes faster, not slower
The reflex objection is that policy-as-code adds friction. In practice it removes the conversations that used to block releases - "is this compliant?" is answered by the system itself. The CI run is the conversation. See the longer argument in Governance is a feature, not an appendix.