3.3 Constraints, Sensors, Validators, and Gates

Environmental enforcement follows a familiar engineering pattern: restrict admissible behavior where possible, observe what occurs, evaluate the resulting evidence against a desired condition, and enforce the verdict. Part II made properties explicit and showed how models can be analyzed for the questions they represent. Alignment must additionally connect those properties to the realized system. A mechanism may observe or derive evidence from the implementation, evaluate that evidence against an obligation, and control admission based on the resulting verdict. MAGE separates these functions into four roles: constraint, sensor, validator, and gate. A mechanism may perform several roles at once; the distinction separates prevention, observation, judgment, and admission.

Governance mechanism. A repeatable structure in the engineered environment through which Alignment constrains work, produces evidence, evaluates evidence, or controls admission.

The four roles are:

• Constraint — removes or narrows an action or state the system is allowed to express.
• Sensor — observes the work or system and produces evidence.
• Validator — evaluates evidence against an obligation.
• Gate — controls whether work may cross a boundary.

Implementations often bundle several roles.

The four split into two pairs. Constraints and sensors concern the work or system state: one restricts what may occur, the other observes what did occur. Validators and gates concern decisions over evidence: one evaluates the evidence, the other enforces the verdict.

3.3.1 Prevention and Observation

On the work-facing side of the loop, the two complementary moves are prevention and observation; Figure 3.3-1 draws the split. A constraint restricts what may occur; a sensor observes what did occur. Prefer a constraint where the unwanted action or state can be excluded cheaply and reliably. Otherwise, expose enough evidence for the obligation to be evaluated at an appropriate boundary.

An instruction is enforced only when a mechanism in the environment acts on it. If a brief must contain a required section, check for that section before launch and refuse the launch when it is absent.

A sensor observes what happened and produces evidence: actual = observe(system). It does not judge; a validator decides whether that evidence satisfies the obligation. When observation exposes a correctable violation after the fact, repair costs an additional iteration. That makes prevention attractive where the unwanted state can be excluded cleanly; many important properties, however, can only be observed.

A CI test suite often bundles three roles: executing the code produces evidence, checking the result validates it, and failing the build gates progress. One artifact can perform several roles without collapsing the distinction among them.

The use of explicit evidence to justify consequential engineering claims also has a substantial history in safety and assurance engineering. Safety cases and the broader assurance-case tradition organize claims, supporting evidence, assumptions, and argument so that acceptance does not rest on an unsupported assertion that the system is safe.¹1. Timothy Patrick Kelly, “Arguing Safety—a Systematic Approach to Managing Safety Cases” (Doctoral dissertation, 1998). ²2. Adelard, “The Adelard Safety Case Development Manual,” 1998. MAGE inherits that concern but separates several roles that an assurance argument may connect: what evidence the system produces, what evaluates that evidence, and whether and how the resulting judgment is enforced. An argument can justify a claim without itself controlling the system; Alignment asks when the surrounding engineering environment should enforce the obligation represented by that claim.

A sensor is only as good as the signal it can read. Observability means that a running system exposes enough signal to explain what it did and what went wrong. Observability supplies the loop's evidence path: the relevant state or event must be exposed in a form a sensor can read. A gate can act only on evidence available at its boundary, whether produced earlier or derived there. That may be the event a gate fires on, the log a checker reads, or the trace that turns "the build failed" into "the build failed here, for this reason." If the evidence an obligation requires does not exist, no downstream mechanism can recover it; the environment must first instrument the relevant state or event.

A constraint removes an unwanted action or state from the admissible space. Unlike a sensor, which observes the resulting state after the fact, a constraint makes the prohibited move unavailable through that mechanism. Closed representations are the cleanest example. A lifecycle encoded as arbitrary strings admits values the design never intended, and a mismatch surfaces only an iteration later, when the test suite crashes. Encode it as a closed enumeration instead and the compiler rejects any value outside the declared set on the spot. The enum does not watch for the illegal state later — it removes that representation from well-typed code, and no iteration is spent catching it. Where the valid action or representation space is naturally closed, MAGE prefers representations that exclude invalid members structurally.

Programming-language theory made this move systematic: choose a representation or type discipline in which some invalid programs cannot be written as well-typed terms.^** Benjamin C. Pierce characterizes type systems as syntactic methods for classifying program phrases so that classes of erroneous behaviors can be ruled out automatically ³3. Benjamin C. Pierce, Types and Programming Languages (MIT Press, 2002).. MAGE generalizes the engineering preference rather than the formalism: where practical, restrict the action or representation space so the bad state cannot be produced, instead of detecting it again on every later iteration.

