Code-as-Policy: Definition, Applications, and Implications

Updated 25 August 2026

Code-as-Policy refers to systems where governance rules are encoded in executable programs, which are then evaluated, enforced, and made contestable digitally.
These systems intersect with robotics, cloud infrastructure, and policy enforcement, but raise concerns about legitimation, transparency, and human oversight. For example, language models generate infrastructure codes that are validated for compliance checks, such as structural, behavioral, or operational invariants.
The reliability and performance of the code depend on elements like APIs, object grounding, and human-crafted compositions, yet risks like invalid or unsafe code persist within the boundary of operational validating tools.

Code-as-Policy is a paradigm in which executable programs encode, interpret, enforce, or operationalize rules governing actions, resources, workflows, or decisions. The term encompasses several related but distinct architectures: LLMs that synthesize robot-control programs; policy engines that evaluate machine-readable governance rules; typed programs in which authorization evidence is required by the type system; verifier-guided generation of infrastructure code; and systems that govern generated implementations through protocols, invariants, and evidence. Across these forms, code is not merely an implementation detail: it becomes part of the mechanism by which norms are represented, evaluated, enforced, or made contestable. The paradigm nevertheless raises a fundamental distinction between executable enforcement and legitimate governance. Software can constrain what happens, but transparency, interpretation, oversight, contestability, provenance, and remediation determine whether what happens is justified and reviewable (Hicks, 2022).

1. Conceptual foundations and scope

Code-as-Policy can be understood at three levels. Policy specification states what actions, states, or outcomes are permitted. Policy evaluation determines whether a concrete request or artifact satisfies the stated conditions. Policy-preserving execution constrains the application, controller, or infrastructure so that the governed action cannot proceed without satisfying the policy.

A conventional policy-as-code system generally separates the policy artifact, policy engine, and enforcement point. Developers author declarative rules; an engine evaluates those rules over contextual inputs; and a CI/CD pipeline, Kubernetes admission controller, sidecar, embedded library, or standalone service acts on the result. Decisions may take the form of allow, warn, or deny. This separation supports reuse, testing, auditability, and independent evolution (Foalem et al., 9 Jan 2026).

Code-as-Policy is broader than Policy-as-Code. A policy engine such as Open Policy Agent (OPA) evaluates explicitly authored rules, whereas a generated robot program, infrastructure compiler, authorization function, or kernel heuristic may itself function as policy even when it is not packaged as a dedicated policy artifact. Conversely, some systems associated with Code-as-Policy generate infrastructure or control code while relying on separately supplied policies for verification. The term therefore describes a functional relationship between code and governance rather than one universal language or execution model.

Regulative and constitutive norms

A distinction associated with the code-as-law literature separates regulative and constitutive norms. A regulative norm mandates, permits, or prohibits an action that remains technically possible. Driving above a speed limit remains possible even if legally prohibited. Code may detect or record the violation, while legal institutions determine unlawfulness, liability, admissible evidence, sanction, or remedy.

A constitutive norm defines an action or status itself. A password requirement is constitutive because entering the correct password constitutes successful login; without it, access is technically unavailable. Software can therefore transform a policy choice into an architectural condition. Instead of stating that access is forbidden, it can make access impossible.

In this setting, a system’s designers, implementers, trainers, and operators possess normative power. They select objectives, categories, thresholds, training data, features, error definitions, blocking conditions, exception handling, evidence retention, and human-intervention mechanisms. A system can therefore reproduce institutional assumptions even when discrimination or exclusion was not explicitly intended. The example of racial risk assessment illustrates how classifications embedded in software can operationalize existing bias (Hicks, 2022).

Code is not automatically law

The “code is law” literature includes Reidenberg’s lex informatica, Lessig’s account of architecture as regulation, smart contracts, and digisprudence. Code can regulate conduct, create categories and statuses, distribute benefits and burdens, and affect people who never directly interact with the system.

Code does not, however, automatically possess the institutional properties of law. It generally lacks ex ante legitimation, procedural fairness, independent interpretation, appeal, legally recognized accountability, and ex post remediation. Software commonly executes represented conditions rigidly, whereas legal rules may contain contextual standards, exceptions, proportionality requirements, defenses, and interpretive practices. Code-as-Policy is therefore best understood as a qualified thesis: code can enforce norms directly and pervasively, but technical enforcement is not self-legitimating governance.

