Governance-as-Code — the Gate That Gates Itself

The first version of the new gate contained an exemption for the code that told it what to check. A test fixture was easier to keep green that way. It also meant an agent could change part of the gate without triggering the very rule intended to protect it.

That is where this episode starts: with a useful control almost acquiring its own escape hatch.

The linkage that controls the gate belongs inside the protection boundary. Conceptual artwork.

Episode 14 followed the work to measure CI: where builds spent time, what counted as a change and how attribution reached the dashboard. This episode follows the next question—what should the pipeline accept from an agent-assisted development channel? The specification dates to Sunday 21 June 2026; the inspected implementation lands across Monday 22 and Tuesday 23 June. The work extends beyond the measurement weekend.

I owned the direction and review of the platform, with agents assisting with implementation and verification. The retained reports describe Codex implementation lanes and a separate Claude/Sonnet verifier. This is a curated reconstruction from those reports, the specification and historical source. It preserves their account of the review; it does not replay the original conversations or turn an agent’s report into an independent observation.

Keep useful changes moving

CI was already a bottleneck. I wanted changes to move through a lab I treated as production without letting the pressure for speed quietly erode its controls. The gate specification captures that engineering objective: keep the velocity and bound failure modes such as unattributed changes, oversized batches and agents weakening their own checks.

The work was tracked as VW-945 — OPA/Conftest LLM-channel contract gate (warn-then-enforce). It proposed a common policy layer for merge requests, with stricter conditions for recognised agent-authored changes. Human review remained part of the design. The new layer would make a few recurring review questions explicit and repeatable.

That distinction matters to how I judge the result. A policy engine does not discover the right governance model by existing. Someone chooses what facts it receives, which changes deserve additional review and what happens when evidence is missing. Those choices were the work.

The chosen tools were Open Policy Agent’s Rego language and Conftest. Rego expresses decisions over structured input; Conftest evaluates those policies against supplied data. In this case the data was a JSON description of a merge request, assembled from Git and any available risk artifact. The engine was small enough to inspect. Its input boundary deserved as much attention as its rules.

The flow below separates the policy verdict from the CI decision that could make it blocking. That separation explains why the first findings were useful even while the pipeline could stay green.

What the gate could actually see

The foundation was VW-962 — VW-945a: OPA/Conftest engine — policy/ scaffold + build_input.py + contracts:llm-gate CI job. Its historical merge is present on 22 June. The later source snapshot shows the input builder collecting a diff range, parsing attribution trailers, counting inserted and deleted lines, listing changed paths and inspecting the diff for coverage-floor changes.

This gave the policies concrete fields rather than a request to make an open-ended judgement about whether a patch looked safe.

The specification was broader than the delivered detector. It asked for protection against removed assertions and other ways of weakening CI. The inspected builder implements coverage-floor comparison and protected-path detection. I would not describe that as proof that it could detect every deleted assertion or weakened test.

There is a similar limit around agent identity. The delivered provenance policy recognises codex and claude-code. Other attribution outcomes do not acquire those checks merely because the design describes an agent channel. The mechanism can ask whether the provenance fields it receives are empty; it cannot establish that all agent work has declared itself honestly.

Those boundaries keep the story useful. They tell me where to improve the control, rather than letting the name “governance” stand in for coverage the code did not provide.

The fixture that changed the rule

The next slice was VW-963 — VW-945b: Three new contracts — provenance + diff-scope-cap + CI-weakening veto (Rego + tests). This is the review failure at the centre of the episode.

The implementation report describes two Codex lanes. The first added a special case for changes that only touched build_input.py. That kept an existing smoke fixture passing, but it exempted an input-builder edit from the CI-integrity contract. The verifier rejected it. The same review also found that checking only an empty string missed provenance fields that were absent altogether.

The report identifies a cause in the specification itself: it had insisted that the smoke fixture be preserved while asking for a rule whose intended behaviour changed that fixture’s result. The implementation satisfied the preservation constraint by weakening the boundary. That is an important failure in how the work was specified, as well as a bad change in the resulting code.

Repair the test's assumptions instead of creating an exception in the control. Conceptual illustration.

The second specification removed that conflict. It allowed the fixture to change and forbade the exemption. The revised fixture supplied the human co-author signal required for its control-file edit; a separate solo-agent edit had to keep producing a violation. Provenance used object.get so an absent field and an empty one both reached the missing-value check.

The final historical source includes the whole policy/ directory in the protected prefixes. That includes the builder itself. The CI-integrity rule then consumes the touches_ci fact without a builder-only carve-out.

ci_integrity_violation[msg] {
	input.touches_ci == true
	agent_authored
	input.has_human_coauthor == false
	msg = "agent-authored CI change requires a human coauthor"
}

The report says the verifier reconstructed the attack inputs: a solo input-builder change had to be denied, and a missing model key had to be denied. It records 17 passing Conftest tests. Re-running the retained revision during preparation also gives 17/17, with Rego v0 compatibility enabled. That independently checks the saved rules now; the original reviewer interaction remains a historical report.

The practical lesson is specific. When a new control changes an old fixture’s verdict, preserving the fixture is not automatically the right constraint. The expected result needs review. Otherwise a test can reward the very exemption the control was built to prevent.

The gate met its own merge request

The historical report describes the first real CI evaluation on the merge request introducing those contracts. It records two findings: the agent-authored change touched policy controls without the expected human co-author trailer, and the commit lacked session provenance.

These were policy denials, but the job was allowed to fail. The pipeline could remain green while the findings were retained. That is the first stage of warning in this story: a non-blocking CI job around rules that could emit denials. It is different from the later rules explicitly returning warnings under a per-contract mode.