A footnote on control engineering. The decomposition echoes the closed-loop posture of control and systems-safety engineering without treating an agent fleet as a control system. See Leveson 2011 ⁴4. Nancy G. Leveson, Engineering a Safer World: Systems Thinking Applied to Safety (MIT Press, 2011)..

Human processes can play the same roles: logging senses, review validates, and approval gates. Human judgment remains necessary. Repeated, mechanically decidable judgments are candidates for durable structure.

The sharpest instance of the pair is ownership of a unit of work. DocAble's in-flight lease makes active ownership visible and lets apparently abandoned work become recoverable. The lease does not itself grant final permission to perform the consequential side effect. A durable compare-and-set supplies that constraint: competing claimants cannot both acquire it, so at most one performs the effect. The lease may expire because a worker is merely slow, so redelivery cannot imply permission to repeat the effect. Recovery is not permission.

3.3.2 One Obligation, Several Ways to Hold It

A modeled obligation does not imply one particular enforcement technology. Ask first what kind of property it is and where the environment can enforce it.

If an invalid state can be removed from the action space, prefer the constraint. DocAble's work-item claim is the simple case: a database compare-and-set updates the row only while it remains in the expected prior state. Two competing claimants cannot both win the same transition. The ownership obligation is therefore carried by the runtime primitive itself rather than by a later checker.

Other properties live across sequences of otherwise legal actions. The in-flight lease is one example. Reclaiming a stale lease, issuing a new epoch, and receiving a late release from the previous holder are each individually plausible events; their interleaving can still violate the ownership invariant. Here the environment needs a validator that can reason over the composed state space. DocAble uses a small, purpose-built model checker: an executable transition model enumerates the reachable interleavings within explicit bounds and searches them for violations of the ownership invariants.^†† More precisely, this is bounded explicit-state model checking. "Bounded model checking" conventionally refers to bounded executions encoded for SAT/SMT solving; DocAble's checker exhaustively explores an explicitly bounded state space instead. The checker is deliberately specialized to the protocol. For this small protocol, a purpose-built checker keeps the method close to the model and avoids unnecessary tooling.

Temporal obligations require another shape of evidence. "No two workers own the same claim" is violated by one reachable bad state. "Every submitted job eventually terminates" is not. A finite trace can show progress, but it cannot establish that every fair execution eventually reaches a terminal state. A temporal model checker can reason about that stronger claim.

These are not levels of sophistication. They are different matches between property and mechanism. The engineering preference remains the same throughout MAGE: make the bad state impossible when you can; otherwise produce proportionate evidence that an appropriate evaluator can use to decide the obligation. Figure 3.3-2 sets the three matches out.

PROGRAMMING LANGUAGES

Inset — Synthesizing the Guardrail

Hard controls raise an obvious scalability question: who builds all of the checkers? The simplest answer is the same one we have used throughout this book: work with the agent. Once an invariant is explicit, an agent can help translate it into executable checks—linters, schema constraints, architectural tests, static-analysis rules, or mappings from model concepts to implementation artifacts. The engineer remains responsible for the invariant and for validating that the resulting mechanism actually enforces it, but need not hand-code every guardrail.

There is a stronger version of this idea. A static analysis can itself be represented with degrees of freedom: specify what property the analysis should establish while leaving choices about how to perform the analysis open. Recent work has proposed self-adaptive static analysis, in which the analysis representation admits automatic optimization for the particular program and analysis. The aim of such methods is to generate precise and efficient analyses through self-aware, self-optimizing, sound analysis machinery—automating the realization of the control without making its enforcement probabilistic.⁵5. Eric Bodden, “Self-Adaptive Static Analysis,” in “Proceedings of the 40th International Conference on Software Engineering: New Ideas and Emerging Results,” special issue, Proceedings of the 40th International Conference on Software Engineering: New Ideas and Emerging Results (New York), ICSE-NIER '18, 2018, 45–48, https://doi.org/10.1145/3183399.3183401. ⁶6. Eric Bodden, Self-Optimizing Static Program Analysis (SOSA), ERC Advanced Grant 2023 Research Proposal, Part B1 (2023).