2. Major architectural forms

Code-as-Policy research contains several architectural families. They share executable governance but differ in what code represents, when it is generated, and how correctness is established.

Form	Primary artifact	Main enforcement or assurance mechanism
Executable embodied policy	Robot-control or agent program	Perception, API composition, execution, and feedback
Policy-as-Code compliance	Rego or another policy artifact	Policy-engine evaluation over structured inputs
Policy as type	Typed proposition and proof-bearing value	Compile-time and runtime proof obligations
Policy-guided synthesis	Terraform, HCL, or other generated artifact	Verifiers, policy checks, repair, and reinforcement learning
Protocol-governed implementation	Generated implementation admitted under a protocol	Structural, behavioral, operational invariants and evidence

Embodied program synthesis

In the original Code-as-Policies formulation, a LLM receives natural-language instructions and generates Python programs that query perception interfaces, perform symbolic or geometric computation, and call robot-control APIs. The generated program may contain loops, conditionals, feedback, reusable functions, NumPy operations, Shapely geometry, and calls to manipulation or navigation primitives. The resulting policy is an executable perception-to-control program rather than a textual plan (Liang et al., 2022).

Later systems extend this model. RoboPro combines RGB-D observations, robot state, language, and an API library in a unified vision-language-code model. It generates policy code whose calls produce end-effector trajectories, using perception APIs such as object localization and grasp estimation and control APIs such as move_to_pose, follow_way, open_gripper, and close_gripper (Xie et al., 8 Jan 2025).

CaP-X studies the same paradigm as a benchmarkable robot-manipulation architecture. Its CaP-Gym environment lets agents synthesize and execute programs that compose perception and control primitives, while CaP-Bench varies abstraction level, temporal interaction, and perceptual grounding (Fu et al., 23 Mar 2026).

Agentic policy orchestration

Some systems use LLMs not only to generate policy code but also to orchestrate retrieval, validation, execution, and repair. ARPaCCino translates natural-language infrastructure requirements into Rego, evaluates Terraform plans, and iteratively modifies infrastructure until validation succeeds. Its architecture combines RAG, OPA/Rego syntax checking, semantic review, Terraform preprocessing, policy evaluation, and source-level remediation (Romeo et al., 11 Jul 2025).

MACOG applies a related multi-agent architecture to Terraform generation. Specialized agents construct an intermediate resource graph, harmonize provider schemas, emit HCL, review the result, prove security properties, estimate cost, execute Terraform validation, and repair failures through a shared blackboard and finite-state controller (Khan et al., 4 Oct 2025).

Policy-guided and evolutionary synthesis

TerraFormer generates Terraform configurations while using Rego, terraform validate, and terraform plan as verifier signals during supervised fine-tuning and Group Relative Policy Optimization (GRPO). Its reward distinguishes unparsable output, compilable but undeployable output, and deployable output satisfying increasing numbers of policy rules (Jana et al., 13 Jan 2026).

PolicySmith instead treats systems-policy design as offline evolutionary program search. An LLM generates candidate caching or congestion-control heuristics inside a template, a checker filters candidates, and a context-specific evaluator measures performance. High-scoring programs are returned to subsequent prompts as examples. The generated policies can operate in a cache simulator or through eBPF-compatible Linux kernel interfaces (Dwivedula et al., 9 Oct 2025).

Hybrid neural and executable policies

RL-GPT separates high-level procedural behavior, which is suitable for generated code, from low-level visually grounded behavior, which is learned through reinforcement learning. A slow agent decomposes tasks and decides which sub-actions should be coded or learned; a fast agent generates code and RL configurations; a critic evaluates execution; and PPO trains neural policies for difficult reactive behaviors (Liu et al., 2024).

CaP-RL similarly fine-tunes a coding model using execution rewards. The model emits executable robot programs, the programs run in an environment, and verifiable success rewards update the code-generating policy (Fu et al., 23 Mar 2026).

3. Representation, enforcement, and verification

The central technical question is how policy code relates to the governed action. Systems differ substantially in whether they produce a Boolean decision, a proof, an executable controller, a constrained artifact, or evidence of compliance.

Compliance and accountability

Compliance auditing usually checks whether a system follows a predefined norm. Its basic output is effectively pass or fail. This is useful when the norm is agreed, precise, and representable, but it assumes the norm itself. A system can therefore comply correctly with a discriminatory, incomplete, or otherwise harmful policy.

