Governance before generation. Architectural constraints evaluated and injected before the AI agent writes a single line — not caught in CI, not flagged in PR review. The enforcement point is the strategic variable. Move it upstream of generation and the entire output changes.
Concepts 11 min read · May 2026

# Governance Before Generation

Where in the development pipeline you enforce architectural constraints determines whether governance is a bottleneck or a multiplier. Governance before generation means enforcement happens at the moment of AI intent, not at the moment of human review.

By Theo Valmis · Published May 2026

The phrase "governance before generation" describes a specific enforcement posture — a choice about where in the AI development pipeline architectural constraints are applied. It is not about whether governance happens. It is about the only enforcement point that can shape AI output rather than react to it.

That distinction — shaping versus reacting — is the structural argument this page develops. The enforcement point is not a scheduling detail. It is the variable that determines whether governance is architectural infrastructure or expensive remediation.

The enforcement point is the strategic variable. Moved upstream of the agent, governance shapes a single proposal. Moved downstream, governance becomes the review queue — a rework loop that scales with AI generation rate, not with team size.

## What governance before generation actually means

Every AI coding workflow has a sequence: intent forms, agent runs, output is produced, output is reviewed, output is merged. Governance can be inserted at any point in that sequence. The question is: what happens depending on which point you choose?

Pre-generation enforcement means the governance system fires before the agent writes. The sequence becomes: intent forms, governance evaluates and injects constraints, agent runs with those constraints in context, output is produced already shaped by the constraint. The constraint influenced the proposal; it did not just evaluate it.

Post-generation enforcement — CI linting, PR review, audit tooling — means the governance system fires after the agent has already written. The sequence becomes: intent forms, agent runs (without constraint context), output is produced, governance evaluates the output, violations are flagged or blocked. The constraint evaluated the proposal; it did not shape it.

These produce structurally different outcomes. Pre-generation enforcement reduces violations at source. Post-generation enforcement catches violations after they exist. At human generation speeds, this difference is manageable — the volume of violations is low enough that post-generation catching is workable. At AI generation speeds, the difference compounds.

The enforcement point is the strategic variable. Everything else — the quality of your decision records, the precision of your retrieval, the coverage of your constraints — is multiplied or divided by where enforcement fires. Pre-generation enforcement multiplies; post-generation enforcement divides attention.

The five concrete checkpoints across the AI development lifecycle make this choice visible. Each is a place where governance can fire — but only the first two fire before generation. The rest react to output that already exists.

Five enforcement checkpoints · two fire before generation

Five lifecycle checkpoints. Pre-generation governance: IDE corpus as context, and pre-tool-use hook that blocks before the agent writes. Post-generation checks: CI check (the hard gate that blocks before merge), Merge gated on the verdict, and post-hoc Audit review.

Pre-generation governance
Post-generation checks
IDE
corpus as context
Pre-tool hook
block before generation
CI check
block before merge
Merge
gated on verdict
Audit
post-hoc review
Five checkpoints, one strategic split. Pre-generation governance shapes a single proposal before the agent writes. Post-generation checks react to output that already exists; the CI gate is the only one that can still block.

## Why this problem exists in AI-native development

The enforcement-point problem is not new to software teams. Static analysis, linting, and pre-commit hooks all represent an understanding that catching violations earlier is cheaper than catching them later. The question has always been: how early can you push the enforcement point?

For human developers, the answer was: pre-commit, at most. Human developers can internalize constraints, read documentation, and apply architectural knowledge as they write. Pre-generation enforcement — injecting constraints before the developer types — was not meaningfully possible because the developer was already doing it mentally.

AI agents do not internalize constraints. They generate code based on training distribution, task prompt, and whatever context is present in the active window at generation time. If the constraint is not in that context, the agent does not apply it. It is not failure to comply; it is absence of information. The agent literally does not know the constraint exists unless it is injected.

This creates a structural opportunity that did not exist in human-paced development: the injection point before generation is now a real engineering surface. You can specify exactly what context the agent receives before writing. If architectural constraints are part of that context, they shape the output. If they are absent, the output is unconstrained by your decisions.

