3.3 Constraints, Sensors, Validators, and Gates

MAGE uses four roles to describe how environmental authority operates. A mechanism may constrain an action, sense the state or result of work, validate the resulting evidence against an obligation, or gate whether the work may advance. One artifact often plays several at once; the four remain useful because they separate four moves that one tool may blur together: 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 gives the verdict consequence.

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 carries authority 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 and produces evidence. It lets the move happen and reads the evidence back out after the fact — actual = observe(system). A raw sensor only produces evidence: a log line, a trace, a metric, or a scan of the calls present in the code. It does not decide whether what it saw is good or bad — that judgment belongs to the validator. 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.

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, downstream authority cannot 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 CITE0. 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 vocabulary deliberately echoes control engineering: constrain admissible behavior, observe state through sensors, compare evidence against a desired condition, and act on the result. The inheritance is an analogy, not an identity — an agent fleet is not a linear control system. What carries over is the closed-loop engineering posture. Leveson's systems-theoretic safety work provides a nearby precedent ²2. 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 authority 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 act on 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.

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

3.3.3 Validators and Gates

The other two roles act at the loop's closing door. 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 authority comes not from itself but from what the environment does with its verdict. A correspondence validator can hold authority over agreement without making either representation authoritative for execution: DocAble's remediation-graph parity check blocks drift between the projected computation graph and the typed pass declarations, even though those executable declarations remain upstream of the graph the check reads.

A gate supplies that consequence. 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. Giving a validator's verdict gating authority is a commitment. Giving an uncertain validator blocking authority converts its false positives into rejected work or outages.

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 Authority 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 authority 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 consequence 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 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 authoritative mechanism merely by existing or by appearing in an agent's context. Authority 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 gives it authority.

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 authority.

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.