Compliance proofs may establish that a specified computation was executed correctly. They do not necessarily reveal whether inputs were complete or honestly selected, whether the policy is legitimate, or whether affected people can challenge the result. A zero-knowledge proof can verify computation over supplied inputs without proving that the inputs were accurate or complete.

Transparency-enhancing technologies instead preserve information for independent assessment. Tamper-evident logs, traceability mechanisms, input and output records, causal information, and user-accessible decision records can support reconstruction, discovery, expert analysis, cross-examination, and challenges to both system behavior and the underlying norm. Technical evidence is not equivalent to legal accountability: evidence can establish an event and preserve integrity, while legal processes interpret the event, assign responsibility, impose consequences, and provide remedies (Hicks, 2022).

Typed policy enforcement

“Policy as Type” represents the authorization proposition itself as a dependent type. A request can be modeled as:

$(\text{right},\ \text{accessor},\ \text{object},\ \text{environment})$

A conventional engine might return a Boolean decision, whereas a dependently typed system requires a term:

$p : \operatorname{Policy}(S,M,R,C)$

where $p$ is evidence that the request satisfies the policy. A protected operation can then require a dependent pair containing both a value and a proof about that value. A caller lacking the proof cannot invoke the operation without failing type checking (Fuchs, 2 Jun 2025).

This approach can encode access-control lists, role-based access control, relationship-based access control, and attribute-based access control. Its examples include age restrictions, parental permission, HTTPS transport, service approval, time-of-day limits, protocol restrictions, and transaction constraints.

The principal advantage is the integration of policy evaluation and policy-preserving execution. Rather than requiring application code to remember to check an authorization result before making a call, the protected function’s type requires authorization evidence. Runtime decision procedures can return Dec P, Maybe P, or a proof-bearing dependent pair when facts arrive from external systems.

The guarantee remains conditional. The type system cannot independently establish that an external age, approval flag, identity, or location is truthful. It proves that values are used consistently with their types and supplied evidence. Authentication, signed claims, trusted issuers, revocation, freshness, and external-state integrity remain necessary.

Protocol-governed implementations

Protocol-Driven Development defines a protocol as:

$\mathcal{P}=(\mathcal{S},\mathcal{B},\mathcal{O})$

where $\mathcal{S}$ contains structural invariants, $\mathcal{B}$ behavioral invariants, and $\mathcal{O}$ operational invariants (He et al., 13 May 2026).

Structural invariants constrain interfaces, schemas, field types, serialization, errors, versioning, and compatibility. Behavioral invariants constrain observable executions through properties such as determinism, idempotence, monotonicity, safe error propagation, and temporal consistency. Operational invariants constrain external calls, network destinations, filesystem access, dependencies, latency, memory, CPU, concurrency, secrets, and background activity.

The admissible implementation space is:

$\mathcal{I}_{\mathcal{P}}= \{I\in\mathcal{I}\mid I\models\mathcal{P}\}$

with:

$I\models\mathcal{P} \iff (I\models\mathcal{S}) \land (I\models\mathcal{B}) \land (I\models\mathcal{O}).$

This model treats generated code as a replaceable realization rather than as the durable source of authority. A Python policy, Rego-like evaluator, Rust service, or WebAssembly module may be substituted if it satisfies the same protocol.

PDD adds an Evidence Chain linking the protocol, implementation hash, validator identities and versions, validation results, environment, timestamps, provenance, and admission decision. Its Validator Loop separates protocol authoring, candidate generation, structural validation, behavioral validation, operational validation, evidence generation, admission or rejection, and deployment or replacement.

4. Policy authoring, synthesis, and lifecycle

Code-as-Policy systems vary in who writes the policy, how policy code is generated, and whether the policy is updated independently of model parameters or implementation code.

Declarative authoring for non-programmers

Pika provides a form-based interface for authoring executable governance policies in online communities. Its declarative language decomposes policies into base actions, filters, base procedures, decorators, and executions. A policy can govern an event such as channel renaming or private-channel membership, filter eligible actors and channels, apply consensus voting or a jury, and execute notifications or approved actions (Wang et al., 2023).

