Inference-Time Semantic Execution Control

1. Problem and architectural premise

Contemporary AI safety architecture treats inference as a generative event followed, optionally, by correction. A model produces a candidate output, and a chain of post-hoc components — output classifiers, content filters, heuristic rule engines, refusal detectors, retrieval-augmented verification, watermarking, and human review — attempts to determine whether the output should be allowed to leave the system. This pattern is structurally committed: by the time post-hoc evaluation runs, the inference has already been performed, the semantic transition has already occurred inside the model's internal state, and any side effects coupled to the generation pathway (logged tokens, cached state, downstream agent triggers, tool invocations issued mid-generation) have already executed.

Runtime guardrails — the second-generation response — push some of this checking earlier, into the decoding loop or into wrapper layers around the model API. They are still architecturally downstream of the decision to generate. A guardrail evaluates a candidate token, span, or completion against rules, and either lets it pass, mutates it, or aborts the stream. The unit of enforcement is the token or the message; the unit of meaning — what the inference is actually doing in the world — is not represented. A guardrail cannot answer the question "is this agent permitted, in this context, with this lineage, against this policy, to perform this kind of inference at all," because none of those terms exist in its vocabulary.

Three failure modes follow directly. First, post-hoc filtering produces a leakage gradient: anything the filter does not recognize escapes, and adversarial drift continually expands the unrecognized region. Second, runtime guardrails are non-deterministic with respect to policy: the same prompt under the same nominal configuration can pass on Monday and fail on Tuesday because the guardrail is itself a probabilistic system layered on a probabilistic system. Third, neither approach can express non-execution as a legitimate outcome. A blocked generation is treated as an error, a failure, an exception path — not as a correct, governed, intended result of the system operating as designed.

The architectural premise of inference-time semantic execution control is that these failure modes are not bugs in the post-hoc layer but artifacts of placing governance after generation rather than before it. The corrective primitive is not a better filter. It is a different ordering: resolve policy first, gate inference on capability, and treat the gate's decision — including its decision not to execute — as the system's first and authoritative output.

2. The core architectural primitive: pre-execution policy resolution

The inference-time gate is a deterministic resolution step that runs before the model is permitted to perform any committed inference. Its function is to compute, from a structured set of inputs, whether the proposed inference is admissible. The inputs are: (a) the inference request, lifted into a semantic-state representation that captures intent, addressed capability, and target effect; (b) the active policy object, resolved from the governance chain associated with the calling agent and the operational context; (c) the agent's demonstrated capability state, including lineage continuity, prior admitted transitions, and any capability proofs the agent carries; and (d) the entropy and resource envelope under which the inference would execute.

"Pre-execution" is meant precisely. The gate runs before any token is decoded, before any tool is invoked mid-generation, before any retrieval is issued, before any internal chain-of-thought is permitted to commit into the agent's persistent state. The gate is not wrapping the model — it is positioned in front of the model in the execution graph, and the model is invoked only as a consequence of the gate's admission. If the gate does not admit, the model is not run; the inference does not occur; no candidate output is produced that then has to be filtered, retracted, or apologized for.

The resolution itself is deterministic. Given the same semantic-state input, the same policy object, the same capability state, and the same envelope, the gate returns the same admissibility decision. This is not a performance optimization; it is the load-bearing property that distinguishes a gate from a guardrail. Policy resolution is implemented as a typed evaluation over structured objects, not as a learned classifier, and its decision surface is auditable: every admit, pause, defer, and refuse can be traced back to the specific policy clause and capability fact that produced it.

What the gate is can be stated compactly. It is an admissibility function that maps (semantic_state, policy, capability, envelope) to one of a finite outcome class, and the model is invoked only along the admit branch. What the gate is not matters equally. It is not a content filter, because content does not exist yet. It is not a retrieval check, because retrieval is itself an inference that the gate governs. It is not a wrapper around model.generate(); it is a precondition on whether model.generate() is reached at all.

3. Capability-gated inference

The second primitive is that the gate decision is conditioned on demonstrated capability rather than asserted intent. The distinction is structural. An asserted-intent system asks: does this request, as described, conform to policy? A capability-gated system asks: does this agent, given what it has actually demonstrated and what its lineage attests, hold the capability required to perform this inference under this policy? The first question is answerable from the request alone; the second requires a persistent capability record the agent carries with it.

