Enforcement provenance. Every governance verdict is a record with a chain — back through the precedence rule that selected the decision, back through the compiled record, back to the authoring ADR. "Why did this PR get blocked?" has a single, citable answer: the chain itself. Without provenance, governance is opaque enforcement; with it, governance is auditable engineering.
Concepts 9 min read · May 2026

# Enforcement Provenance

An engineer pushes a PR. CI blocks the merge with a governance violation. The engineer's first question is: which decision blocked this, and where can I read the rationale? Enforcement provenance is the engineering property that makes the answer one click away — not a guessing game.

By Theo Valmis · Published May 2026

A governance system that blocks a merge but cannot explain why is indistinguishable from a flaky test. The block becomes noise to be worked around — disabled in CI, ignored in review, treated as a hostile gate rather than an architectural signal. Provenance is the property that converts an enforcement event from "the system said no" into "this specific team decision, written on this date, by this person, applies because of this precedence rule, and the rationale is at this URL."

Provenance chain · enforcement verdict cites authoring intent

Six-link chain from authoring ADR through compilation, retrieval, precedence resolution, evaluation, and enforcement event. Link 1 (authoring) is the source decision; link 6 (enforcement event) is the verdict. Each link cites the previous, making the chain the audit record. A citable-chain summary block follows the six links.

1. 01
   Authoring
   Source decision
   git sha · author · date
2. 02
   Compiled record
   decision_id
   corpus version · schema
3. 03
   Retrieval
   scope match · top-K
   query · rank · candidates
4. 04
   Precedence
   rule · winner
   supersession · scope
5. 05
   Evaluation
   predicate(decision, diff) → block
   tool · agent · timestamp
6. 06
   Enforcement event
   verdict · severity
   queryable from CI, dashboard, IDE

Citable chain
verdict#NNNN ← evaluator(decision @ corpus v.N) ← precedence(supersession) ← retrieval(query q)
← decision ← compile(source @ sha) ← author
Every step is a link · every link is queryable · the chain is the audit record.
The chain is the audit record. Verdict → evaluator → precedence rule → retrieval → compiled record → authoring ADR. Each link cites the next. "Why did this fail?" resolves to a single chain, not a guess.

## What enforcement provenance actually means

Provenance is not a feature added on top of governance. It is what every step of the governance pipeline produces as a byproduct, when the pipeline is built right. The components are:

### 1. Decision identity

Every compiled decision has a stable identifier — not just a filename. The ID survives ADR renames, supersessions, and refactors of the source documentation. When a verdict cites `d-17`, that identifier resolves to a specific record in the corpus regardless of how the underlying ADR file has moved or been edited.

### 2. Compilation traceability

The compiler records which source file produced which decision record, at which git SHA, with which author. The compiled corpus is not just data; it is data with origin. Anyone reading the corpus can answer "where did this constraint come from?" by following the link back to the source ADR.

### 3. Retrieval explanation

When the governance retriever returns a set of candidate decisions for a query, it records the query, the scope match, the rank, and the candidates. The set of decisions that could have applied is itself a queryable record — not just the one that did apply.

### 4. Precedence citation

When two or more candidates match, the precedence resolution names the winner and the rule that selected it. "ADR-0042 wins by supersession over ADR-0017" is a complete precedence citation; "ADR-0042 was chosen" is not.

### 5. Evaluation record

The evaluator records the predicate it ran, the input it ran against, the agent or CI run that triggered it, and the timestamp. Two evaluations with the same input and corpus produce identical records (deterministic enforcement), but each evaluation is its own audit event.

### 6. Verdict link

The enforcement output links to all five upstream artifacts. Reading the verdict tells you which evaluator, which precedence rule, which retrieval, which compiled record, and which authoring ADR. There is no hidden step.

## Why provenance has to be structural, not narrative

A common shortcut is to attach a freeform message to each block: "Blocked because of the repository pattern rule." This is narrative provenance — a human-readable explanation generated by the system at the time of the block. It is useful for humans, but it is not enough.

Narrative provenance fails in three ways: it cannot be programmatically queried (so you cannot ask "how often does this decision block PRs?"); it cannot be aggregated (so you cannot graph drift by decision); and it is generated, not stored (so the rationale text might change run-to-run as templates evolve, breaking auditability over time).

Structural provenance — IDs, links, timestamps, versions — is the substrate underneath narrative. The system can render any narrative on top of structural provenance at any time; the system cannot derive structural provenance from narrative after the fact.