Pika compiles JSON specifications into Python policies executed by PolicyKit. The system supports consensus voting, juries, benevolent dictatorship, ranked voting, quadratic voting, liquid democracy, threshold moderation, role assignment, notifications, and membership operations. It is event-driven and does not directly support persistent state predicates evaluated at arbitrary times, such as inactivity over one month or a warning count exceeding a threshold.

The system illustrates an accessibility–expressivity trade-off. Non-programmers can configure existing components, but programmers remain necessary to extend the component library. The paper does not define explicit policy priorities, general conflict-resolution semantics, exception clauses, or a general appeal language.

Retrieval and tool-mediated generation

ARPaCCino demonstrates an agentic workflow for generating and validating Rego rules from natural-language descriptions. RAG supplies OPA, Rego, Terraform, and provider documentation; deterministic tools check syntax and evaluate policies; an external expert reviews semantic correctness; and the agent repairs Terraform when policy violations are detected (Romeo et al., 11 Jul 2025).

The system distinguishes policy representation, policy evaluation, and policy enforcement. In its Terraform case study, the workflow is:

$p : \operatorname{Policy}(S,M,R,C)$ 7

Its enforcement is primarily pre-deployment compliance gating and source-level remediation rather than runtime control after infrastructure provisioning.

Constrained synthesis

MACOG transforms natural-language infrastructure intent into a typed Infrastructure Intermediate Representation containing resource nodes, dependency edges, provider information, and effects such as encryption, least privilege, residency, redundancy, exposure restrictions, and budget limits. Terraform is then emitted using provider-aware constrained decoding. The generated artifact is round-tripped into an intermediate representation and compared with the intended graph (Khan et al., 4 Oct 2025).

MACOG’s agents separate architectural planning, provider harmonization, HCL realization, review, security proving, cost planning, deployment validation, and memory management. Its OPA policies are externally supplied rather than generally synthesized for each request. The principal output is Terraform code accompanied by policy traces, validation results, deployment logs, and related evidence.

TerraFormer follows a different route. It creates policy-annotated natural-language-to-Terraform and Terraform-mutation datasets, uses Rego policies during dataset validation, and optimizes generation with verifier-derived rewards. Its work is therefore policy-guided synthesis rather than a complete end-to-end transformation from natural-language policy to policy program to infrastructure (Jana et al., 13 Jan 2026).

Offline policy search

PolicySmith uses templates to constrain the program space. A caching template exposes object metadata, aggregate statistics, history, and a priority() function; a congestion-control template exposes kernel-visible state and the cong_control callback. The LLM generates candidates, checkers reject invalid code, evaluators measure performance, and high-scoring candidates become examples for later rounds (Dwivedula et al., 9 Oct 2025).

The framework is not reinforcement learning, does not deploy a neural policy for inference, and does not perform online policy synthesis. Its principal learning signal is evaluator performance combined with compilation and checker feedback. This makes it closer to LLM-guided genetic programming or program search than to runtime agentic Code-as-Policy.

Function-level reuse and repair

FCGraft addresses two problems in fully generative embodied policies: repeated prefill computation over long prompts and reliability failures caused by unconstrained decoding. It stores validated functions together with their textual interfaces and Transformer key-value caches. New programs retrieve relevant interfaces, generate task-specific compositions, link validated implementations, and patch only localized erroneous regions (Chun et al., 11 Jun 2026).

Its two-tier cache is:

$\mathcal{H}=(\mathcal{I},\mathcal{C})$

where $p : \operatorname{Policy}(S,M,R,C)$ 0 stores function interfaces and $p : \operatorname{Policy}(S,M,R,C)$ 1 stores validated implementations. Stitching composes cached function structures into a new policy, while patching preserves a prefix and suffix and regenerates only an error region. This improves latency and reduces the need to regenerate known-good control logic, but cache compatibility remains operational rather than formally proved.

5. Embodied control and infrastructure governance

Two prominent application domains—embodied agents and infrastructure—illustrate how Code-as-Policy interacts with perception, execution, validation, and safety.

Embodied agents

The original embodied formulation maps:

$p : \operatorname{Policy}(S,M,R,C)$ 2

Generated code can select objects by color, category, ordinal, or spatial relation; compute positions, offsets, averages, distances, and trajectories; invoke manipulation or navigation primitives; and use for or while loops for sequencing and feedback (Liang et al., 2022).