This is the same modeling move applied recursively. The obligation enforced by the guardrail is fixed; the implementation of the guardrail need not be. Rather than asking an agent to probabilistically judge whether generated code satisfies an obligation, automation can help construct and optimize the mechanism that checks it. As implementation becomes cheaper, verification need not remain artisanal. The factory can help build its own guardrails.

Whichever validator supplies the judgment, the enforcement still depends on what the environment does with its verdict.

3.3.3 Validators and Gates

The other two roles act on evidence and admission. A validator turns evidence into a judgment: does the observed call graph contain only permitted edges, did this journey establish its post-condition, does the provenance record account for every mutation? It reads the evidence a sensor produced — or derives it straight from the artifact — and asks whether it satisfies the obligation. A validator may be deterministic, probabilistic, or human; its verdict affects admission only when the environment acts on it. A correspondence validator can enforce agreement without making either representation govern execution. DocAble's remediation-graph parity check blocks drift between the projected graph and typed pass declarations even though the executable declarations remain upstream.

A gate enforces the verdict. It decides whether the work may cross a boundary: commit, merge, deploy, execute, close, or draw on a scarce resource. Validation and gating are separate design decisions. A cost ceiling can be measured and evaluated without blocking production; a security invariant may deserve immediate refusal. Wiring a validator's verdict into a gate is a commitment. Making an uncertain validator blocking converts its false positives into rejected work or outages.

CAVEAT

Enforcement is conditional

A mechanism can guarantee only the property it actually governs, under the assumptions on which its evidence and implementation depend. A validator can faithfully enforce the wrong obligation; a model can omit a consequential distinction; a sensor can fail to observe the relevant state. Hard control therefore does not mean "the system is correct." It means that, within a stated scope, acceptance no longer depends on the agent voluntarily satisfying that obligation.

A loop may re-derive evidence at a later admission boundary rather than rely on the producing agent's self-report or on an earlier marker.^‡‡ Re-derivation trades additional computation and latency for stronger assurance that the evidence corresponds to the artifact or state being admitted. Reusing or caching an earlier result can be a sound optimization when the system can establish that the relevant inputs have not changed; the optimization should preserve that correspondence rather than merely assume it. Re-derivation can strengthen independence and freshness: the later mechanism evaluates the artifact or state that is actually being admitted. DocAble's definition-of-done audit takes this approach, recomputing its evidence at close rather than relying on evidence produced earlier in the task. The principle is simpler than the implementation choice: the thing asking to pass does not get to define what counts as having passed.

3.3.4 One Measurement, Different Enforcement Decisions

The four roles are not stages of maturity. DocAble's GenAI cost-and-usage model makes the point. Related measurements from the same model can support different enforcement decisions, and Figure 3.3-3 fans them across the roles. Usage is continuously sensed. Capacity signals can adapt request behavior. Exhausting a per-job budget can produce soft completion rather than outright rejection. A hard daily-budget gate exists but is dormant unless configured. One quantitative model can support observation, adaptation, graceful degradation, or hard admission control. The appropriate response depends on the obligation attached to the quantity, not on the supposed maturity of the environment.

A quantitative tolerance can also expose margin. If a value remains inside its acceptable bound, margin describes the room between the realized value and that boundary. A request completing in 120 ms against a 200 ms ceiling has 80 ms of margin. That information can matter before conformance fails: two realizations may both satisfy the same obligation while one operates much closer to its boundary and therefore has less room to absorb variation or future change.

That calculation is easy only when the model supplies a meaningful distance to the boundary. Quantitative obligations often do: latency, memory use, throughput, or cost can be compared directly with a declared bound. Many software obligations are qualitative instead. A dependency may cross a forbidden architectural boundary or remain within the permitted graph; a transition may be legal or illegal. Some such obligations admit useful notions of distance from failure, while others do not. MAGE therefore uses margin where the model provides a meaningful measure; it does not assume that every tolerance does.

3.3.5 Positive and Negative Constraints

Constraints are often introduced as prohibitions: this code must not call that library. DocAble's provenance machinery demonstrates the complementary form. Every typed mutation verb is required to emit attribution. A source-time rule checks that the required call is wired into the mutation path. Figure 3.3-4 sets the two forms side by side: one mechanism removes a forbidden action; the other requires evidence-producing behavior.

3.3.6 Provenance-Carried Admission

Earlier in this Part, architectural conformance provided one example of enforcing intended relations. Provenance is useful for a particular version of that problem: the required relation concerns not merely which components interact, but the path through which a protected operation was derived.