If the verdict cannot be programmatically traced to a specific record, the enforcement is opaque. Opaque enforcement is what turns governance into noise — engineers stop trusting it because they cannot interrogate it.

## What provenance enables

Several capabilities are downstream of having a provenance chain. None of them are achievable without it.

Capability | Without provenance | With provenance
--- | --- | ---
Why did this block? | Read the message; guess at the rationale | Follow the chain to the authoring ADR
Drift telemetry | Aggregate text matches | Aggregate by decision_id · per-agent · per-path
Decision impact analysis | None — guesses based on tickets | "This ADR blocked 14 PRs this quarter"
Regression after refactor | Manual code review of the corpus | Diff the resolved chain across compilations
Compliance evidence | Argue the system worked | Show the chain to an auditor
Dispute resolution | "The bot said no" | "ADR-0017 says no; here is the file and the author"

The fifth row matters in regulated environments specifically. A security or compliance review of an AI-coded codebase needs to demonstrate not just "we have rules" but "this PR was evaluated against these specific encoded constraints at this version of the corpus, and this verdict was recorded." Provenance is what makes that demonstration possible.

## The common misread: logs as provenance

Many teams treat application logs of governance events ("INFO: block_pr called at 14:32, reason='repository pattern'") as provenance. They are not. A log line is an artifact of execution; it is not a citable link.

Real provenance has three properties that logs alone do not:

- Stable references — the decision ID in the verdict still resolves to a record six months later, even if the ADR was renamed.
- Versioned context — the corpus version at the time of the verdict is part of the record. Reproducing the verdict means knowing which corpus state produced it.
- Bidirectional links — given a decision, you can list the verdicts that cited it. Given a verdict, you can list the decisions it cited. Logs are one-directional and unindexed.

Logs tell you what happened. Provenance tells you why it happened, and lets you follow why all the way back to the team's authoring intent. The difference is unobservable in any single event and decisive across thousands.

## Provenance as the foundation of trust

Governance systems live or die on engineer trust. An engineer who has been blocked once by an opaque rule will, the next time, look for a way around the gate. A governance system that gets routed around does not have governance — it has theater. Provenance is the mechanism by which engineers can interrogate the system, disagree with it productively, and either update the decision or accept the block on its merits.

This is why provenance is not a "nice to have" property attached to a working governance system. It is a precondition for governance being adopted at all. Without it, the system is a black box that says no. With it, the system is a colleague that cites its sources.

## Related concepts

- Governance provenance — the companion concept at a different grain. Enforcement provenance traces a verdict back to its decision; governance provenance traces a decision back to its origin.
- Verification contracts — what provenance proves at the system level. Contracts pre-register expected verdicts; provenance records observed verdicts with citable lineage.
- Deterministic enforcement — what makes provenance reproducible. Without determinism, the chain reconstructs different verdicts on different runs.
- Architectural compiler — the source of compilation traceability, which is link 02 of the chain. Compilation produces the decision IDs and source links that provenance relies on.
- Precedence semantics — what makes link 04 citable. Without ordered precedence rules, "the winner was chosen" is not a usable provenance step.

Operational implications

- AI Coding Governance Should Be Reviewable

  Governance verdicts must be inspectable, citable, and disagreeable — or engineer trust collapses.

- Why Observability Is Not Governance

  Visibility explains drift after it occurs. Governance constrains drift before generation.

- Why Architectural Governance Needs Precedence Semantics

  When ADRs overlap, the system needs deterministic resolution — not best-effort guessing from a model.

- Review Is Not Governance

  Human review systems do not scale linearly with AI output velocity. Review samples; governance shapes.

Enforcement surfaces

- GitHub Actions

  CI enforcement gate: every PR is checked against the compiled constraint set.

- GitLab

  Pipeline-stage governance enforcement on merge requests.

- Claude Code

  PreToolUse hook enforces governance constraints before every file write.

Related demos

- Multi-Agent Governance

  Governance constraints propagate identically across Claude, Cursor, and CI in a single workflow.

Related benchmarks

- Benchmark

  Empirical reproducibility measurements across governance scenarios — same input, same verdict.

Related concepts

- Verification Contracts

  Pre-registered, machine-evaluable claims a generated artifact must satisfy before it is allowed to land.

- Precedence Semantics

  Explicit resolution rules for how overlapping or superseding decisions combine into a single verdict.

- Governance Infrastructure

  The engineering platform layer that encodes, distributes, versions, and enforces architectural decisions across agents and CI.

- Deterministic Enforcement

  Same input, same verdict — every time. Governance verdicts are reproducible, not probabilistic.