Mechanistic Boundary

This file captures the active §10 chapter draft context assembled on 2026-06-06, reconciled 2026-06-19 to add the Operational Questions opener and update the composition clauses to the drafted prerequisites (ZTG-0a–0e) and ZTG-2. It is a working draft, not final publication copy.

The Mechanistic Boundary is the first system invariant (ZTG-1 through ZTG-5). It specifies the deterministic separation between reasoning and irreversible action — the structural point through which every model-derived action must pass to become an effect in the world.

Operational Questions

ZTG-1 is mapped, with ZTG-3, to execution-boundary enforcement: where synthetic reasoning stops and materially consequential execution begins. ZTG-1 is the gate every proposed action must pass through; ZTG-3 (Governed Effect Surface) is the closed set of channels there are to act through. Together they answer the boundary question in full — ZTG-1 mediates every action, and ZTG-3 guarantees there is no unmediated way to act. ZTG-1 also conditions replayability and evidence coupling: every boundary decision is recorded (ZTG-0a), reproducible (ZTG-0b), and, where it authorizes an effect, coupled to that effect's evidence (ZTG-4).

Normative

A deterministic boundary MUST separate reasoning from irreversible action. The boundary exists in code, not in policy interpretation, intent reconstruction, or post-hoc evaluation. It is architectural rather than procedural. Its operation does not depend on any property of the reasoning system whose outputs it gates.

No component within the governed system may bypass, reinterpret, defer, or negotiate the boundary at runtime. The boundary is not a service the reasoning system requests authorization from; it is the structural separation through which the reasoning system's outputs must pass to become actions.

Authorization MUST occur before irreversible action. An architecture in which actions execute speculatively and are evaluated for authorization in parallel, with rollback if authorization fails, does not satisfy ZTG-1 for irreversible actions. Speculative execution of irreversible actions is irreversible execution.

No action derived from model output may execute without explicit structural approval. Authorization is not inferred from context, derived from absence of denial, or implied by continued operation. The architecture's default disposition toward any model-derived action is refusal; authorization is the explicit grant that converts refusal into permission.

Boundaries are code-enforced, not intent-interpreted. The architecture does not reason about what the model meant, what a reasonable agent would do, or what the model should be permitted to do given context. It evaluates the proposed action against policies in effect and produces a deterministic decision.

Boundary Composition

With ZTG-0a (Observability). The boundary's operation MUST be fully observable. Every authorization decision — grant, refusal, and escalation alike — is recorded with decision-level fidelity (inputs, policy version, identity, decision-time, verdict, and action taken), and those records carry ZTG-0a's intrinsic tamper-evidence. Recording only grants, or treating refusals as unrecorded, does not satisfy ZTG-0a.

With ZTG-0b (Replayability). Boundary decisions MUST be replayable. Given the same recorded inputs, the same policy version, and the same pinned evaluation-engine semantics, the boundary MUST reproduce the same verdict. Replay reconstructs the verdict and never re-emits the effect. Non-deterministic boundary behavior violates ZTG-1.

With ZTG-0c (Temporal Integrity). Boundary decisions occur at a single decision-time, established from a trusted time source the reasoning system does not control, against a coherent point-in-time snapshot of governance state. The boundary MUST NOT evaluate against stale policy, future state, or temporally inconsistent inputs.

With ZTG-0d (Identity Integrity). Authorization at the boundary requires attributable authority. Every recognized authorization traces, through its delegation chain, to a human or institutional ratifying principal, bound by non-repudiable, revocable credentials satisfying ZTG-0d. The reasoning system holds no authorizing identity.

With ZTG-0e (Governance Consistency). The boundary MUST operate against a single consistent view of governance state, agreed across enforcement points and applied atomically. During governance-state inconsistency, the boundary MUST refuse authorization.

Memory Subsystem Interaction

Memory subsystems may inform boundary evaluation, but memory contents MUST NOT bootstrap policy authority. Memory contents are inputs to evaluation, not sources of additional policy.

The boundary MUST NOT recognize memory-resident content as authorizing, declaring exceptions, or modifying policy. Memory-to-policy elevation is governed by the relevant memory subsystem specification, outside ZTG. ZTG specifies that elevation must occur through an explicit promotion protocol rather than implicit interpretation.

This matters because memory contents are typically writable by the same model whose outputs the boundary gates. Accepting memory-resident content as authorizing creates a path for the model to author its own authorization.

Boundary Scope

The boundary applies to all actions producing externally observable effects. The scope includes obvious cases and less obvious cases:

• Reads from external systems whose access pattern itself signals the target.
• Internal state changes whose visibility extends beyond local reasoning scope.
• Resource consumption patterns observable beyond the reasoning system.
• Speech-to-user output where receipt of communication has consequences.
• Memory writes consulted by other systems.

Scope determination is conformance-relevant. An implementation enforcing the boundary on only a subset of supported effectful actions does not satisfy ZTG-1.

Boundary Integrity

The boundary's integrity requires:

• Boundary code separately auditable from reasoning-system code.
• Policy evaluation in a context the reasoning system cannot influence.
• Decision communication to the action surface through a channel the reasoning system cannot intercept or modify.
• Audit emission atomic with the decision through a path the reasoning system cannot affect.

The boundary is a separate architectural component, operating in isolation from the reasoning it gates.

Further Considerations