Capability in this architecture is not a role label or a permission flag. It is a structured object that accumulates across an agent's lineage: which admitted inferences it has produced, which policy frames it has operated under, which transitions it has been authorized for, which entropy envelopes it has stayed within, and which capability proofs it has been issued. The capability object is itself governed — it cannot be forged, asserted, or self-signed by the agent — and it is resolved through the same chain of trust that resolves the policy object.

Capability gating closes a class of failures that asserted-intent systems cannot close. An agent that requests a high-stakes inference can describe its request perfectly while lacking any lineage that demonstrates it has ever performed comparable inferences under comparable policy. In an asserted-intent system, the request looks admissible and the gate admits. In a capability-gated system, the missing lineage is itself a load-bearing signal: the gate withholds admission not because the request is wrong but because the agent has not demonstrated the capability the inference requires. Conversely, an agent with strong lineage can be admitted into inferences whose surface form would look suspicious in isolation, because its capability record carries the missing context.

Capability gating also makes the system robust under prompt-level adversarial pressure. Prompt injection, jailbreaks, and social-engineering payloads target the description of intent. They cannot inject capability, because capability lives outside the prompt, in the agent's lineage record, and the gate consults that record rather than the prompt's self-description. The attacker's surface is not the gate; it is the much narrower problem of corrupting lineage, which the governance chain is designed to prevent.

4. Deterministic non-execution as a valid outcome

The third primitive is that the gate's outcome class is finite, named, and treats non-execution as legitimate. Concretely, the gate returns one of: admit (model is invoked, inference proceeds under the resolved policy), pause (inference is held pending an external condition — a capability proof, a policy clarification, a human-in-the-loop signal — with state preserved so that resumption is well-defined), defer (inference is routed to a different agent or a different operating envelope whose capability record fits the request), or refuse (inference is declined, and the refusal is committed as the system's authoritative output for this request). Each of these is a first-class outcome, recorded in the lineage with the same fidelity as an admitted inference.

This is the pivot that separates inference-time semantic execution control from every adjacent technique. In a guardrail architecture, refusal is an exception path — something went wrong, the model was prevented from doing what it was supposed to do, and the operator must reconcile the gap. In a gated architecture, refusal is the system doing exactly what it is supposed to do: producing a deterministic, auditable, lineage-recorded decision that this inference shall not occur, with the same architectural weight as an emitted answer. The user, the calling agent, the operator, and the auditor all see the same fact: the gate refused, and here is the policy clause and capability gap that produced the refusal.

Pause and defer extend this principle. A pause is not a stall; it is a committed state in which the inference request has been recognized, evaluated, and judged inadmissible now but potentially admissible later under a specific named condition. The system records what condition would change the outcome, and the request resumes deterministically when that condition is satisfied. A defer is a routing decision: the gate has determined that some other agent or some other envelope is the correct executor, and it hands off the request with full lineage continuity, so the receiving agent inherits the context rather than starting fresh.

Treating non-execution as a valid outcome class has a concrete consequence for system design: there is no longer any pressure on the model to "find a way to answer" requests it should not answer. The model is not consulted on requests the gate refuses. The pathology of helpful-but-wrong outputs, of confidently confabulated answers under refusal pressure, of jailbreak-induced compliance, is structurally absent — not because the model has been trained out of it, but because the model is not invoked.

5. Policy object structure and resolution

The policy object consumed by the gate is a typed structure, not a prose document and not a learned weight matrix. It carries: a set of admissibility predicates over semantic-state fields; a capability requirement schema specifying which capability facts must be present and at what level; an envelope specification (entropy bounds, resource bounds, latency budget, side-effect class); a lineage requirement specifying what prior admitted transitions must exist; and a non-execution mapping specifying, for each predicate failure, which non-execution outcome (pause/defer/refuse) is correct and what condition would change it.

Policy objects are resolved through the governance chain rather than supplied by the caller. The agent does not submit its own policy along with its request. Instead, the gate resolves the applicable policy from the governance chain associated with the agent's lineage, the operational context (tenant, jurisdiction, deployment surface), and the inference class. This resolution is itself deterministic and auditable, and it is what prevents the obvious attack of an agent simply asking under a more permissive policy.

