cd /news/ai-policy/governance-you-can-t-grep-isn-t-gove… · home topics ai-policy article
[ARTICLE · art-113786] src=dev.to ↗ pub= topic=ai-policy verified=true sentiment=· neutral

Governance You Can't Grep Isn't Governance

A developer detailed the creation of AIEOS, a governance framework that embeds AI development rules into machine-readable, CI-enforced pipelines, allowing validators to fail builds and approvals to be recorded as events. The framework, built over six months, moves governance from documents to code-level enforcement, addressing the challenge that AI code generators do not read policy prose.

read3 min views1 publishedAug 28, 2026

Earlier this month I clicked a button labeled Freeze, and a validator told me my artifact was conformant. One click, one status change, one machine-checked answer. It took me six months of building to earn that boring sentence.

This is the last post in a series that started in April with a blunt claim: AI doesn't fix your development problems, it accelerates them. Eight posts later I can compress everything the series argued into one line.

If your governance can't fail a build, it's advice.

Every post in this series turns out to be the same post. Measure AI delivery at the pipeline layer, because the vendor dashboard can't fail a build. Keep validators separate from fixers, because a judge that helps can't be audited. Treat the coding assistant like infrastructure, because infrastructure is the thing your controls actually attach to. Make approval an event with a name and a timestamp, because "somebody clicked merge" is not evidence.

Read them together and the pattern is hard to miss. Every one of those claims is about moving governance out of documents and into things a pipeline can evaluate.

I didn't plan that. I found it by writing.

Enterprises have governed software with prose for as long as I've been doing this: policy PDFs, wiki standards, review checklists, the CAB agenda. That worked, barely, because humans were the only generators and humans read prose. The generator isn't reading your wiki. It never will. The only governance a code generator can encounter is governance that lives where the code lives.

AIEOS started as two internal documents and a conviction: AI is a generation engine, not a decision-maker. The framework that grew out of it is my attempt to make the series' argument executable, and its shape follows directly.

The rules are content. 158 principles, 66 patterns and 111 practices, distilled from 45 sources, versioned in git like everything else. Nothing there is novel. What matters is where it sits.

The structure is machine-readable. Fifteen governance kits, one manifest (kit-manifest.yml

) that declares every kit, dependency edge, artifact flow and trigger condition. The console doesn't have opinions about the kits. It derives them from the manifest, all fifteen, at runtime.

The enforcement is CI. Conformance checks run from a shared workflow, and after July's audit (the green checkmarks were lying) they run with continue-on-error

banned and signing steps verified, because I learned the hard way that an unenforced check is worse than no check. It manufactures confidence.

And approval is an event. That Freeze click writes a Status: FROZEN

block into the artifact, a validator confirms conformance, and remediation after that point requires a new author clearing the same gate from the frozen baseline. Validators judge. They don't help. The maker-checker separation regulated industries have run for decades, now grep-able.

  Rules as content           kit-manifest.yml           Conformance CI
  (versioned in git)  --->   (machine-readable)  --->   (can fail the build)
                                                                 |
                                                                 v
      Production      <---   Approval event      <---   Frozen artifact
                             (named + timestamped)      (Status: FROZEN)

The whole framework in one line: rules the pipeline can read, checks that can fail, approvals that leave evidence.

The vendor decks skip this part.

A framework built and operated by one person proves the mechanics, not the sociology. I know the mechanics work because I rebuilt them after watching them fail silently for two months. I don't know what happens when 200 engineers meet the same gates, and anybody who claims to know is selling something.

And the ceiling question from last week's post stands. Governance as code makes review evidence computable. It doesn't tell you how many AI-generated changes per week your reviewers can absorb before the control becomes theater. I still don't have that number.

Five technology waves, thirty years, and the discipline never changed: know what's about to hit production and have a way to stop it. What changed is the only audience that matters for your rules. It used to be engineers. Now it's engineers and the machine generating alongside them, and prose only reaches one of those.

So write the rules where both can read them. Version them, gate on them, let them fail builds and leave timestamps.

Grep-able or imaginary. Pick one.

── more in #ai-policy 4 stories · sorted by recency
── more on @aieos 3 stories trending now
sponsored brought to you by zahid.host 4,200+ EU-deployed projects
reading about agents? ship yours in a single git push.

Run your AI side-project on zahid.host

EU-based hosting, git-push deploys, automatic HTTPS, no cold starts. Free tier with a custom domain — perfect for shipping the agent you just read about.

$git push zahid main
Live at https://your-agent.zahid.host
Get free account → Pricing
from €0/mo · no card required
LIVE [news/governance-you-can-t…] indexed:0 read:3min 2026-08-28 ·