Policy as Code

Every engineering organization has policies. Some are security rules, such as which identities may reach an API. Some govern infrastructure, such as which regions or images are approved. Others govern software architecture, such as which modules may access customer data or which adapter must mediate a legacy dependency.

When those policies live only in prose, enforcement depends on interpretation and memory. Policy as Code makes selected rules explicit enough for software to evaluate. The rule can be reviewed in version control, tested against examples, distributed to enforcement points, and applied consistently to structured input.

The policy engine does not need to be embedded in the system it governs. Open Policy Agent, the canonical general-purpose example, separates policy decision-making from policy enforcement. A service sends structured input to OPA, OPA evaluates applicable policy and data, and the service decides how to enforce the returned result. That separation is one of the defining architectural strengths of Policy as Code.

How Policy as Code works

A complete policy system has more than a rule file. It needs a chain from authority to action:

• Policy source: a rule is authored, versioned, reviewed, and tested.
• Decision point: an engine evaluates structured input against the applicable rule and data.
• Enforcement point: the calling system acts on the result.
• Decision evidence: logs record which rule, input, and policy version produced the outcome.

This explains why Policy as Code is broader than automated compliance scanning. A scanner evaluates one class of artifacts at one point in a lifecycle. A policy decision can govern API requests, infrastructure plans, deployment configuration, CI metadata, agent tool calls, or any other action that can be represented as structured input.

From architectural decision to enforced agent action

The Mneme-specific opportunity is architectural Policy as Code. Traditional Policy as Code asks, “Is this action permitted?” Architectural Policy as Code asks, “Would this change violate an architectural decision?”

The pipeline makes two translations. First, a human architectural decision becomes a machine-evaluable rule. Second, the rule becomes an operational decision at a specific action boundary. Losing either translation produces a familiar failure: policy without architectural meaning, or architectural intent without enforcement.

Policy decision points and enforcement points

A policy decision point answers the question. A policy enforcement point does something with the answer. OPA documents this explicitly: OPA is the decision point, while applications and integrations are enforcement points. Keeping those responsibilities separate allows teams to manage policy centrally while enforcing it near the systems that act.

The separation also exposes design choices that a rule file cannot settle on its own:

• Which input is authoritative and complete enough to evaluate?
• Where in the action lifecycle should the decision be requested?
• Should a missing or unavailable decision fail open or fail closed?
• Does the enforcement point have the authority to block, or can it only warn?
• What evidence must be retained for review and audit?

These questions are especially important for AI coding agents. An advisory policy returned after the agent has edited thirty files has a different cost and effect than a policy evaluated before the first incompatible write.

Policy as Code vs Architecture as Code

Policy as Code is broader than architectural governance

Policy as Code is used across authorization, security, compliance, infrastructure, Kubernetes admission, CI/CD, API gateways, and application behavior. Mneme should not try to redefine that broad category around itself. General-purpose policy engines are designed to evaluate many kinds of organizational rules against structured data.

Architectural governance is a narrower domain with specific upstream and downstream requirements. The system has to preserve why a decision exists, resolve which code the decision governs, interpret a proposed software change, and return a verdict at an agent execution surface. Generic policy evaluation can be part of that design, but it does not provide the architectural decision model or the integration with agent actions by itself.

Policy as Code for AI coding agents

AI coding agents change the unit of enforcement. Traditional CI policy evaluates an artifact after it exists. Agent policy can evaluate a proposed action before the tool call executes. That creates an opportunity for governance before generation and pre-action enforcement:

• An agent proposes an edit, write, dependency addition, or configuration change.
• The runtime identifies the affected architectural scope.
• The policy layer evaluates the action against the applicable decision records.
• The enforcement point allows, blocks, or routes the action for review.
• The system records enforcement provenance.

This is not merely a faster CI check. The earlier enforcement point changes the agent's trajectory. A blocked incompatible action can redirect the implementation before downstream code, tests, and explanations accumulate around the wrong architectural choice.

What good architectural policy requires

Deterministic evaluation

A governance rule should produce the same verdict for the same input and policy version. Probabilistic interpretation can help author or classify policy, but the binding decision needs stable semantics if teams are expected to trust and audit it.

Precise scope

Architecture is contextual. A dependency that is forbidden in a domain service may be valid in an adapter. Policy that lacks scope either misses real violations or floods teams with false positives.

Explicit precedence and exceptions

Policies overlap and decisions evolve. The system needs explicit rules for supersession, specificity, exceptions, and unresolved conflicts. Otherwise the policy engine merely moves ambiguity from prose into code.

Fail-safe enforcement

The enforcement point needs a defined behavior when policy cannot be evaluated. OPA's operational guidance distinguishes fail-open and fail-closed behavior and leaves that choice to the integrating software. Agent governance needs the same explicit decision, calibrated to the cost of allowing or denying the action incorrectly.

Traceable evidence

An allow or deny result is not enough for architectural governance. Teams need to know which decision applied, which rule version represented it, why the scope matched, and where the verdict was enforced. That chain turns policy execution into reviewable engineering evidence.

Where Mneme fits

Mneme applies Policy as Code to architectural decisions in AI-assisted software development. It sits between the sources that describe intent and the execution surfaces where agents change code. The goal is not to become a universal policy engine. The goal is to make selected architectural rules deterministic, scoped, enforceable, and traceable at the moment they matter.

That positioning keeps the categories clear. OPA and other policy systems remain appropriate for general authorization and infrastructure policy. ADLs, ADRs, and Architecture as Code formats remain appropriate for describing architectural intent. Mneme connects that intent to controls inside coding-agent workflows.

Sources and further reading

• Open Policy Agent documentation: Policy as Code, structured input, and the separation of policy decision-making from enforcement.
• OPA philosophy: policy decoupling, declarative policy, and automatic enforcement across software services.
• OPA deployment guidance: policy decision points, policy enforcement points, decision logging, and proximity to enforcement.
• OPA operations guidance: explicit fail-open and fail-closed behavior when a decision is unavailable.