Compile the Policy

Here is the artifact this whole series has been circling. A risk standard, the kind an examiner asks for by name, living as a document in a shared folder with its version typed into the footer. The last three edits arrived as email attachments. Nobody can run a test against it, because there is nothing to run. The enterprise calls this governance, and for the softest, highest-stakes artifacts it owns, this is genuinely the state of the art.

Infrastructure got a pipeline a decade ago. Architecture, as I argued in the last post, can have one now. The hardest domino, and the real payoff of the argument, is this one: the governance, risk, and compliance layer that regulators actually read. It is the artifact people assume can never be code, because it is prose and judgment and signatures. Most of it can. Here is what it looks like to compile the policy.

Authoring stays, the plumbing changes

Start by removing a fear. Nobody has to write policy in a code editor. The authoring stays in the tools the risk and compliance teams already use. What changes is where the authoritative copy lives and how it moves.

Today the source of truth is a shared drive, and the version is a social convention: a number in the footer, a suffix in the filename, a memory of who sent the latest one. Move that authoritative copy into a versioned store, and the version stops being something a human types and becomes something the system guarantees. The document a compliance officer opens is still a document. Behind it, quietly, is a history with a diff, an author, and a date attached to every change. That single move, off the shared drive and into version control, is the whole precondition. Everything else is what you can build once it is true.

The test stage is where it gets real

This is the part people think is impossible, and it is the part that matters most, so I want to be concrete. A software test asks a machine a yes-or-no question about an artifact and gets an answer without a human. The claim of this post is that a surprising amount of a risk standard can be asked that way.

Some of the questions are structural. Does every control in this standard map to a control in the enterprise catalog, or is there an orphan that governs nothing? Does every external citation still resolve, or is the standard pointing at a regulation that moved? Does the document carry the required sections a policy of its class must have? Those are checks a machine runs in seconds, and each one can fail the change before a human spends a minute on it.

Some of the questions are semantic, and this is where policy-as-code earns its place. The Open Policy Agent project exists to express rules as code and evaluate them against structured input, and its Rego language was built for exactly this shape of question: given a machine-readable description of a control, does it satisfy the rule. The reason this is now tractable for governance and not just for infrastructure is that the controls themselves are getting a machine-readable form. NIST’s OSCAL represents control catalogs, baselines, and assessment results as structured data instead of prose tables. Once a control is data, a policy engine can test it, and “is this standard internally consistent with the baseline it claims to implement” becomes a check that goes red or green.

And you run all of it in a throwaway environment, the way a test suite spins up a disposable container, evaluates, and tears down. The standard is rendered from source, the checks run against it in isolation, the result is recorded, the environment vanishes. Governance stopped being a review someone remembers to schedule and became a stage in a pipeline that runs on every proposed change.

Package, version, promote

A tested artifact still has to ship, and shipping a governance document has an exact analog to shipping code. Package it with an immutable version and publish it to a governed registry, the way a build publishes an artifact. The version now lives in the system of record, not in the footer, and “the current risk standard” is a specific, retrievable version rather than a best guess about which copy in which folder is authoritative.

Then promote it. Draft, review, approved, published, moving into the content system or control platform where the organization actually consumes it, with a human sign-off gating each transition that requires one. This is the part regulators care about most, and it is the part the pipeline serves best, because promotion through gates with recorded approvals is precisely what an audit trail is. The examiner’s question, who approved this and when, stops being an archaeology project and becomes a query against the promotion history.

Where model risk meets the pipeline

There is a reason to do this now rather than in a calmer decade, and it is the same engine the pillar named. Once governance artifacts are versioned, testable, and gated, an agent can draft the change, run the checks, and open the proposal, at a volume no human policy team could sustain. That is the opportunity. It is also the risk, because the thing generating the change is itself the thing hardest to govern.

I wrote in SR 11-7 Was Written for Models That Don’t Argue Back that classic model-risk validation assumes a fixed, deterministic function, and a generative agent breaks that assumption. The pipeline is part of the answer. The enforcement primitive is the gate that runs before the artifact takes effect, the validation hook that checks the change against policy the moment it is proposed, positioned on the trust ladder according to how much autonomy the change type has earned. An agent that can propose a policy edit is only safe if every proposal lands in the same tested, gated pipeline a human’s would, and nothing reaches the control system outside it. Enforcement, not enablement, is the phrase I keep returning to, and this is where it bites hardest.

The tax was always paying for this

There is an objection worth meeting head-on: this sounds like more compliance overhead, and regulated shops already drown in it. I have argued the opposite twice and will only reference it here. The friction of regulated work caps AI productivity at a real ceiling, and I made peace with that in The Compliance Tax. And in The Documentation Dividend I argued that the documentation compliance forces you to produce is a compounding asset, not dead weight. That documentation is exactly the machine-readable corpus this pipeline needs. The compliance burden was already making you write the controls down. Putting them under a governed lifecycle does not add the work. It finally collects the return on work you were already doing.

What the pipeline can’t decide

The honest limit, and it is the sharpest one in the series so far. Everything above handles the mechanical half of governance: consistency, mapping, citations, structure, provenance, approval. It does not handle the interpretive half. Whether a control is strong enough for the risk it covers, whether “should” should have been “must,” whether this standard actually protects the customer it claims to, none of that has a Rego rule that settles it. A policy-as-code check can prove a standard is internally consistent and still miss that it is confidently, coherently wrong.

That interpretive judgment stays human, and worse, the human review it needs was built for a pace that machine-generated change is about to overwhelm. That problem is large enough to be its own post, and it is the one coming next in this series. For now the claim is bounded and, I think, defensible: the risk standard in the shared folder does not have to stay there. Most of what makes it governance, the consistency and the mapping and the provenance and the gated approval, can be compiled, tested, and enforced like software. Point the pipeline you already run at the document you already have. The only genuinely hard part left is the judgment, and that was always yours to keep.

---

If this resonated, read SR 11-7 Was Written for Models That Don’t Argue Back, on why generative agents break classic model-risk validation, and The Domino That Already Fell, on the pipeline this post points at a governance document. Both sit in the Everything as Code series, under the pillar.

Find me on X @orestesgarcia or LinkedIn /in/setsero.