RoboPro extends this approach with direct visual grounding. It uses SigLIP-L, a two-layer adaptor, CodeQwen-1.5-7B-Chat, and an API library whose implementations rely on GroundingDINO, AnyGrasp, motion heuristics, ROS, and robot controllers. Video2Code uses DROID videos, Gemini-1.5-Flash, and DeepSeek-Coder-V2 to construct approximately 115,000 runtime-code examples from video-derived plans (Xie et al., 8 Jan 2025).

CaP-X demonstrates that performance depends strongly on human-crafted abstractions, usage examples, temporal interaction, and perceptual representation. High-level APIs and privileged state improve reliability, while low-level APIs expose a larger program-search problem. Multi-turn execution feedback, visual differencing, automatic skill synthesis, ensembling, and reinforcement learning can recover part of the performance lost when designer scaffolding is removed (Fu et al., 23 Mar 2026).

RL-GPT provides a complementary decomposition. GPT-4 generates high-level code and temporally abstract actions, while PPO learns visually grounded and reactive behaviors. Generated code can therefore become part of the RL action space rather than serving only as a final controller (Liu et al., 2024).

The principal limitations are dependence on perception and API design, brittle object grounding, invalid or unsafe code, incomplete recovery, latency, and weak continuous feedback for contact-rich behaviors. Syntactic filters such as blocking imports, exec, and eval do not constitute physical safety guarantees.

Infrastructure and cloud governance

Infrastructure-oriented systems use Code-as-Policy to connect natural-language intent, Terraform or other IaC artifacts, policy engines, provider schemas, cost constraints, and deployment behavior.

MACOG creates typed resource graphs, uses constrained HCL decoding, checks schemas and references, evaluates OPA rules, estimates cost, runs Terraform validation and planning, and repairs failures using structured counterexamples (Khan et al., 4 Oct 2025). Its ablations identify constrained decoding, Security Prover feedback, and DevOps sandbox feedback as major contributors to benchmark performance.

TerraFormer combines supervised fine-tuning with verifier-guided GRPO. Its reward is staged:

zero for output that fails compilation;
$p : \operatorname{Policy}(S,M,R,C)$ 3 for compilable but undeployable output;
a value from $p : \operatorname{Policy}(S,M,R,C)$ 4 to $p : \operatorname{Policy}(S,M,R,C)$ 5 for deployable output, with the fractional component representing policy-rule satisfaction.

This creates a policy-guided optimization signal, but passing OPA proves only that the generated artifact satisfies the encoded rules. It does not establish satisfaction of every possible meaning of the natural-language requirement or successful live-cloud deployment (Jana et al., 13 Jan 2026).

The open-source adoption study finds that Policy-as-Code is primarily used for security governance and compliance governance. In its sample of 399 GitHub repositories and nine tools, Security Governance accounts for 65.4% of classified policy purposes and Compliance Governance for 21.3%. OPA dominates file-level usage, while OPA and Gatekeeper display strong co-usage (Foalem et al., 9 Jan 2026).

Satellite Mission Compiler demonstrates a ground-side domain-specific pipeline for mission plans. It validates YAML with Pydantic, evaluates ten OPA/Rego deny rules, compiles accepted plans into a typed WorkflowIntent, and renders Argo Workflow DAGs and Kueue Job manifests with Dynamic Resource Allocation support (Tsai et al., 16 Jul 2026).

Its architecture distinguishes schema validation, semantic policy evaluation, intermediate representation, and backend rendering. The separation prevents mission policy from becoming tied to a particular Kubernetes or Argo representation. The system is a compiler gate and admission pipeline, not an onboard autonomous planner or complete flight-safety case. Its policy rules cover mission identity, event presence, acquisition services, accelerator fallback, priority, download visibility, service steps, and recognized landscape types.

6. Governance, limitations, and research directions

The central controversy in Code-as-Policy is whether executable enforcement should be treated as sufficient governance. The research broadly rejects that equivalence.

Enforcement versus legitimacy

A system can execute a rule correctly while applying an unjust, incomplete, or defective policy. In the Post Office Horizon case, accounting output was treated as a presumption of subpostmaster responsibility while known error information remained undisclosed. In the Uber case, automated fraud classifications could convert biased ratings, facial-recognition errors, or inaccurate data into loss of employment and income. These cases show why execution correctness is insufficient without transparency, evidence access, contestability, and remedies (Hicks, 2022).

