Integrity-Aware Inference

Mechanism

The mechanism interposes a deterministic integrity evaluator between the caller's intent to invoke an inference function and the actual dispatch of that call. The evaluator consumes three structured lineage objects and produces a single admit-or-reject outcome that is recorded irrevocably in the agent's lineage log. The first object is the input lineage, which carries the cryptographic digests, originating field identifiers, transformation chain, and policy classifications of every datum that will be presented to the model as context, prompt, or parameter. The second object is the model lineage, which binds the requested inference target to a specific model identifier, weight digest, version stamp, and the policy class under which that model is permitted to operate. The third object is the environment binding, which records the runtime container identity, the calling cognitive role, the active policy reference revision, the upstream admissibility gate decision that authorized the call, and the trust slope state at the moment of dispatch.

Each object is hashed against a canonical reference structure derived from the agent's policy reference. If any field is absent, malformed, or fails its expected hash chain back to a recorded provenance event, the evaluator emits a non-execution verdict. Non-execution is not the same as failure: the call site receives a structured rejection event that names the specific lineage component that broke, the policy clause that demanded it, and the upstream lineage anchor that should have produced it. The model is never invoked, no tokens are consumed, and the surrounding semantic state is not perturbed. Rejection events are themselves committed to the lineage log, so an auditor can later reconstruct not only what the agent thought but also what the agent refused to think and why.

When the three lineage objects validate, the evaluator emits a signed admission token that the dispatch layer presents to the inference runtime. The token binds the eventual response to the exact lineage triple that authorized it, so any output later quoted, cached, or propagated downstream carries an unforgeable reference back to the precise input, model, and environment from which it originated. This converts inference outputs from anonymous strings into provenanced artifacts.

The admission token is short-lived and scoped to the single dispatch it authorizes. Reuse of an admission token for a second call, even one whose lineage objects would validate independently, is rejected: the token's nonce is consumed at dispatch and any replay is treated as an integrity violation regardless of the apparent legitimacy of the call. This prevents a class of attacks in which an attacker captures a valid admission and replays it against a different but superficially similar invocation. The signed binding also extends through any caching layer: a cache hit does not bypass the evaluator, because the cached response is itself indexed by lineage triple and the evaluator must confirm the new caller's lineage matches before the cached response is returned. In this way the integrity property is preserved across both fresh inference and memoized inference, and the same audit trail applies to both.

Operating Parameters

The integrity evaluator is parameterised by a small set of policy-controlled knobs. The lineage depth bound governs how far back the evaluator must walk the provenance chain before accepting an anchor; shallow bounds permit fast inference at the cost of provenance completeness, while deep bounds enforce end-to-end traceability at the cost of evaluation latency. The freshness window bounds the maximum age of an environment binding before re-attestation is required, preventing replay of stale authorizations. The model lineage tolerance defines whether minor weight revisions are accepted under the same policy class or whether each revision requires explicit re-authorization.

Severity weighting is applied to rejection events. A missing input lineage on a low-policy-class call produces a recoverable rejection that the caller may retry with corrected provenance. A tampered model lineage or a forged environment binding produces a non-recoverable rejection that escalates to the agent's governance role and locks the calling cognitive path until manual review. The severity table is itself a declarative artifact in the policy reference, so domain operators can tune the response surface without modifying the evaluator.

Rate and concurrency parameters bound how many simultaneous integrity evaluations a single role may have outstanding, preventing inference floods from masking individual lineage failures behind aggregate latency. Timeout parameters distinguish between a slow attestation source and an absent one, so transient infrastructure issues do not collapse into security verdicts.

Alternative Embodiments

In a centralized embodiment, the integrity evaluator runs as a sidecar process colocated with the inference runtime, intercepting all model calls at the transport layer. This embodiment is suited to monolithic deployments where the agent and its models share a trust boundary. In a distributed embodiment, the evaluator is sharded across the cognitive roles that originate calls, with a shared attestation service issuing canonical references; this fits federated deployments where multiple agents share a model fleet but maintain independent lineage logs.

In a hardware-anchored embodiment, environment bindings are produced by a trusted execution environment that signs the runtime container identity and the loaded model digest with a hardware key. The evaluator validates these signatures against an enrolled hardware roster, so a spoofed environment cannot satisfy the binding regardless of how convincingly its software state is reconstructed. In a software-only embodiment, environment bindings rely on policy-issued tokens with short freshness windows and continuous re-attestation.

