This paper is written for the people who own how AI gets built. The Chief AI Officer who sets the policy, the platform leader who owns the pipeline, the engineer who ships the model, and the governance lead who has to prove the rules are followed. It answers one question. When your AI policy states a rule, does anything in the build actually stop a violation, or is the rule only a sentence someone was meant to remember.
Executable Policy, Shelf Policy, Enforcement Coverage, the Policy Pipeline, and Build-Time Policy are original constructs of this work, published under the license on the back cover. They build on prior work on enforcement points [4] and on published research into how development-stage failures and documentation behave [1][2][3]. Every quantitative claim is cited to a named source or labeled directional, without exception.
Every enterprise AI program I meet has a policy. A document, often a good one, that says what the organization will and will not do with AI. Almost none can show me where, in the act of building a model, that document actually stops anything. The policy exists. The enforcement does not.
A rule that an engineer has to remember, at the moment they are moving fast to ship, is a rule that fails. Not because people are careless, but because memory is not a control. The data gets used, the model gets trained, the system gets deployed, and the only thing between the written rule and a violation is whether someone recalled the right sentence at the right line of code.
This paper is my answer to the question I now ask in every governance review. Not whether you have a policy, everyone does, but whether your policy runs. Whether each rule that matters is wired to a check inside the pipeline that applies it without being asked. The constructs are original work. The numbers are cited or labeled directional, without exception. I hold this to the standard of the rooms it will be read in.
Most AI policy is written to be filed, not enforced. It names the right rules, assigns the right owners, and then sits beside the work instead of inside it. The gap between what the policy says and what the build actually stops is the subject of this paper. Five findings follow.
A policy an engineer has to remember is a policy that fails. Most AI development policy is Shelf Policy. Written, owned, and wired to no check, so at the moment the work happens it stops nothing. Memory is not a control.
The failures are the kind a check catches. Data leakage alone affected 294 papers across 17 fields [1], and the fix the authors proposed was a standardized check that makes the flaw visible. Documentation standards exist for the same reason. model cards for the trained model [2] and datasheets for the data [3] are development stages asking for an artifact that can be inspected, not a promise.
Policy only governs if it is executable. Executable Policy is policy expressed as checks that run inside the pipeline, applied by the system, not recalled by a person. The measure is Enforcement Coverage, the share of clauses with a live enforcement point.
Enforce at build time, not in the audit. A violation caught at the data stage is a warning. The same violation caught after it ships is an incident. Build-Time Policy moves the check to where the work is, so the rule is applied before the cost is paid.
You can wire it in one quarter. Map the clauses to the pipeline, turn the testable ones into checks, and raise Enforcement Coverage on the highest-severity clauses first. The work starts with an inventory of which rules are enforced and which only exist on paper.
Ask an AI team to show you their policy and you get a document. Ask them to show you where that document stops a violation during development, and most cannot. The data-use rule lives in a file the ingestion pipeline has never read. The fairness commitment is a paragraph the training job does not reference. The policy and the work occupy different worlds, connected only by an engineer's memory of what the rule was.
This is not hypothetical. When a class of error has no enforced check, it spreads. Data leakage, a flaw that inflates results by letting a model see what it should not, was found across 294 papers in 17 scientific fields [1]. The fix the authors proposed was not more policy. It was a standardized check that makes the flaw visible before the result is trusted. The same logic produced model cards [2] and datasheets [3], the development stages demanding an artifact that can be inspected rather than a promise that can be forgotten.
A policy is not a control until something in the build refuses to proceed when the rule is broken.
Each of those failures is the kind a single check in the pipeline would stop. Exhibit 2 shows how much of a typical policy has such a check, and how much does not.
Shelf Policy is not one failure. It is six recurring ways a written rule never reaches the work. Each is common, each is fixable, and each is closed by wiring the rule to a check in the Policy Pipeline of Section 03.
A policy statement wired to no check anywhere in the pipeline. It is true on paper and absent in the build.
Written so vaguely it cannot be turned into a check. Use data responsibly is a value, not a test a pipeline can run.
Checked after the fact in a review, not at build time, so the violation has already shipped by the time anyone looks.
A check exists but only warns, never blocks. Under a deadline, a warning that stops nothing is a warning that is ignored.
The check no longer matches the current policy, so it passes work the rule now forbids and reports green while doing it.
A stage of the pipeline with no checks at all, so whatever policy should apply there simply never reaches it.
Executable Policy has one architecture. Take the development pipeline you already run, name its stages, and put an enforcement gate at each one. A gate reads the clauses that apply to its stage and refuses to pass work that breaks them. The share of clauses with a live gate is your Enforcement Coverage.
| Stage | What policy it enforces | The gate, in practice |
|---|---|---|
| Data | Provenance, consent, no leakage, handling of sensitive fields | A data contract test that blocks unapproved or leaking sources |
| Train | Approved data only, logged configuration, reproducibility | A build gate that fails on unregistered data or an unlogged config |
| Evaluate | The accuracy bar, safety and robustness thresholds | A threshold test that fails the run when it falls below the bar |
| Deploy | Complete documentation, named sign-off, scope of use | A release gate that requires a filled model card and an approval |
| Operate | Monitoring, drift limits, access to the running system | A runtime guard that flags drift and enforces who can call it |
The gates do not replace judgment, they carry it. A human still decides what the rule should be and what threshold counts as passing. The pipeline applies that decision every time, without waiting to be asked, so the rule holds on the busiest release day as firmly as on the day it was written. A clause with no gate is the Shelf Policy of tomorrow.
The economics of policy are the economics of when the check runs. A rule enforced at the data stage stops a violation while it is still cheap to fix. The same rule left on the shelf lets the violation travel through training, evaluation, and release, picking up cost at every step, until it surfaces as an incident with a customer or a regulator attached. The question is never whether you pay to enforce a rule. It is whether you pay a little, early, or a lot, late.
You do not wire every clause at once. You start by finding which rules are already enforced and which only exist on paper, then you give the highest-severity shelf clauses a gate. The first phase is an inventory, because you cannot raise coverage you have never measured.
Enforcing everything equally wastes effort on rules that rarely matter and underprotects the ones that do. Four variables place any clause on one of four enforcement postures.
Can the clause be expressed as a check a pipeline can run? If not, it stays a documented rule.
Does a violation cause irreversible or high-stakes harm? Severity decides whether a gate must block.
How often is the clause touched in development? The more often, the more a standing gate earns its keep.
Can a violation be caught and undone cheaply later? The harder to undo, the earlier the check must run.
The through line is simple. A rule you cannot test stays documented and owned. One you can test, that is costly to get wrong and touched often, earns a blocking gate at every stage. Match the posture to the clause, and you spend enforcement where a violation would hurt.
Executable Policy is policy expressed as checks that run. Enforcement Coverage is the share of clauses with a live check. What is left is Shelf Policy, and it binds nothing.
| Probe | Question | Yes | No |
|---|---|---|---|
| 1 MAP | Can you list every clause in your AI policy and say which are enforced? | ||
| 2 SHELF | Do you know your Enforcement Coverage, the share wired to a live check? | ||
| 3 DATA | Does a check block unapproved or leaking data before training? | ||
| 4 TRAIN | Does the build fail on unregistered data or an unlogged configuration? | ||
| 5 EVAL | Does a run fail automatically when it falls below the safety or accuracy bar? | ||
| 6 DEPLOY | Is a complete model card and a named sign-off required to release? | ||
| 7 BLOCK | Do your high-severity checks block the work, not just warn about it? | ||
| 8 SYNC | When the policy changes, do the checks change with it? | ||
| 9 BUILD | Are violations caught during development, not in a later audit? | ||
| 10 OWNER | Does every clause have an owner who confirms its check still matches intent? |
The Executable Policy Index places you on the Policy Pipeline of Section 03. The stage you land on is the stage to finish before you climb.
This paper is a conceptual contribution. Executable Policy, Shelf Policy, Enforcement Coverage, the Policy Pipeline, and Build-Time Policy are original constructs of this work. They apply published findings about how development behaves, that an unchecked flaw spreads widely when nothing enforces against it [1], and that the development stages are better served by inspectable artifacts than by promises, which is why model cards [2] and datasheets [3] exist. They build on prior work that named enforcement points, the specific places a system applies a rule [4].
Every exhibit is marked. Solid fill is cited data. Hatched fill is directional illustration, shown to make a mechanism legible, not to assert a measured value. Red marks unenforced policy. The one hard figure in the paper, the spread of a single unchecked flaw, is cited to a named study [1].
Arjun Jaggi, Executable Policy, Enterprise AI Research, White Paper No. 07, arjunjaggi.com, November 2026.
Arjun Jaggi writes and advises at the intersection of enterprise AI strategy, governance, and the engineering that makes policy real. His work turns the hardest questions of running AI at scale into named frameworks that a board can decide on and a team can execute. Engage at arjunjaggi.com.