Rights-Grade Inference Governance

Mechanism

Rights-grade inference governance treats the rights of the inference subject as a first-class precondition of the inference call rather than as a downstream filter on its outputs. Every inference call carries, alongside the prompt or query, a rights binding: a structured, signed object that names the subject, declares the consent grants under which the call is being made, scopes the data and operations the call may touch, and fixes the retention regime that will apply to any artifacts the call produces. The inference engine validates the binding cryptographically before any computation runs. If the binding is missing, malformed, expired, or inconsistent with the call's declared scope, the engine does not return a degraded answer; it returns non-execution.

Non-execution is a structurally distinct outcome. It is not an empty response, not a refusal token emitted by the model, and not a polite decline at the policy layer. It is the absence of an inference event. The engine writes a rejection record to lineage, the rejection record names the binding defect that caused it, and no model forward pass occurs. This distinction matters because it removes an entire class of leakage: a model that never runs cannot accidentally memorize, infer side-channel facts, or emit data that the rights binding forbids. The cryptographic check is a hard gate, not a soft preference.

The binding itself is composed of three declared components. Consent identifies the subject, the operations they have authorized, and the time window over which the authorization holds. Scope identifies the data partitions, agent fields, and external resources the call is permitted to read or write. Retention identifies how long the call's outputs, intermediate states, and lineage entries may be kept and under what conditions they must be redacted or deleted. Each component is cryptographically signed by an authority recognized by the policy reference, and the engine validates the signature chain before the call is admitted.

Because the binding is checked at the call site, rights enforcement is co-located with inference rather than separated from it by a network hop or a policy proxy. The engine cannot be tricked by a caller who validates rights at the front door and then forwards an unbound call to a back-door endpoint, because there is no back-door endpoint that will run without a binding. The engine's evaluation function is itself the gate.

Operating Parameters

The binding format is parameterized by the policy reference. Operators declare which authority public keys are recognized, which signature algorithms are accepted, and which canonicalization rules apply to the binding payload. These parameters are versioned, so a policy update can rotate keys, deprecate algorithms, or tighten canonicalization without altering the engine's evaluation logic.

The consent component is parameterized by an operations vocabulary. Each operation a subject can authorize, such as inference over personal text, generation of likeness, derivation of preferences, or training-style adaptation, is named in a controlled vocabulary that the policy reference exposes. Consent grants enumerate operations from this vocabulary, and the engine matches the call's declared operation against the grant set. Calls whose operation is not present in the grant set are non-executed.

The scope component is parameterized by a partition map and a resource catalog. Partitions divide the agent's semantic state into rights-relevant regions; the catalog enumerates external resources by stable identifier. A scope grant lists the partitions and resources the call may touch. The engine enforces scope by binding the call's read and write set to the declared scope before evaluation begins; reads outside scope are unsatisfiable, and writes outside scope are non-executed.

The retention component is parameterized by a small set of declared regimes - for example, ephemeral, session-bound, audited, or archival - each with its own deletion timeline and redaction obligations. Lineage entries inherit the retention regime of the call that produced them, and downstream consumers of those entries inherit it transitively. The engine refuses to commit a call whose declared retention regime is incompatible with the regime under which any of its inputs were collected.

Finally, the binding lifetime is parameterized. Bindings can be one-shot, scoped to a session, or scoped to a longer-lived authorization window. The engine refuses calls whose binding lifetime has expired, whose nonce has already been observed, or whose freshness window has elapsed, in each case writing a non-execution record.

Alternative Embodiments

In a single-tenant embodiment, the engine and the binding authority share an administrative boundary. Bindings are minted by a local issuer and validated by the engine using a static key set. This embodiment is appropriate for enterprise deployments where the inference subject and the operator are within the same trust domain.

In a multi-tenant embodiment, bindings are minted by per-subject issuers and validated against a federated key directory. The engine accepts bindings from any issuer the policy reference recognizes, and rejects bindings whose issuer is unknown or revoked. This embodiment supports inference platforms that serve many independent subjects on shared infrastructure.

