Semantic Admissibility Gate

Mechanism

The admissibility gate is a deterministic evaluation function positioned at the entry of every inference transition. Before any generation, retrieval, or tool invocation occurs, every candidate input is presented to the gate as a structured object carrying its canonical fields, its lineage tail, the credential under which it is being offered, and the governance class the caller asserts it belongs to. The gate evaluates the object against the active policy and returns one of three outcomes: admit, non-admit, or decompose. Admit forwards the input to the inference step unchanged. Non-admit refuses entry and emits a typed non-admission record. Decompose returns the input to the caller as a structured request for further work, naming exactly which canonical fields must be supplied, refreshed, or re-attested before re-presentation.

Three checks are load-bearing. The governance-class check verifies that the asserted class matches the policy applicable to the requested inference and that the input's actual class, derived from its lineage, is consistent with the assertion. A class mismatch produces non-admission regardless of credential validity; the input is structurally inappropriate, not merely unauthorized. The credential check verifies that the credential under which the input is offered is currently valid, has not expired, has not been revoked, and is bound to the lineage chain of the input itself. An expired or unbound credential produces non-admission even if the input would otherwise be class-correct. The lineage check verifies that the input's lineage tail is complete, integrity-sealed, and consistent with the canonical fields it claims to populate. Missing lineage is treated as missing trust; there is no implicit fill.

The gate is pre-generation, not post-generation. No tokens are emitted, no tool is called, and no semantic state is mutated until the gate has admitted the input. This is not a performance optimization; it is the structural property that makes governance possible. A post-generation filter cannot prevent contamination of the agent's own working state by the act of generating; a pre-generation gate refuses entry before any such state can form. The gate's outcome is recorded in the integrity ledger before the inference step executes, so that even if downstream processing fails or is interrupted, the admissibility decision survives.

Non-admission is a typed event, not an error. The non-admission record names the failed check, the policy clause that produced the failure, the offending canonical fields, and the lineage of the rejected input. Callers receive the record and can choose to repair the input, re-present it under a different credential, decompose it into smaller admissible parts, or abandon the attempt. The agent's semantic state is unchanged by a non-admission; the only side effect is the ledger entry.

Decompose is the structural alternative to forced admission. Where a request would be partially admissible if a single field were refreshed, the gate returns a decompose outcome naming exactly which fields are at fault and which canonical operations would repair them. Decompose preserves the caller's progress: nothing the caller has prepared is discarded, and re-presentation after repair is a continuation rather than a retry. The decompose outcome is the mechanism that lets a strict gate coexist with practical workflows; without it, callers would face a binary admit-or-abandon decision and would be incentivized to over-claim credentials.

The gate's three checks are evaluated in a fixed order: governance class first, credential validity second, lineage completeness third. The order matters because it determines which non-admission record is produced when more than one check would fail. Class is checked first because a class mismatch is non-repairable by the caller; emitting a credential-failure record for an input that was structurally inappropriate would mislead the caller into renewing a credential when no credential could have helped. The order is policy-fixed and cannot be reordered at runtime.

Operating Parameters

The gate is parameterized by the active policy's class lattice, credential schema, and lineage requirements. The class lattice defines which governance classes may flow into which inference contexts; flows not permitted by the lattice are non-admitted. The credential schema defines the credential types the gate recognizes, their validity intervals, their binding rules, and their revocation sources. The lineage requirements define the minimum tail depth, the required integrity-seal algorithm, and the canonical fields that must be present for a lineage to be considered complete.

Decompose thresholds govern when the gate prefers decomposition over outright non-admission. A request that fails on a single missing field is more usefully decomposed than rejected; a request that fails on governance-class mismatch is not a candidate for decomposition because no further work by the caller would repair it. The thresholds are policy-defined and are checked at policy compile time for consistency, so that a policy cannot accidentally produce decomposition loops.

The gate's evaluation is bounded in time and resources. A single admissibility decision must complete within a policy-defined budget; budget exhaustion produces non-admission with a distinguished reason code. This bound prevents the gate from becoming a denial-of-service surface and ensures that admissibility decisions are themselves predictable.

Revocation propagation is parameterized by a maximum staleness interval. A credential whose revocation status was last refreshed beyond the staleness interval is treated as not-currently-validated and produces non-admission, even if the most recently observed status was valid. This converts revocation freshness from an operational property into an admissibility property; the gate cannot admit on the basis of stale-good information.

