Concepts

The language of AI-native governance

Infrastructure categories are defined by the teams building them. These are the concepts that shape how Mneme understands the problem of governing AI coding agents — and why most current approaches don't solve it.


Most of the terms on this page don't have industry-standard definitions yet. Architectural governance, governance before generation, decision continuity — these are concepts that the AI coding ecosystem is actively working out. The definitions here are Mneme's positions, not neutral encyclopedia entries.

Each concept page explains not just what the term means, but why the structural problem it names exists in AI-native software delivery — and why the solutions that feel intuitive (documentation, prompt engineering, code review) don't actually solve it.

If you're evaluating architectural governance tooling, these concepts are the vocabulary for comparing approaches. If you're building in this space, they're the framework for understanding where different systems sit in the stack. The applied arguments — where each concept's consequences play out in real engineering — live in insights; the empirical proof points are in the benchmark.

Mneme HQ concept architecture A four-tier composition diagram. The top tier (context) shows where governance operates: the AI operating layer and objective-driven development. The second tier (outcomes) shows what governance achieves: architectural governance and governance infrastructure. The third tier (properties) shows six system properties: governance before generation, deterministic enforcement, governance propagation, model-independent governance, multi-agent continuity, and enforcement provenance. The fourth tier (primitives) shows four primitives the system is built from: architectural compiler, executable architectural intent, verification contracts, and precedence semantics. A failure-mode rail at the bottom shows what accumulates in the absence of these layers: AI agent drift and architectural drift. CONCEPT ARCHITECTURE · context · outcomes · properties · primitives every node links to its definition CONTEXT where governance operates AI Operating Layer intent · tools · agents · execution Objective-Driven Development goal-driven loops · agent search OUTCOMES what governance achieves Architectural Governance the discipline Governance Infrastructure the platform layer PROPERTIES what governance does Governance Before Generation pre-generation hook Deterministic Enforcement same input · verdict Governance Propagation one corpus · every agent Model-Independent Governance survives the swap Multi-Agent Continuity sessions · time Enforcement Provenance citable verdicts PRIMITIVES what it's built from Architectural Compiler ADR → typed corpus Executable Architectural Intent the corpus substance Verification Contracts pre-registered verdicts Precedence Semantics supersession · scope · time WITHOUT THIS LAYER what accumulates AI Agent Drift the agent-side phenomenon Architectural Drift the codebase-side consequence ↑ what governance prevents ↑ outcomes operate within context ↑ properties produce outcomes ↑ primitives compose into properties
How the concepts compose. Four primitives — compiled records, executable architectural intent, verification contracts, precedence rules — produce six system properties (including model-independent governance, the property that makes the whole stack survive a model swap), which together produce two outcomes: architectural governance and governance infrastructure. Those outcomes operate inside a larger context — the AI operating layer and objective-driven development — that this stack is designed to make safe. Absent these layers, the failure rail accumulates: agent-side drift, codebase-side drift.
01
Architectural Governance

The system that encodes team decisions as machine-evaluable constraints and enforces them at the point of AI code generation — before review, before drift compounds.

02
Governance Infrastructure

The dedicated engineering platform layer that encodes, distributes, versions, and enforces architectural decisions across AI agents. Infrastructure — not process, not convention, not tooling bolt-on.

03
AI Agent Drift

The agent-side phenomenon — coding agents, across sessions and providers, producing code that progressively diverges from the team's intended architecture when no shared decision substrate exists.

04
Architectural Drift

The codebase-side compound degradation that AI agent drift produces. What "drift" looks like once it has settled into the repository's structure.

05
Multi-Agent Architectural Drift

What happens when multiple autonomous agents each make locally reasonable changes that compound into system-wide architectural deviation.

06
Governance Before Generation

The principle that architectural constraints must be evaluated before the AI writes code. The enforcement point is the strategic variable — and moving it upstream changes everything.

07
Architectural Compiler

The pipeline that converts documentation-form decisions into machine-evaluable constraint records. Parse → validate → resolve → emit → enforce. Compilation closes the documentation-to-enforcement gap.

08
Executable Architectural Intent

The slice of project knowledge that has been promoted from documentation into machine-evaluable, enforceable constraints that bind AI agent behavior at generation time — not just read, but obeyed.

09
Verification Contracts

Pre-registered, machine-evaluable assertions that define what a governance check must prove. The structural difference between measurable governance and governance you can only hope for.

10
Governance Propagation

One compiled decision reaches every agent, every developer, every CI run with identical scope and verdict. The spatial property that turns "the same rule" into "the same enforcement."

11
Deterministic Enforcement

A governance check that produces the same verdict for the same inputs, always. Not a performance property — the precondition for governance auditability and improvement.

12
Precedence Semantics

The ordered rules that resolve overlapping decisions deterministically. Supersession → scope specificity → recency → severity. Conflicts that can't resolve are compile-time errors, not runtime ambiguity.

13
Multi-Agent Continuity

Decisions persist across agents, sessions, and time without re-derivation. The temporal counterpart to propagation — decision-side memory rather than agent-side memory.

14
Decision Continuity

The property that architectural decisions remain enforced across agents, sessions, and time — regardless of which agent acts or what context it inherited.

15
Enforcement Provenance

Every verdict is a citable chain — back through the precedence rule, the compiled record, and the authoring ADR. Opaque enforcement is theater; provenance is what makes governance trustable.

16
Governance Provenance

Every rule has a lineage — the authoring ADR, the supersession chain, the originating discussion or incident. Per-rule, not per-verdict; the substrate that turns governance into engineering.

17
Artifact Provenance

The record of plans, diffs, screenshots, browser recordings, and verification evidence produced by autonomous agents. Provenance explains; governance constrains.

18
Model-Independent Governance

Architectural rules that live outside any one model, prompt, IDE, or agent runtime. The same engine consulting the same corpus returns the same verdict at every enforcement surface — so governance outlives the next model migration.

19
Agent Verification

Proving that an autonomous run preserved architectural intent, operational constraints, and invariants — not just that execution completed. Execution success is not architectural correctness.

20
Execution Surfaces

The inventory of places agents leave artifacts — code, commits, branches, PRs, CI configs, manifests, runbooks, docs. Governance limited to source code leaves most agent output ungoverned.

21
AI-Native SDLC

A software delivery lifecycle designed from first principles for AI agents as primary code generators. The rate-limiting step has flipped — generation is no longer the bottleneck.

22
Agentic Development

The development paradigm where AI agents are first-class code generators. Architectural control stops being a cultural norm and becomes an operational engineering problem.

23
Objective-Driven Development

A programming model where developers define a desired outcome and an AI agent iteratively changes code until the condition is met. The unit of work shifts from the prompt to the objective — and the agent becomes an optimizer that needs constraints.

24
AI Operating Layer

The coordination layer that translates human intent into multi-system execution across tools, agents, memory, and infrastructure. The new operating system is an execution system — and every execution system eventually becomes a governance system.

25
Reliable Delegation

The operating model for AI agents in production: teams can assign work to agents only when the system can verify that the work stayed inside known architectural, security, and operational constraints.

26
Intent Debt

The gap between what a system is supposed to preserve and what its AI agents are actually constrained to follow. When agents become the execution layer, intent debt becomes the primary bottleneck.

27
Spec-Driven Development

An AI-assisted workflow where a structured spec is the source of truth for what an agent builds. It defines what to build — governance defines what must stay true while building it.

See these concepts in practice

The benchmark, the demos, and the open-source codebase are all running versions of the governance infrastructure described here.

View on GitHub →