Boundary as architectural primitive. The Mechanistic Boundary is not a service the governed system uses when it wants to behave responsibly. It is the structural separation through which actions must pass. This mirrors imaginative-to-executive separation in biological cognition: imagination does not optionally invoke a review function; outputs cannot reach motor execution without traversing executive function.

Speculative execution and the boundary. Speculative execution of irreversible actions is irreversible execution. Implementations supporting speculative execution must restrict it to actions whose ZTG-5 harm class is Restorable and whose computed assessment is below thresholds where stratification applies. Gradient speculation, partial commits, and optimistic concurrency with compensating actions are non-conforming for Irreversible-class actions regardless of performance benefits.

Defining what counts as external to the model. The boundary presupposes a definable distinction between model and external action. Token streaming, tool use mid-generation, and memory writes can make the distinction subtle. Implementations should declare their externality boundary explicitly and apply it consistently. The conservative choice is to treat any output crossing an architectural component boundary as external.

Borderline side effects. Cache changes, internal parameter updates during inference, logs consumed by other systems, and observable resource-allocation patterns may be internal operations or boundary-relevant actions depending on implementation context. Implementations should produce explicit determinations for each borderline operation type and document them as part of conformance verification.

Model architecture interaction. Mid-generation actions are still actions. Architectures executing tool calls within inference context, without boundary involvement, are not ZTG-1 conformant. Tool-call proposals must route through the boundary before invocation.

Performance and the temptation to relax. Boundary evaluation introduces latency. Caching authorization decisions across requests, bypassing the boundary for "obviously authorized" actions, or using reduced evaluation paths are non-conforming. Performance constraints must be addressed by preserving the discipline: scaling boundary capacity, authorized batching, pre-computation, or optimization within the evaluation path.

Adversarial inputs and boundary robustness. The boundary cannot be more robust than the inputs it evaluates. Input sanitization is handled by composition requirements, especially the Input Sanitization Boundary in §18. ZTG-1 specifies structural boundary properties and depends on composing requirements for input handling.

Boundary semantics across action classes. Boundary discipline does not vary across action classes, but consequences do. ZTG-5 may impose stricter gate requirements for Irreversible or over-threshold actions. The boundary's discipline of complete mediation, deterministic evaluation, and audit emission remains uniform.

Boundary and Stasis interaction. During Stasis (ZTG-2), the boundary becomes more restrictive, not less: Stasis is the state in which no new authority is granted, so the boundary grants nothing while held. The boundary refuses authorization when the system cannot guarantee invariants hold. Operational pressure to bypass during Stasis is expected; refusal is the architecture functioning as designed.

How We Do It

Constable implements the Mechanistic Boundary through architectural separation between the agent loop and the execution surface. The policy evaluation gate is structurally placed between these layers, with no path from agent to execution that does not traverse the gate.

The execution gate. Constable's gate is separate from the agent runtime. It runs in its own process boundary, evaluates policies using OPA/Rego, and communicates decisions to the action surface through a channel the agent runtime cannot intercept. The gate's code is separately auditable, deployed, and versioned from the agent code.

The gate evaluates one action at a time. Each evaluation is atomic with respect to policy state. The result is a verdict (authorize, refuse, escalate) bound to the specific action, policy version, and timestamp.

OPA/Rego as evaluation surface. Constable uses OPA with Rego policies. OPA provides deterministic policy evaluation with policy code that is auditable, version-controlled, and replayable. Rego's evaluation model is decidable and side-effect-free. Other policy languages with equivalent properties can also be conforming implementation choices.

Integration with Airlock. Constable composes with Airlock for input sanitization. All policy-evaluation inputs route through Airlock normalization before reaching the evaluator. The gate accepts only Airlock-processed inputs.

Memoria promotion gate. Constable composes with Memoria through Memoria's promotion gate. Raw memory contents are not visible to policy evaluation. Memory contents consulted by policy must be promoted through explicit protocol requiring named human attestation.

Tool call routing. Constable routes tool calls produced during inference through the execution gate before invocation. The model produces tool-call proposals; the gate evaluates them; only authorized proposals invoke tools.

Performance optimization within discipline. Constable preserves boundary discipline while improving latency through policy pre-compilation, parallel evaluation of independent policies, input caching at the normalization boundary, and audit emission batching where durability is preserved. Authorization decisions are not cached across requests.

Conformance verification for ZTG-1. Constable's internal testing includes:

• Path analysis verifying no agent-to-execution bypass.
• Replay testing for identical decisions from identical inputs.
• Adversarial input testing under malformed and ambiguous inputs.
• Tool-call interception testing.
• Memory-bypass testing.
• Stasis interaction testing.
• Performance testing verifying discipline under load.

The testing protocol is documented separately in the conformance verification specification referenced in §22.

Draft Flags

• Composition clauses reconciled 2026-06-19 to the drafted prerequisites: the ZTG-0a clause now requires refusals/escalations and intrinsic tamper-evidence; ZTG-0b adds pinned engine semantics and no-re-emit; ZTG-0c adds the trusted time source and point-in-time snapshot; ZTG-0d adds terminal ratifying-principal attribution and non-repudiable credentials; ZTG-0e adds cross-enforcement-point agreement and atomic application. This closes planning/section-10-composition-clause-updates.md.
• §18 Input Sanitization Boundary is referenced but not captured in this workspace yet.
• §22 Conformance Verification is referenced but not captured in this workspace yet.
• The chapter is substantively strong but likely needs final tone calibration for publication register.