In a delegated embodiment, the subject grants a delegate the right to mint scoped bindings on the subject's behalf. The delegate's bindings carry a chain of signatures that traces back to the subject's root grant, and the engine validates the entire chain. This embodiment supports agent-to-agent calls and intermediated workflows without diluting the subject's control.

In a hardware-attested embodiment, the engine itself is bound to a hardware root of trust, and the binding includes a constraint that the call must execute inside an attested enclave. The engine refuses calls whose attestation does not match the constraint. This embodiment is appropriate for highly sensitive subjects whose rights bindings must reach into the execution environment as well as the policy layer.

Composition with Other Mechanisms

Rights-grade governance composes with the semantic admissibility gate by acting as a precondition rather than a competitor. The gate evaluates candidate transitions against integrity, policy, and trust-slope constraints; rights governance ensures that the gate is only ever asked to evaluate transitions that the subject has authorized. A failed binding short-circuits the gate; a valid binding hands the gate a call whose scope and retention are already constrained.

Rights-grade governance composes with lineage because every non-execution event is itself a lineage entry. Auditors do not see only the calls that ran; they also see the calls that were refused, the binding defect that caused each refusal, and the time at which the refusal occurred. This produces a complete record of the engine's interactions with the subject's rights, including negative outcomes, which is the standard a rights regime must meet.

Rights-grade governance composes with the elegance evaluator by constraining the candidate set before elegance is computed. Transitions that would touch out-of-scope fields are not merely unattractive; they are inadmissible. Among the admissible candidates, elegance ranks the cleanest, but the rights binding is what determines what is admissible in the first place.

Distinction from Prior Art

Conventional consent and rights frameworks operate at the application or storage layer. They control whether a record can be read, whether a transformation can be initiated, or whether an output can be returned to a particular recipient, but they do not bind to the inference call itself. The model runs and then a downstream filter decides what to release. Such frameworks cannot prevent the inference event from occurring, cannot prevent inadvertent memorization, and cannot produce a structural record of refused calls because the calls were not refused at the engine.

API-key and OAuth-style authorization mechanisms scope what a caller can request but treat the inference engine as a generic resource. They do not carry subject rights into the engine, do not bind retention, and do not produce a non-execution record at the engine when the binding is invalid; they produce an HTTP error at the gateway. The engine itself is unaware of the subject.

The disclosed mechanism is distinguished by binding subject rights cryptographically at the inference call site, by treating an unbound or invalid call as non-execution rather than as an error in the response, and by recording non-execution as a structural lineage event. This conjunction is what makes the rights regime enforceable at the layer where the model actually runs, rather than at the layer that wraps it.

Disclosure Scope

This disclosure covers the rights-binding format, the consent, scope, and retention components, the cryptographic validation performed at the inference call site, the non-execution outcome and its lineage representation, and the policy-driven parameters that configure the binding regime. It covers single-tenant, multi-tenant, delegated, and hardware-attested embodiments.

The disclosure is structural. Implementations may use any signature scheme, any canonicalization, and any partitioning of the agent state that preserves the declared semantics of consent, scope, and retention. The defining property is that the inference engine refuses to evaluate calls whose rights binding is missing or invalid, and that the refusal is recorded as a first-class structural event.

The disclosure extends to any embodiment in which the binding format is versioned and migrated under policy control, in which keys are rotated through the policy reference without service interruption, and in which the engine accepts a binding only after validating the entire signature chain against the current authority set. It covers embodiments in which the binding's canonicalization is enforced by a declared schema rather than by ad-hoc parsing, and embodiments in which the engine emits a structured non-execution receipt that the caller can present to a higher-level auditor as proof that the call was offered, that it was refused, and that the refusal was bound to a named binding defect.

Within scope are embodiments that compose the rights binding with delegated authorization chains of arbitrary length, with hardware attestation as an additional precondition, and with retention regimes that span multiple agents through transitive inheritance. Also within scope are embodiments in which non-execution events are themselves subjects of policy, such that the rate, distribution, and binding-defect classes of refused calls drive operational signals back into the policy reference. The determinative criterion in every such embodiment is that no inference computation occurs in the absence of a valid binding, that the absence of computation is itself a recorded structural event, and that the binding's three components - consent, scope, and retention - are independently checked, signed, and auditable.