Enforcement point | What it affects | Outcome at AI scale
--- | --- | ---
Pre-generation hook | What the AI proposes | Violations prevented at source
Pre-commit / CI lint | Whether code is staged or merged | Violations written, then caught — costs reviewer time
PR review | Whether code is merged | Violations written, reviewed, disputed, revised — highest cost
Post-merge audit | Codebase at rest | Violations already in production — remediation required

The table above describes a cost gradient. Every row to the right of pre-generation enforcement represents a stage where the violation already exists as written code and must be undone. The only enforcement point where the violation never exists is pre-generation. Every other point is catching something that already happened.

## The common misread: treating post-generation enforcement as equivalent

Teams that have invested in strong CI pipelines and thorough code review often argue that their post-generation enforcement is functionally equivalent to pre-generation governance. The reasoning: if the CI gate catches every violation and blocks every non-compliant merge, then no violations reach production — which is the goal.

This argument holds for violation prevention at the codebase level. It does not hold at the level of review cost, developer feedback loops, or architectural drift velocity.

When the CI gate blocks a violation, someone wrote it, staged it, opened a PR, waited for CI, read the failure, understood the violation, revised the code, and re-submitted. That sequence consumed time at every step. At human generation speeds, that sequence is occasional — most PRs pass, and the violations that fail are edge cases. At AI generation speeds, that sequence fires far more frequently. The AI writes more, it writes faster, and each generation is a fresh draw from a distribution that does not know your architectural constraints unless you inject them.

Post-generation enforcement catches violations after they are written. Pre-generation enforcement prevents them from being written. The CI gate is a necessary fallback. It is not a substitute for pre-generation governance. Teams that treat CI as their primary enforcement layer will find it increasingly expensive as AI generation volume grows.

The second failure mode of post-generation-only enforcement is architectural drift velocity. When violations are caught post-generation, the agent's context does not update. The next generation starts from the same constraint-free state. The agent will produce similar violations again — not because it "learned" the wrong thing, but because its context for the next task does not include the lesson from the previous failure. Pre-generation enforcement injects that lesson into every generation. Post-generation enforcement has to reteach it through CI failures every time.

## How this fits the AI SDLC

Pre-generation governance has a specific home in the AI SDLC: the hook layer, positioned between the agent runtime and the tool execution layer. This is the surface where the agent declares what it intends to do before doing it, and the governance system intercepts that intent.

In Claude Code, this is the pre-tool-use hook. Before the agent writes to a file, the hook fires with the file path and the task context. The governance system receives that signal, retrieves the decision records relevant to the file and task, formats them as constraint context, and injects them back into the agent's environment before the write proceeds. The agent writes with full constraint context. The hook is the enforcement point.

# Claude Code hook configuration (settings.json) "hooks": { "PreToolUse": [ { "matcher": "Write|Edit|MultiEdit", "hooks": [ { "type": "command", "command": "mneme inject --file $CLAUDE_TOOL_INPUT_PATH" } ] } ] }

The hook is not a wrapper around the agent. It is a pre-flight interception that surfaces context the agent did not have before the write intent was declared. The sequence: agent declares intent to write → hook fires → Mneme retrieves relevant decisions → decisions are injected → agent writes with constraint context in scope.

For teams using CI as a secondary enforcement layer, Mneme also provides a CI mode that evaluates generated code against the full decision corpus after generation — a confirmation that what reached CI is consistent with what the hook injected before generation. The CI gate is not the primary governance enforcement; it is the audit trail that confirms the pre-generation layer worked.

This two-layer architecture — pre-generation injection as the shaping layer, CI evaluation as the audit layer — is the full implementation of governance before generation. Neither layer alone is sufficient at scale. Together, they create an enforcement surface that operates at both the moment of AI intent and the moment of merge readiness.

## Related concepts

Governance before generation is the enforcement posture. Three adjacent concepts describe the components that make it work:

- Architectural governance — the system that governance before generation implements. Governance before generation is not a product; it is a design principle about where enforcement lives. Architectural governance is the full system: decision records, retrieval, injection, and verification.
- Deterministic enforcement — the property that pre-generation enforcement must have to be auditable. If the same query against the same decision corpus can produce different constraint injections on different runs, governance is probabilistic and unauditable. Deterministic enforcement ensures the injection is consistent.
- Claude Code integration — the specific runtime surface where pre-tool-use hooks implement governance before generation for Claude Code users. The integration is the engineering realization of the concept.