Composition rules govern how multiple applicable policies combine. Policies compose by intersection on admissibility predicates (the most restrictive applicable predicate wins), by tightening on envelope bounds, and by union on lineage requirements. This composition is associative and order-independent, which is what allows the gate to remain deterministic even as the governance chain evolves: adding a policy never relaxes the gate, and the resolution order does not change the outcome.

6. Operating parameters and engineering envelope

The gate operates within a measurable engineering envelope. Latency is dominated by policy resolution and capability evaluation rather than model inference, and is bounded by the size of the policy object and the depth of the lineage walk; in typical configurations resolution completes in single-digit milliseconds, well below the latency floor of the model invocation it precedes. Throughput scales horizontally because resolution is a pure function over its inputs and admits aggressive caching keyed on (policy_hash, capability_hash, envelope_hash). Memory footprint is bounded by the policy object and the active capability slice, both of which are finite and typed.

Failure modes are explicit. A gate that cannot resolve a policy — because the governance chain is unreachable, because the policy object is malformed, or because a required capability fact is missing — does not default to admit. It defaults to a deterministic non-execution outcome (typically pause, with the unresolved condition named), and the failure itself is committed to lineage. This is the inverse of fail-open guardrails and is the property that lets the gate be relied upon in safety-critical and regulated contexts.

Determinism extends to upgrade and rollback. Because the gate's behavior is a function of versioned policy objects and versioned capability schemas, replaying a historical request against historical policy reproduces the historical outcome bit-for-bit. This is the property that auditors, regulators, and incident responders require and that probabilistic guardrails cannot offer. It is also what enables safe policy evolution: a new policy can be evaluated in shadow against historical traffic before it is promoted, with exact reproduction of what the gate would have done.

Concrete parameter ranges follow from the structural properties above. Policy object size in deployed configurations ranges from approximately 2 KB for narrow inference classes (a single tool with two or three admissibility predicates) to approximately 256 KB for broad multi-capability operating envelopes; objects larger than this typically indicate a missing decomposition into composable sub-policies and are flagged at registration time. Lineage depth — the number of prior admitted transitions the gate consults — is bounded in practice by a recency window of 16 to 1024 transitions, with older transitions contributing only through their summarized effect on capability state rather than through direct re-evaluation. Capability proof verification, when proofs are signed by an external authority, adds 1 to 8 ms per proof; proofs from the agent's own anchored governance chain are typically pre-resolved and add sub-millisecond cost. The cache keyed on (policy_hash, capability_hash, envelope_hash) achieves hit rates of 70 to 95 percent in steady-state deployments, which is what allows the gate to add a fixed cost per inference rather than a growing one as policy and capability surfaces expand.

Entropy envelopes — the bound on how much committed semantic state an admitted inference is permitted to produce — are expressed in three composable forms. A token-count bound (typical range 64 to 32,768 tokens) limits the size of the emitted artifact. A side-effect class bound (drawn from a small finite enumeration: read-only, idempotent-write, non-idempotent-write, irreversible) limits the kind of effect the inference may cause. An information-disclosure bound, expressed as a list of capability scopes the inference is permitted to address, prevents an admitted inference from drifting into adjacent capabilities the agent does not hold. All three bounds compose by intersection across applicable policies, which is the property that makes the envelope monotone under policy addition.

7. Composition with the cognition architecture

Inference-time semantic execution control does not stand alone. It composes with the surrounding cognition architecture along three explicit interfaces. Upstream, it consumes resolved policy from the governance chain and resolved capability from the agent's lineage record. Downstream, when it admits, it hands the resolved semantic state to the model along with the envelope under which the model is permitted to operate; the model executes inside that envelope, and entropy bounds, resource bounds, and side-effect class are enforced as properties of the execution rather than as post-hoc checks. Laterally, every gate decision — admit, pause, defer, refuse — is committed to the lineage record, so the next inference performed by the same agent consumes the result of this one as part of its capability state.

The composition is what makes the architecture cognition-native rather than wrapper-style. A wrapper sits outside the model and reasons about its outputs. The gate sits inside the execution graph, on the path between intent and inference, and reasons about what is permitted to occur. The model, the gate, the governance chain, the capability record, and the lineage are not independent components stitched together; they are aspects of a single execution substrate in which inference is a governed semantic transition rather than a free generative event.

