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.
Core concepts
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.
→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.
→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.
→The codebase-side compound degradation that AI agent drift produces. What "drift" looks like once it has settled into the repository's structure.
→What happens when multiple autonomous agents each make locally reasonable changes that compound into system-wide architectural deviation.
→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.
→The pipeline that converts documentation-form decisions into machine-evaluable constraint records. Parse → validate → resolve → emit → enforce. Compilation closes the documentation-to-enforcement gap.
→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.
→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.
→System properties
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."
→A governance check that produces the same verdict for the same inputs, always. Not a performance property — the precondition for governance auditability and improvement.
→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.
→Decisions persist across agents, sessions, and time without re-derivation. The temporal counterpart to propagation — decision-side memory rather than agent-side memory.
→The property that architectural decisions remain enforced across agents, sessions, and time — regardless of which agent acts or what context it inherited.
→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.
→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.
→The record of plans, diffs, screenshots, browser recordings, and verification evidence produced by autonomous agents. Provenance explains; governance constrains.
→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.
→Proving that an autonomous run preserved architectural intent, operational constraints, and invariants — not just that execution completed. Execution success is not architectural correctness.
→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.
→Paradigm & context
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.
→The development paradigm where AI agents are first-class code generators. Architectural control stops being a cultural norm and becomes an operational engineering problem.
→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.
→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.
→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.
→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.
→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.
→Applied governance surfaces
The deterministic enforcement layer that preserves architectural intent across AI-assisted software development — the inevitable next category in the AI engineering stack.
→The enforcement layer that preserves architectural, operational, and organizational constraints across AI-driven software execution systems.
→Enforcement of architectural, operational, and policy constraints across long-running autonomous execution environments — the runtime-time discipline.
→The control layer that keeps autonomous coding agents aligned with architectural decisions while they operate inside agent-first IDEs — Antigravity, Cursor, Claude Code.
→The practice of applying architectural constraints, decision provenance, and verification checks to agent-first workflows running across editor, terminal, and browser.
→Architecture deep dives
The five-stage pipeline, DecisionRetriever field weights, top-K=3 selection, Layer 1/Layer 2 metrics, and why there are no embeddings.
The three-tier model (documentation / prompt memory / decision memory), schema comparison, precedence resolution, and ADR import workflow.
See these concepts in practice
The benchmark, the demos, and the open-source codebase are all running versions of the governance infrastructure described here.