Treating AI governance as code means compiling policies into mechanical checks that run at the boundary of every build, instead of as documents a lawyer reviews after release. The CANONIC preprint formalizes the move by mapping governance axioms onto compiler-theory layers, then tests it with a pre-registered benchmark. The result is the part worth pausing on: structural admission keeps a record auditable, but it does not decide whether the content is any good.
How does CANONIC turn governance into a compilation step?
CANONIC reframes governance as a compiler’s well-formedness check: content either clears an admission grammar and enters the corpus, or it does not. The author reduces governance to three axioms (Triad, Inheritance, and Introspection) and maps each onto a layer of compiler theory, namely syntax, scope-resolution, and type system. Admission becomes a decidable, linear-time check rather than a judgment call, according to the paper’s abstract. The structural move is what matters here: governance stops being a memo a reviewer interprets and becomes a rule a machine applies at the point where an artifact is first admitted. Every claim that gets through is anchored to a definition, a commit, and an evidence window, which the author argues makes the record reproducible and checkable end to end.
What did the four-regime benchmark actually test?
CANONIC ran a pre-registered cross-provider benchmark across four regimes to ask one question: does structural admission keep slop out of a corpus? The answer the author reports is no. No prose-reading gate reliably separates reliable from unreliable content, because slop is not a property an algorithm computes; it is a verdict of domain expertise. That is the paper’s own framing, and it deserves weight, because it inverts the premise a lot of governance-tooling vendors sell. The mechanical layer CANONIC keeps is not a slop filter. It is an audit ledger.
The abstract does not report per-regime performance figures, so specific accuracy or false-admission numbers are not available from this source as of 2026-07-08. Anyone building on CANONIC should treat the headline conclusion as a preprint claim pending the per-regime results the paper links separately, rather than quoting a number that does not appear in the abstract.
Where do structural filters fail to catch slop?
The failure CANONIC documents is structural, not incidental. A grammar can decide whether a claim is anchored to a definition, a commit, and an evidence window. It cannot decide whether the claim is true, well-grounded, or responsibly scoped. A paragraph can satisfy every formal axiom and still be wrong, or right in a way that misleads. The author is explicit about this boundary: the governance layer “does not decide slop; it keeps the record auditable.”
This is where the compilation analogy earns its keep and then stops. A compiler that rejects malformed code is genuinely useful, because malformed code does not run. A governance compiler that admits only well-anchored claims does not guarantee the claims are good, only that they are traceable. That is real value for auditability. It is not the same as reliability, and conflating the two is the predictable failure mode for anyone who reads “governance is compilation” as “compilation is verification.”
What does compliance-as-a-build-step actually buy a platform team?
The honest payoff is audit cost, not correctness. If compliance is a check that runs mechanically at admission, it runs on every artifact, every time, at near-zero marginal cost. That collapses the economics of auditing, because a team no longer pays lawyer-hours to eyeball whether every published claim has a source; the build step refuses to ship claims that lack one. The Reg2Req pipeline points at the same cost frontier from the other direction. It automates the regulation-to-requirements translation that engineers still do by hand, identifying requirement-bearing clauses across the full GDPR (398 clauses) and EU AI Act (574 clauses) corpora with macro-F1 scores of 0.82 and 0.78 respectively, according to its authors.
What both pieces share is the bet that the expensive, manual, error-prone part of compliance can be mechanized. Reg2Req’s user study, with 25 practitioners, found plain-language explanations significantly improved comprehension of derived requirements and confidence in acting on them (p < 0.001). That is a comprehension result, not a correctness result, and the distinction matters the moment you hand the derived requirements to a build step. A team that trusts mechanically derived requirements owns the gap between “the practitioner understands the requirement” and “the requirement is the right one.”
What new defects does code introduce: version-skew and gaming?
Mechanical checks have mechanical failure modes. The two that matter for governance-as-code are version-skew and gaming, and both are worse than the human-review failures they replace because they fail silently and uniformly.
Version-skew is the drift between the compiled policy and the regulation it encodes. A regulation changes; the compiled grammar does not, until someone re-derives and ships it. Every build in the interim runs against a stale rule set and passes. Human review at least has a chance of someone noticing the regulation moved. A mechanical check passes the stale grammar with full confidence and a green build badge, which is harder to argue with than a memo. The policy-as-code precedent is already a well-trodden category, and the maintenance question of who re-derives the rule when the source regulation moves is exactly where those systems bleed. CANONIC’s differentiator is that it anchors every admitted claim to a definition, a commit, and an evidence window, which turns the ledger into something reproducible rather than a bare pass or fail.
Gaming is the second-order consequence of making admission mechanical. Once the gate is a grammar, the optimization target becomes “satisfy the grammar.” A producer who can attach a plausible definition, a commit hash, and an evidence window to any claim clears the check regardless of whether the claim holds up. The Reg2Req authors’ own human-rated correctness numbers, 3.74 and 3.54 out of 5 for GDPR and EU AI Act derived requirements, are a check on optimism: even the derived requirements land closer to adequate than to correct. A build that gates on mechanically derived, partially-correct requirements inherits that gap.
Which normative questions can a compiler not resolve?
CANONIC’s own benchmark lands the answer: reliability is a verdict of domain expertise, not a property an algorithm computes. The normative questions governance ultimately has to answer, whether a claim is responsible, whether a risk is acceptable, whether a deployment is proportionate, are exactly the ones that resist a mechanical check. A compiler can refuse an unanchored claim. It cannot tell you whether an anchored claim should have been made.
This is not a limitation unique to CANONIC; it is the boundary of the whole approach. The incident-governance literature reaches a compatible wall. A survey of existing AI incident governance frameworks, arXiv:2607.05163, finds those frameworks lack consistency in definitions, classification, monitoring, and reporting. That inconsistency is not a tooling gap you compile away. It is the absence of agreement on what counts as an incident, which is a normative question no grammar can settle. The people who want governance to compile have to first agree on what the grammar encodes, and that agreement is the hard, human, political work that precedes any build step.
Does governance-as-code undermine the human-review premise of the EU AI Act?
This is the question the angle raises, and it is the one place the brief cannot fully answer from primary sources. The premise, that high-stakes obligations under frameworks like the EU AI Act and ISO/IEC 42001 are met through human-reviewable process, is a claim about regulatory design. The sources here do not contain the primary statutory or standards text needed to assert it, so any statement that “the EU AI Act requires human oversight” should be pinned to that text before it is carried as fact rather than left as inference from a preprint’s framing.
What can be said from the sourced material is narrower. Reg2Req treats the EU AI Act as a 574-clause corpus and derives software requirements from it mechanically. If, in production, those derived requirements are wired into a build step that substitutes for human review, the question becomes whether mechanical satisfaction of a derived clause is the same obligation the regulation actually imposes. The Reg2Req correctness ratings, around 3.74 and 3.54 out of 5, suggest the derived requirements are not yet reliable enough to be load-bearing on their own. Until that gap closes, governance-as-code augments human review rather than replacing it, and anyone treating compilation as compliance should be explicit about which clauses they delegated and to whom the residual judgment accrues.
Where this leaves governance-as-code
The defensible version of CANONIC’s thesis is narrower than the title implies, and the author knows it. Governance can compile, in the sense that admission can be a mechanical, linear-time, reproducible check. It cannot compile in the sense of deciding what is true, because the paper’s own four-regime benchmark says it cannot. A platform team that adopts the approach gets a real win: every shipped claim is anchored, traceable, and auditable at near-zero marginal cost, and the slop question is pushed to the reviewer who actually has the domain expertise to answer it.
What it does not get is permission to delete the reviewer. The Reg2Req correctness numbers, the incident-governance definitional gaps, and the gaming pressure all point the same way: the mechanical layer is a ledger, not a verdict. Treat it as the build step that makes human review cheaper and more targeted, and it pays off. Treat it as the step that replaces human review, and you have shipped a compiler that passes well-anchored slop with a green badge.
Frequently Asked Questions
When is governance-as-code a poor fit for a compliance program?
It fits internal policies, which are deliberate guidelines meant to shape decisions and produce rational outcomes. It does not replace statutes that compel behavior, because a compiled grammar can enforce a policy but cannot by itself discharge a legal obligation.
How does CANONIC differ from OPA or Rego-style policy-as-code gates?
Rego-style checks typically emit a bare pass or fail. CANONIC treats the evidence ledger as the real output: every admitted claim is tied to a definition, a commit, and an evidence window, so the record is reproducible rather than a single boolean.
What should a team document before turning a policy into a build gate?
A complete policy needs scope statements, definitions, compliance and consequences sections, responsibilities, and effective dates. Omitting any of those gives the build step an incomplete contract that it will still enforce with full confidence.
Which Reg2Req metric should give teams pause before full automation?
Practitioners rated derived-requirement completeness near 4.5 out of 5, but correctness only around 3.74 for GDPR and 3.54 for EU AI Act requirements. The gap means a build gate can ship artifacts that look complete while still misstating the underlying obligation.