The inspected CI configuration supports that distinction. It runs the builder, captures Conftest’s JSON and exit status, constructs a Markdown findings table, attempts to post it when a token and merge-request context are available, and retains the artifacts. It ends with the captured status while allow_failure: true makes the job non-blocking.

That is a useful feedback path, with an operational limit. The script permits a failed comment request and keeps a local artifact instead. Source inspection proves the attempted annotation path; the report supplies the account of the introducing run. I have not recovered that run’s raw job log or independently inspected its original posted comment.

The finding also exposed a mismatch in the policy model. Reviewing an agent’s merge request in GitLab did not add a co-author trailer to the commit. The human oversight the workflow cared about and the evidence the policy accepted lived in different places.

Calling that a false positive would skip the actual problem. The rule accurately evaluated its input. Its input did not represent the review event the design wanted to recognise. Before making it blocking, that gap needed a deliberate solution.

One condition, three modes

The final implementation slice carried the historical title VW-964 — VW-945c: Graduate pdg:risk-gate + warn-then-enforce wiring (Unleash flags + would-block counter). The title describes the intended scope. The implementation report is more limited: it delivered the mode mechanism and risk-routing contract, with infrastructure integration still deferred.

The input builder gained one environment variable per contract. It normalises each value, accepts off, warn or enforce, and falls back to warn for an absent or invalid setting. The Rego files use their own warn fallback when the modes object is absent.

def _contract_modes(env: Mapping[str, str] | None = None) -> dict[str, str]:
    environment = env or os.environ
    modes: dict[str, str] = {}
    for contract, env_name in _CONTRACT_MODE_ENV.items():
        mode = environment.get(env_name, "").strip().lower()
        if mode not in _VALID_CONTRACT_MODES:
            mode = "warn"
        modes[contract] = mode
    return modes

The batch-size contract needs one extra distinction. The soft limit is more than 800 changed lines or 25 files; it remains a warning even in enforce mode. More than 2,000 lines or 60 files crosses a hard limit. Those are strict greater-than comparisons, with insertions plus deletions counted as changed lines.

The fourth contract consumes a supplied high risk tier and the same co-author signal. It does not reimplement the dependency-risk analysis or identify a named reviewer. The report explicitly says the existing risk-gate implementation was untouched.

The report records a successful first lane for this slice after the mode matrix had been specified up front: 28 Conftest tests and 17 Python input-builder tests. During this reconstruction I reran the retained Rego suite and obtained 28/28. I have not rerun the original Python suite or GitLab pipeline. The local Conftest reports a development build with OPA 1.21.0; --rego-version v0 makes the historical syntax explicit, but does not reproduce CI’s pinned Conftest 0.56.0 binary.

The dial was installed; the rollout was unfinished

Observe the warning before relying on it to stop the machinery. Conceptual illustration.

The mode mechanism was real. An operational flag-controlled enforcement rollout was still ahead of it. The report lists three requirements before graduation: the Unleash flags and bridge that would export their state into CI, a Grafana would-block panel, and an accepted way to represent human approval.

A separate follow-up captured those remaining pieces: VW-993 — VW-945d: LLM-channel gate enforcement graduation — Unleash flags + CI env-bridge + Grafana would-block panel + human-approval encoding. The restored June snapshot marks that task Backlog and the three implementation children Done. Completing the engine, contracts and mode mechanism had not completed the enforcement rollout.

That changes the ending. The work did not establish that I could already flip an Unleash flag to make an agent policy block a merge. It established an environment-driven policy mechanism, defaulting to warnings, inside a job that still had allow_failure: true. Even a policy-level denial and a pipeline-level blocking decision were separate layers to wire deliberately.

The implementation report’s completion status and the follow-up ticket therefore describe different scopes. It does not complete every acceptance criterion in the original programme. There is no measured false-positive rate in the inspected evidence, no proof that the dashboard was counting would-block events and no demonstrated graduation to enforcement.

That is still a useful result. The first review had found a hole in the gate’s input boundary. The first reported evaluation had found missing provenance and an inadequate representation of oversight. The next implementation made policy behaviour explicit enough to test across modes. Each stage narrowed a different uncertainty.

What I would carry forward

The balance I wanted was safer delivery without making every useful iteration wait for a sprawling manual process. This work shows why achieving that balance needs more than adding a gate job.

• Protect the evidence path. A rule can be correct while the input builder filters away the fact that should trigger it. Changes to that builder belong inside the protected boundary.
• Review contradictory requirements early. “Preserve the fixture” and “change what this fixture is allowed to do” cannot both be treated as fixed instructions. Resolve the expected behaviour before implementation.
• Separate a signal from the authority it represents. A co-author string, an authenticated identity and a review approval answer different questions. Choose the evidence the decision actually needs.
• Test modes and defaults explicitly. Off, warning, denial, absent settings and invalid values are part of the contract. The soft batch limit also needs its own expected result.
• Measure before tightening. Would-block counts and reviewed false positives were still work to do. Provisional thresholds are easier to improve when their uncertainty stays visible.

I would judge the gate by the decisions it could explain and the limits I could inspect. The implementation made a small set of review concerns executable. The review around it stopped one of those concerns being weakened for convenience. The unfinished rollout then showed exactly what evidence was needed before I could trust it to block work.

Next in the verified sequence is Episode 16, “The Trust Engine — the Grounding Architecture.” The retained plan and pre-crafted episode move from checking code changes to grounding generated claims in evidence. That is the next engineering question: how to preserve the connection between what an agent says and the source that permits it to say it.