Policy version is itself a parameter of every gate decision. The gate stamps the policy version into the admit, non-admit, or decompose record at the moment of evaluation. A subsequent policy update does not retroactively change prior decisions; auditors evaluating a historical decision do so under the version that produced it. This versioning makes admissibility decisions stable artifacts rather than transient outcomes of whatever policy happens to be live.

Alternative Embodiments

In a single-policy embodiment, the gate evaluates against one active policy applicable to all inference. In a multi-tenant embodiment, the gate selects the policy on the basis of the caller's tenant identity, and the class lattice is partitioned per tenant; cross-tenant flows are non-admitted by construction. In a regulated embodiment, the policy is signed by an external regulator and the gate refuses to load policies that fail signature verification, so that the admissibility decision rests on a regulator-attested rule set rather than an operator-defined one.

In a federated embodiment, the gate's decisions are exchanged across agent boundaries as typed admissibility receipts. A receipt issued by one gate may be presented at another, allowing pre-attested inputs to traverse multiple agents without redundant re-evaluation, provided the receiving policy accepts the issuing gate's authority. In a reduced embodiment suitable for constrained environments, the decompose outcome is disabled and the gate returns only admit or non-admit; this trades flexibility for simplicity without changing the admit boundary.

In a temporal embodiment, the gate consults forecast inputs including capability-decline predictions to refuse inputs that are class-correct and credential-valid today but predicted to become inadmissible within the inference's expected duration. This embodiment uses the same gate; it differs only in the policy's reliance on forward-looking inputs.

In an offline-attestation embodiment, the gate operates without live access to credential or revocation services and relies on signed attestations whose validity intervals are pre-declared. Inputs accompanied by an unexpired attestation are admitted; inputs without one are non-admitted regardless of how legitimate they would appear under online evaluation. This embodiment is structurally identical to the online case; the difference is solely in which canonical fields the gate consults to determine credential validity.

Composition

The admissibility gate composes with the integrity ledger, which records every admit, non-admit, and decompose decision as a sealed event. It composes with the forecasting engine, which consults the gate before issuing fork directives so that inadmissible directives are never sent. It composes with the delegation mechanism, where the gate runs at directive issuance, at delegate entry, and again at recombination; each invocation enforces its own policy without coordination among them. It composes with credential infrastructure, consuming revocation streams and validity intervals as canonical fields rather than out-of-band signals.

Because admit, non-admit, and decompose are typed outcomes with canonical-field payloads, every downstream component sees a uniform interface regardless of which check produced the outcome. A consumer that handles non-admission once handles it for class, credential, and lineage failures alike, while still being able to introspect the reason code when behavior must differ.

The gate composes additionally with downstream observers that subscribe to the ledger's non-admission stream. Such observers may operate compliance dashboards, billing meters, anomaly detectors, or external regulators' monitoring tools. Because non-admission records are first-class artifacts with stable schemas, observers do not need bespoke parsers, and adding a new observer does not require any change to the gate or the policies it enforces.

Prior-Art Distinction

Conventional output filters operate post-generation: the model produces tokens, and a classifier or rule engine decides whether to release them. By that point, generation has already mutated the model's state and consumed resources, and the filter's only remaining option is suppression. Conventional access-control gates sit in front of the API but evaluate only credential validity and coarse role membership; they do not check governance class against lineage and they do not produce decompose outcomes that route work back to the caller for repair.

The structural distinction here is that the gate is pre-generation, evaluates governance class, credential validity, and lineage completeness as a single deterministic function, produces a typed three-way outcome including decompose, and emits sealed non-admission records that are first-class artifacts rather than exceptions. No prior-art system exhibits this combination of pre-generation positioning, three-way outcome, and lineage-bound class enforcement.

Disclosure Scope

This disclosure covers the pre-generation admissibility gate as a deterministic evaluation function over canonical-field inputs; the three-way admit, non-admit, decompose outcome; the governance-class, credential-validity, and lineage-completeness checks as load-bearing components of the decision; the typed non-admission record as a first-class artifact emitted to the integrity ledger; the policy-compile-time consistency checks that prevent decomposition loops; and the composition of the gate with ledger, forecasting, delegation, and credential infrastructure. The disclosure contemplates single-policy, multi-tenant, regulated, federated, reduced, and temporally-aware embodiments, and is not limited to any specific policy language, credential format, or inference modality.