This composition is also what allows non-execution to be a useful outcome rather than a dead end. A refusal from the gate is not an empty response to the user; it is a structured fact that the rest of the system can consume. A downstream agent receiving a deferred request inherits full context. A monitoring layer observing a paused request knows exactly what condition would resume it. A regulator auditing the system can replay refusals against the policy of record and confirm correctness.

8. Prior-art distinctions

Inference-time semantic execution control is not RLHF or constitutional AI. Those techniques shape the distribution from which a model samples; they bias generation toward preferred outputs but do not introduce an execution boundary. A constitutionally trained model still generates first and is still subject to distributional drift, jailbreaks, and confidently wrong refusals. The gate operates at a different layer entirely — before generation, on a different object (the semantic state, not the token stream), with a different decision class (admit/pause/defer/refuse, not preferred/dispreferred logits).

It is not a guardrail or content filter. Guardrails inspect generated content against rules and abort or mutate streams; they cannot represent capability, lineage, or non-execution as a first-class outcome, and they are themselves probabilistic systems whose decisions drift. The gate is a deterministic function over structured objects whose decisions are reproducible across runs and across versions.

It is not policy-as-prompt or system-prompt safety. Asking a model, in its system prompt, to refuse certain categories conflates the policy with the model's interpretation of the prompt and inherits every prompt injection vector. The gate's policy is consumed by the gate, not by the model, and the model is not asked to interpret it.

It is not a reviewer agent or a critic loop. Reviewer architectures generate first and judge after; they inherit the cost and side effects of the first generation and they require the judge to be at least as capable as the actor, which is not generally available. The gate does not generate first and does not depend on a second model to evaluate the first.

It is not access control or RBAC over a model endpoint. Conventional authorization layers gate which principal may call which API, which is a coarse boolean check upstream of the request body; they do not represent the semantic content of the request, do not consult lineage, and do not produce a structured non-execution outcome that records the specific policy clause and capability gap. A principal with API authorization can still issue a request whose semantic content is inadmissible, and the authorization layer will admit it. The gate operates on the semantic state of the request itself, not on the identity of its sender, and admits or refuses on grounds the authorization layer cannot represent.

It is not a tool-use sandbox or capability token in the operating-system sense. Sandboxes constrain what a running process may do once it is running; capability tokens grant a specific permission to a specific holder. Both are evaluated at the point of effect — the syscall, the resource access — rather than at the point of inference commitment. The gate's capability is structured (lineage, prior admitted transitions, envelope history) rather than a single transferable token, and it is consumed at the inference admission boundary, before any tool is invoked, rather than at the boundary of an individual side effect.

It is not formal verification of model outputs or symbolic constraint solving over generation. Formal-methods approaches attempt to prove properties of what the model produces; they are computationally heavy, restricted to narrow output classes, and still operate after generation. The gate does not prove properties of outputs because no output yet exists; it resolves admissibility of an inference request, which is a finite typed evaluation independent of the model's generative behavior and tractable in milliseconds.

Finally, it is not differential privacy, output watermarking, or any retrofit privacy mechanism over a generative pipeline. Those techniques modify the statistical properties of generated content to bound information leakage or to enable post-hoc attribution; they are evaluated on samples after generation, require parameter tuning against an adversary model, and degrade utility in proportion to the strength of their guarantee. The gate makes no statistical claim about generated content. It admits or refuses the inference itself on grounds that are categorical rather than statistical, and the privacy or disclosure properties of an admitted inference are enforced by the envelope under which the model is invoked rather than by perturbation of the model's output distribution.

9. Disclosure scope

This article discloses inference-time semantic execution control as the canonical primary articulation of the inference-control inventive step. The load-bearing primitives — pre-execution policy resolution, capability-gated inference, and deterministic non-execution as a valid outcome class — are described at the level of architectural function rather than implementation detail. Specific embodiments, sub-articulations, and applied configurations are addressed in companion sub-articles under the inference-control step, including admissibility-gate behavior, anchored resolution, capability proofs, lineage recording, entropy bounds, and rollback recovery.

The scope of the primitive is general. It applies to any inference system in which generated outputs acquire authority — as decisions, commitments, actions, or representations — and in which post-hoc correction is insufficient because execution has already occurred. It is model-agnostic, modality-agnostic, and deployment-agnostic; what it requires is a substrate in which policy can be resolved, capability can be evaluated, and inference can be conditioned on both before it is permitted to commit.