Some obligations are cheap to enforce by controlling access to a recognizable primitive. Filesystem and network access are examples. The environment can identify the APIs that perform those effects, designate the small portion of the system permitted to use them, and reject other callers with comparatively simple static analysis. The prohibited interaction has a recognizable surface.

Other architectural obligations do not have such a convenient boundary. Suppose all color decisions must pass through a canonical color model before document mutation. The unwanted alternative is not necessarily a call to one forbidden API. A future implementation may combine otherwise legitimate resolvers, representations, and mutation APIs into a new path that reaches the same protected operation. Each call can be legal, and the path may not match any bypass anticipated by a source-time rule.

This matters in agentic engineering because agents readily invent new ways to interact with a system. A prohibition against yesterday's bypass need not prohibit tomorrow's variation. Enumerating forbidden routes can therefore become an open-ended enforcement strategy.

Provenance can reverse the enforcement problem. Instead of trying to recognize every way an operation might have bypassed the sanctioned abstraction, require the protected operation to carry evidence that it passed through that abstraction.

The sanctioned abstraction can issue an opaque provenance value that ordinary callers cannot construct. The admission boundary then admits the operation only when that provenance is present and valid:

Figure 3.3-5 traces the single sanctioned path: an operation reaches the protected boundary only by deriving through the sanctioned abstraction, which supplies the provenance the boundary demands.

An agent remains free to invent new internal implementations, but invention does not create a new route around the obligation. A newly synthesized path that bypasses the sanctioned abstraction arrives at the boundary without valid provenance and is refused. Enforcement therefore depends on recognizing the allowed derivation, not enumerating all possible forbidden derivations.

That distinction suggests when the pattern is useful. If protected interaction occurs through a small, statically recognizable primitive surface, restrict that surface directly; simpler mechanisms are preferable. Provenance becomes attractive when the obligation concerns how an otherwise ordinary operation was derived, and alternative derivation paths are numerous, compositional, or difficult to identify cheaply from source.

The pattern is therefore not principally about attribution. It is a way to make a derivation path the sanctioned route to admission. A source-time rule can require known sanctioned implementations to emit provenance; the admission boundary can additionally require every protected operation to possess provenance that only the sanctioned path could have produced. The two controls address opposite sides of the relation: one checks known producers; the other refuses unknown routes to the consumer.

The rule of thumb is short. When the forbidden paths are enumerable, ban them. When the allowed path is easier to characterize than all possible bypasses, have the allowed path issue the provenance required at the boundary.

Generative implementation sharpens the choice. An agent is unusually capable of exploiting degrees of freedom left open by the engineered environment, including finding valid implementation paths its designers did not anticipate. A blacklist of forbidden routes therefore becomes systematically less attractive as the space of possible realizations grows.

Provenance-carried admission removes a particular degree of freedom: a protected operation must derive from the sanctioned source or path. Other implementation choices can remain open, but an agent cannot invent a new source of that operation and have it admitted merely because the resulting value is otherwise valid. The environment need not enumerate those alternative realizations; the admission boundary requires provenance that only the sanctioned derivation can supply.

This is a graph-shaped variation on architectural enforcement. Layering constrains which components may interact across a layered structure. Provenance-carried admission instead constrains a particular derivation through an otherwise richer interaction graph: many implementation paths may exist, but only a path through the sanctioned node can produce an operation permitted to cross the admission boundary.

3.3.7 What Counts as a Mechanism

Keep policy, guidance, and governance mechanism separate. A model file can state policy; a playbook can guide an agent; neither becomes an enforcing mechanism merely by existing or by appearing in an agent's context. Enforcement begins when something in the environment actually constrains the work, produces evidence, evaluates that evidence, or controls admission. The model states the obligation; the consuming mechanism enforces it.

The same artifact can play several roles. A structured model injected into context guides reasoning. A validator reading that same model uses it as the obligation against which observed code is judged. A generated permission table turns the same modeled relation into a constraint. The model is the representation; the consuming machinery supplies the enforcement.

Implementations routinely bundle roles. A test runner may sense, validate, and gate; a narrow interface may constrain while emitting provenance. Name the functions inside the bundle rather than stretching every influence into a "soft constraint" or "soft sensor."

Some mechanisms can be designed before the first autonomous change; others become visible only after the environment fails. The next chapter shows how those failures become durable structure.