Pika similarly demonstrates that making policy authoring accessible does not establish that the resulting governance is legitimate, fair, safe, or democratically accepted. A declarative interface can conceal implementation behavior, component interactions, privilege assumptions, and policy conflicts (Wang et al., 2023).

Incomplete specifications and validators

All verification mechanisms are relative to their specifications and observation models. OPA checks only encoded predicates. Terraform planning checks provider-visible deployability but not every runtime property. Type systems prove relationships among typed values but cannot independently authenticate external facts. Property-based tests provide evidence over tested properties without necessarily proving completeness. Signed evidence establishes that a validator reported a result over particular artifacts, not that the validator was complete or the policy itself was correct (He et al., 13 May 2026).

Policy-guided synthesis also faces correlated errors. When a LLM generates the natural-language prompt, Terraform configuration, and Rego policy, the same modeling assumptions may affect all three artifacts. A configuration can pass a generated policy that omitted an important requirement.

Human oversight and contestability

Contestability can concern facts, system operation, classifications, the norm itself, the accountability mechanism, and the consequence. A user-centered accountability model asks whether affected people know that a system acted on them, can obtain relevant records, can challenge inputs and classifications, can challenge the norm, and can obtain correction, reversal, compensation, or appeal.

Transparency is not automatically accountability. Disclosures may be unusable without resources, expertise, legal standing, institutional authority, or remedies. Logs can also create privacy risks. The useful design objective is therefore not unlimited disclosure but appropriately accessible, privacy-preserving evidence.

Safety and operational boundaries

Generated policy and control code should be treated as untrusted until validated. Relevant safeguards include sandboxing, capability restrictions, static and formal checks, schema validation, collision and workspace limits, resource budgets, timeouts, watchdogs, human approval for high-impact actions, versioned diffs, rollback, and independently maintained evidence.

PDD makes this separation explicit through operational invariants. Code-as-Policy systems should not allow a policy implementation to define its own permissions, bypass its policy engine, access unauthorized secrets, or make unapproved external calls. Admission of a policy implementation is distinct from runtime authorization of a particular action.

Policy evolution and conflict

Policy evolution introduces versioning, migration, refinement, rollback, revocation, in-flight requests, cache invalidation, and compatibility problems. Strengthening a protocol should narrow the admissible implementation space:

$p : \operatorname{Policy}(S,M,R,C)$ 6

Most systems do not yet provide complete semantics for policy priorities, exceptions, overrides, conflict resolution, or composition. Pika does not define general precedence among policies. Multi-tool Policy-as-Code deployments can duplicate rules or produce inconsistent decisions. Infrastructure systems may face conflicts between security, cost, availability, regional, and provider constraints. These issues require explicit policy-composition models rather than informal conventions.

Open research directions

Important research questions include:

Policy semantics: How can natural-language requirements be translated into formal, reviewable, and behaviorally complete policy specifications?
Policy compilation: Can one prove that generated policy code preserves the semantics of a declarative policy or protocol?
Conflict resolution: How should policies be combined through priority, specificity, deny-overrides, constraint intersection, negotiation, or explicit human choice?
Evidence and provenance: How can systems prove that deployed enforcement points correspond exactly to the artifacts that were validated?
Runtime correspondence: How can pre-deployment admission guarantees be connected to changing runtime state, credentials, resources, and environmental conditions?
Policy effectiveness: Which empirical measures distinguish the presence of policy files from reductions in security incidents, misconfigurations, compliance failures, cost overruns, or unsafe behavior?
Human contestability: How can affected people obtain understandable evidence and effective remedies without requiring extraordinary technical expertise or collective litigation?
AI and MLOps governance: How should policies govern models, datasets, prompts, training, inference, fairness, provenance, and regulatory evidence?
Hybrid control: How should symbolic code, neural policies, formal constraints, perception systems, and learned repair interact in embodied environments?
Cross-domain portability: What intermediate representations and decision formats can support interoperability among Rego, Kyverno, Sentinel, Cedar, typed policy systems, infrastructure compilers, and agent-control frameworks?

Code-as-Policy is therefore best viewed as a family of architectures rather than a single technique. Its strongest implementations combine executable rules with independent validation, explicit interfaces, evidence, capability restrictions, human oversight, and lifecycle governance. The durable control boundary is not code alone. It is the combination of policy intent, formal or executable semantics, enforcement context, verification assumptions, provenance, contestability, and the institutional authority to act on violations.