A streaming-inference embodiment evaluates lineage incrementally as a long-running generation proceeds, allowing mid-stream rejection if the environment binding expires or the input lineage is retroactively invalidated by a discovered upstream fault. A batch-inference embodiment evaluates lineage once per batch and treats the entire batch as a single transition for lineage purposes.

Composition

Integrity-aware inference composes with the semantic admissibility gate. The admissibility gate's decision to permit a transition is itself an input to the environment binding, so a model call cannot occur without an authorizing gate decision, and a gate decision cannot retroactively justify an unauthorized model call. The two mechanisms form a closed loop: the gate authorizes the intent to invoke, the integrity evaluator authorizes the actual invocation, and both decisions are joined in the lineage record.

The mechanism composes with the trust slope tracker by reading the slope state into the environment binding. When the slope is degrading, severity weights tighten and the freshness window contracts, making the integrity evaluator more conservative precisely when the agent's recent behavior warrants suspicion. It composes with the policy reference loader so that any change to the canonical reference structures forces re-evaluation of in-flight calls under the new policy, preventing silent grandfathering of pre-change inferences.

Distinction Over Prior Art

Conventional inference governance applies content filters to model outputs after generation, or applies prompt-level guardrails before generation. Neither approach verifies the structural preconditions of the call itself. Output filtering cannot detect a call made with tampered weights, because the output may still appear plausible. Prompt guardrails cannot detect an environment binding forgery, because the prompt content is unaffected. Integrity-aware inference operates at a different point in the pipeline: the call site, where lineage is checkable and non-execution is still possible.

Provenance systems in classical data engineering record lineage after the fact for audit. The mechanism here uses lineage as a precondition, not a record, so absent lineage produces non-execution rather than incomplete audit. Attestation systems in trusted computing verify the runtime environment but do not bind that attestation to specific input and model lineages within a cognitive workflow. The combination of all three lineage classes, evaluated at the call site, with deterministic non-execution on any failure, is the structural distinction.

Failure Modes and Recovery

Several failure modes are anticipated and handled deterministically. An attestation source that becomes unreachable produces a timeout-class rejection rather than a security verdict; the calling role may queue the call for retry within the freshness window, and only on persistent failure does the rejection escalate. A model identifier that resolves to a weight digest not enrolled in the policy reference produces a non-recoverable rejection; the model is treated as untrusted regardless of whether the calling role believed it was authorized. A canonical reference structure that has been updated mid-flight produces a re-evaluation requirement; in-flight calls fail closed and must be re-issued under the new policy.

Recovery procedures are themselves declared in the policy reference. Each rejection class has a documented remediation path: retry with corrected provenance, escalation to governance, manual re-attestation, or revocation of the calling role's authorization. The recovery path is executed by the agent's governance role, not by the calling role, preventing self-remediation loops in which a compromised role recovers itself out of a security verdict. Every recovery action is itself committed to the lineage log and bound to the rejection event it remediates, so the audit trail captures the full lifecycle from initial call attempt through final disposition.

Edge cases at the boundaries of policy classes are resolved by the principle of strict admission: when a call's lineage objects span multiple policy classes, the most restrictive applicable class governs. This prevents privilege escalation through policy-class confusion attacks in which an attacker constructs a call whose lineage is individually valid under several classes but whose combination implies privileges no single class confers.

Disclosure Scope

This disclosure covers any system in which model invocation is conditioned on the deterministic verification of input lineage, model lineage, and environment binding at the call site, where any missing or tampered lineage component produces non-execution rather than degraded execution, and where rejection events are committed to the same lineage log as successful calls. The disclosure extends to embodiments that vary the storage of canonical references, the cryptographic primitives used for hashing and signing, the granularity at which lineage is checked, and the integration with upstream admissibility and trust mechanisms, provided the call-site, three-lineage, non-execution-on-failure structure is preserved.

The disclosure further extends to applications across autonomous vehicles, regulated decision-support systems, multi-agent enterprise platforms, and consumer-facing companion systems, in each case where inference calls must be governed with auditable provenance rather than trusted on the basis of caller identity alone.