## Frequently asked questions

What does 'governance before generation' mean?
Governance before generation means that architectural constraints are evaluated and injected into the AI agent's context before it writes a single line of code — not caught in CI, not flagged in PR review, not corrected after the fact. The enforcement point is the moment of AI intent, before output. This is structurally different from post-generation enforcement: the constraint shapes what the AI proposes rather than rejecting what it already produced.
Why does the enforcement point matter?
The enforcement point determines whether governance is a shaping force or a reactive gate. Pre-generation enforcement changes what the AI proposes — the agent receives the constraint before writing and produces code shaped by it. Post-generation enforcement (CI, review) catches violations after the AI has already committed to architectural choices: which patterns to use, which dependencies to introduce, which services to call. Reversing those choices after the fact is always more costly than not making them in the first place. At AI generation speeds, that cost difference compounds into a significant engineering drag.
Isn't CI/CD enforcement equivalent to pre-generation governance?
No. CI/CD enforcement is post-generation: it evaluates code after the AI wrote it, after the developer staged it, after the PR was opened. The constraint fires too late to shape the output. Pre-generation governance fires at the moment of AI intent — before the tool writes to disk. The difference is not just timing; it's outcome. Post-generation enforcement means the AI still writes the wrong thing, developers still spend time on the violation, and the review or CI step still consumes capacity. Pre-generation enforcement prevents the violation from existing.
How does Mneme implement governance before generation?
Mneme implements governance before generation through hook interception at the agent runtime layer. In Claude Code, this is the pre-tool-use hook: before the agent writes a file, the hook fires, Mneme retrieves the relevant decisions for the file path and task, and injects them into the agent's context. The agent then generates code with the constraint in context. Mneme also provides CI gates for post-generation enforcement as a secondary layer, but the primary enforcement point is pre-tool-use — the moment before the write.
What happens without governance before generation?
Without governance before generation, the enforcement burden falls entirely on post-generation processes: code review, CI linting, and PR checklists. At human generation speeds, this is manageable — the violation rate is low enough that review can catch most issues. At AI generation speeds, it fails: the volume of output overwhelms review capacity, violations slip through, and those that are caught still consumed reviewer attention that could have been directed at logic and product decisions. The codebase drifts architecturally, and the drift compounds as downstream agents build on drifted patterns.
Operational implications

- Review Is Not Governance

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

- Why Observability Is Not Governance

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

- AI Code Review Does Not Scale Linearly

  Adding reviewers cannot keep pace with agent-paced generation rates. The math is structural.

- Prompt Engineering Is Not Governance

  Prompt templates nudge output. They cannot enforce architectural invariants across sessions and agents.

Enforcement surfaces

- Claude Code

  PreToolUse hook enforces governance constraints before every file write.

- Claude Agent SDK

  Tool-call interception enforces decisions inside multi-agent SDK workflows.

- Cursor

  CLAUDE.md-equivalent governance surface for Cursor-based development.

- GitHub Actions

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

Related demos

- Governed Python Agent

  Live enforcement of storage and dependency decisions by a Claude-powered agent.

- Repository Pattern

  Pattern-level architectural constraint enforced at the point of agent generation.

- Storage Decision

  ADR-sourced storage constraint enforced deterministically across two competing agent proposals.

- Dependency Policy

  Dependency policy decision compiled from ADR and enforced before a package is imported.

- Claude Agent SDK Governance

  Governance before generation wired into the Claude Agent SDK tool-call layer.

- Architectural Drift Demo

  Before/after trace of drift accumulation and governance interception.

Related benchmarks

- Benchmark

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

Related concepts

- Architectural Governance

  The discipline of constraining what AI agents are allowed to do, not just observing what they did.

- Executable Architectural Intent

  The slice of project knowledge promoted from documentation into machine-evaluable, enforceable constraints.

- Objective-Driven Development

  When the unit of work shifts from prompt to objective, governance has to enter the loop, not wait for review.

- Verification Contracts

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

- Deterministic Enforcement

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

- Enforcement Provenance

  Every governance verdict is traceable back through the precedence chain to the originating decision record.