The Compute-Location Gate: Provenance-Class Routing of Identity Inference with Wire-Layer Refusal of Unconsented Provenance Classes

4.1. Active Inference

An input signal is of the active provenance class when the inferred-about principal initiated the act that produced it. Challenge-response exchanges, a consented structured assessment, an explicit attestation the principal authored, and inputs the principal supplied to a deliberate identity-elaboration flow are all of the active class. The defining property is principal initiation: the principal performed an act whose purpose, as understood by the principal at the time of the act, was to contribute signal to their own identity inference.¶

An inference drawn solely from active-class signal MAY compute server-side and MAY write to the server-held identity vector (Section 7.1).¶

4.2. Passive Aggregate Observation

An input signal is of the passive aggregate provenance class when it was observed without a principal-initiated act, and when the inference drawn from it is computed over a cohort of principals no smaller than the cohort floor (Section 5) and yields only a population-level observation. A passive aggregate inference produces a statement about the cohort (a distribution, a rate, a population parameter) and does not produce a statement attributable to any individual within the cohort.¶

An inference of the passive aggregate class MAY compute server-side (Section 7.2). Its output is a population-level observation; it MUST NOT write an individual-attributable statement to the server-held identity vector.¶

4.3. Passive Individual Observation

An input signal is of the passive individual provenance class when it was observed without a principal-initiated act and the inference drawn from it would yield a statement attributable to a single principal.¶

An inference of the passive individual class is local-only. It MUST be computed on the device-local daemon (Section 4) running on the device that observed the input signal, and the resulting derived statement MUST be retained on that device. An individual-attributable statement of the passive individual provenance class MUST NOT be transmitted to a server, and MUST NOT, by any derivation path, reach the server-held identity vector.¶

The passive individual class is the load-bearing constraint of this memo. The other two classes describe what server-side inference MAY do; this class describes what server-side inference MUST NOT do. A system that routes passive individual observation to server-side compute has not implemented the compute-location gate, irrespective of any access control it applies to the resulting datum afterward.¶

7.1. The Inference Request

A client requesting an identity inference SHALL include, in the request, an inference-negotiation object carrying at minimum the following fields.¶

provenance_class (enum, REQUIRED)

One of active, passive-aggregate, passive-individual. The provenance class the client asserts for the input signal of the prospective inference.¶

signal_stream (string, REQUIRED)

A stable identifier for the stream from which the input signal is drawn. Consent classes (Section 6.2) are keyed to the pair (provenance_class, signal_stream); the stream identifier is the second key.¶

requested_output (string, REQUIRED)

An identifier for the category of derived statement the inference is to produce. The requested output does not select the compute location (the provenance class does), but it is carried so that the consent match (Section 6) and the audit record (Section 9) can record what was requested.¶

cohort_size (integer, OPTIONAL)

Present only when provenance_class is passive-aggregate. The size of the cohort over which the aggregate inference is to be computed. The service SHALL reject the request if cohort_size is below the declared cohort floor (Section 5).¶

principal (string, OPTIONAL)

The ~handle of the inferred-about principal, present when the inference is attributable to a named principal. Absent for a passive aggregate inference, which is by construction not attributable to an individual.¶

7.2. The Negotiation Response

The inference service SHALL respond to an inference-negotiation request with one of three typed responses.¶

accepted

The asserted provenance class is consented (Section 6), the routing function (Section 7) has selected a compute location, and the inference will proceed at that location. The response carries the selected compute_location (server-side or device-local), so that the client and any audit observer record where the inference computed.¶

refused

The asserted provenance class is not covered by a consent class. No inference is performed at any compute location. The structure of the refusal is specified in Section 6.3.¶

redirected

The asserted provenance class is consented, but the routing function has selected a compute location other than the one the client is positioned to satisfy. The most common case is a client requesting a server-side inference on signal the service classifies as passive-individual: the service does not perform the inference server-side, and the response directs the client to perform the inference on the device-local daemon (Section 4). A redirected A redirected response is not a refusal; the inference is admissible. It is not a server-side acceptance either.¶

The negotiation response, in every case, is returned before any inference is performed. An inference service MUST NOT compute an identity inference and then decide, from the result, whether to return it; the compute-location gate is evaluated on the negotiation object alone, ahead of the inference.¶

8.1. Provenance Class Is Distinct from Trait Category

A consent class is keyed to a provenance class and a signal stream, not to the category of the derived output. A principal who has consented to active-class inference of a disposition has not thereby consented to passive-individual-class inference of the same disposition. Consent granted for one provenance class does not generalise to another. This is the defining property of provenance- class consent: the how it was observed is consented separately from the what is derived.¶

It follows that an inference service MUST carry the provenance class on every signal record and on every derived statement throughout its internal architecture, so that the consent match can be evaluated and so that the audit record (Section 9) can record the provenance class that was matched. A derived statement that has lost its provenance class is not consent-checkable and MUST NOT be served.¶

8.2. The Consent Class

A consent class is a grant, authored by the principal, carrying at minimum:¶

• The provenance_class the grant covers.¶

• The signal_stream the grant covers.¶

• The set of requested_output categories the grant admits, or an explicit marker that the grant admits all output categories for the covered (provenance class, signal stream) pair.¶

• A revocation marker; consent classes are revocable, and a revoked consent class MUST NOT satisfy a subsequent match.¶

A consent class for the passive-individual provenance class authorises device-local inference (Section 4) only. No consent class, of any provenance class, authorises the transmission of an individual-attributable passive-individual derived statement to a server; that transmission is precluded by Section 3.3 and is not a grantable scope.¶

Consent for inference from a third-party signal stream is a separate consent class from any authorisation the principal may have granted the third-party platform itself. A principal's authorisation of a platform's data-access grant is not a consent class for ALTER-side or any inference-service-side inference from that platform's stream; the inference service SHALL require a distinct, separately revocable consent class, keyed to the (provenance_class, signal_stream) pair, before inferring from a third-party stream.¶

8.3. The Wire-Layer Refusal

When the asserted provenance class of an inference request is not covered by a consent class, the inference service SHALL return a refused negotiation response. The refusal carries at minimum:¶

reason (enum, REQUIRED)

One of no-consent-class (no consent class covers the asserted provenance class and signal stream), consent-revoked (a consent class existed but has been revoked), cohort-floor (a passive-aggregate request carried a cohort_size below the declared floor), or provenance-not-routable (the asserted provenance class is not one the service admits for the requested output).¶

provenance_class (enum, REQUIRED)

The provenance class that was asserted and refused, echoed so that the client and audit observer record what was requested.¶

explanation (string, REQUIRED)

A human-readable explanation, sufficient for the client's reasoning surface to present to the principal without a further round-trip.¶

A refused response is terminal for the inference request. The inference service MUST NOT, having returned a refusal, perform the refused inference at any compute location, and MUST NOT perform a substitute inference of a different provenance class without a fresh negotiation. The refusal is a wire-layer event: it is observable to the client, it is recorded in the audit log (Section 9), and it occurs before any inference computation.¶

The refusal model of this memo is consent-class matching plus wire-layer rejection. It is not, and does not rely on, any cryptographic attestation that a refused signal was absent from a computation. The refusal asserts that the inference was not performed; it does not produce a proof, verifiable without access to the underlying data, that a particular data category did not contribute to some other computation. The boundary between the mechanism this memo specifies and the cryptographic-attestation question it does not address is stated in Section 11.¶

9.1. Active Class to Server-Side

A consented inference of the active provenance class is routed to server-side compute. Its output MAY be written to the server-held identity vector and MAY be served, subject to the inference service's ordinary read-path consent, through the service's consented query surface. The principal initiated the act that produced the signal; server-side derivation and persistence is the routing outcome.¶

9.2. Passive Aggregate Class to Server-Side, Population-Level Output

A consented inference of the passive-aggregate provenance class, whose cohort_size is no smaller than the declared cohort floor, is routed to server-side compute. Its output is a population-level observation. The output MUST NOT be written to the server-held identity vector as an individual-attributable statement; the server-held identity vector is, by Section 3, the destination of active-class inference alone. A passive aggregate output is a statement about the cohort, retained as such.¶

9.3. Passive Individual Class to Device-Local

A consented inference of the passive-individual provenance class is routed to device-local compute on the device-local daemon (Section 4). The inference service does not perform the inference. Where a client requests a server-side inference on signal the service classifies as passive-individual, the service returns a redirected negotiation response (Section 6) directing the client to the device-local daemon.¶

The routing function has no branch by which a passive-individual inference computes server-side. A server-side compute location is not a selectable outcome for the passive-individual provenance class under any consent configuration. This is the structural property that distinguishes the compute-location gate from an access-control mechanism: access control could, in principle, be configured to admit a reader of a server-side passive-individual trait; the routing function of this section has no such configuration, because the trait is never computed server-side to be read.¶

10.1. Per-Event Audit Record

Every negotiation, whether it resolves to accepted, refused, or redirected, SHALL produce an append-only audit record carrying at minimum: the asserted provenance_class; the signal_stream; the requested_output; the negotiation outcome; the selected compute_location where the outcome was accepted; the reason where the outcome was refused; an [RFC3339] timestamp; and the attribution of the requesting party. The audit record is written to an append-only log; admitted records are not retractable or amendable. Where the inference service is operated as, or alongside, an organisational identity substrate, the audit record SHOULD be emitted to that substrate's audit-signal ingestion surface as specified by [POLICYPROV].¶

The audit record makes the gate's operation observable after the fact: an auditor can determine, for any inference the service performed, what provenance class was asserted, what compute location was selected, and which consent class was matched.¶

10.2. Build-Time Data-Flow Verification

In addition to the per-event audit record, an inference service SHOULD verify, at the time its inference pipeline is built, that the pipeline contains no data-flow path by which a signal of the passive-individual provenance class reaches the server-held identity vector.¶

The verification treats the inference pipeline as a directed graph whose nodes are pipeline stages and whose edges are data-flow dependencies between stages. The verification is the property: for every signal node of the passive-individual provenance class, and for every node representing a write to the server-held identity vector, there exists no directed path from the former to the latter. A pipeline that fails this property has a route by which a device-local-only inference could reach the server, and the build SHOULD fail.¶

This build-time verification is a check on the pipeline's structure, performed before the pipeline runs; it is independent of, and complementary to, the per-event audit record, which observes the pipeline's behaviour after each negotiation. The combination of a structural check at build time and a behavioural record at run time is the verification model of the compute-location gate. Neither component is a cryptographic proof, and the verification model does not depend on one; the boundary is stated in Section 11.¶

15.1. Provenance-Class Misassertion

A client may assert a provenance class that does not correspond to how the input signal was actually observed; for example, asserting the active class for a signal that was passively observed, so as to route an individual-attributable inference to server-side compute. The asserted provenance class is a claim, and the inference service MUST NOT treat it as self-certifying. The service SHALL establish the provenance class from substrate it observes (the act that produced the signal, the stream the signal arrived on, the presence or absence of a principal-initiated trigger) and SHALL refuse a request whose asserted provenance class is inconsistent with the observed substrate. A provenance class established from observed substrate, rather than accepted from a client assertion, is the integrity foundation of the gate.¶

15.2. Cohort-Floor Evasion

An attacker may attempt to extract an individual-attributable statement through repeated passive aggregate queries whose cohorts overlap such that the difference between two near-identical cohorts isolates an individual. The cohort floor of Section 5 bounds the size of any single cohort but does not, alone, bound a differencing attack across cohorts. An inference service SHOULD additionally constrain the composition of passive aggregate queries, for example by refusing aggregate queries whose cohorts differ by fewer than the cohort floor, and SHOULD record passive aggregate cohort definitions in the audit log (Section 9) so that a differencing pattern is detectable post-hoc.¶

15.3. Redirect Suppression

A redirected negotiation response (Section 6) directs a client to perform a passive-individual inference on the device-local daemon rather than server-side. An attacker positioned between the client and the inference service might suppress or rewrite the redirected response so that the client believes a server-side inference is unavailable and abandons the inference, or believes a server-side inference occurred when it did not. Negotiation responses SHOULD be carried over a channel authenticated by the cryptographic identity envelope of [MCPDNS], so that a consuming client can verify the response bears the inference service's declared signing key, and a suppressed or rewritten response is detectable.¶

15.4. Device-Local Daemon Compromise

The device-local daemon (Section 4) holds passive-individual derived statements that, by Section 3.3, never reach a server. Compromise of the device-local daemon exposes those statements. The gate does not make the device-local daemon's storage secure (that is the device's responsibility), but it does ensure that the blast radius of a device-local compromise is confined to a single device's passive-individual derivations and does not extend to a server-held aggregate of many principals' passive-individual traits, because no such server-held aggregate exists. The compute-location gate's routing is itself a blast-radius mitigation.¶

15.5. Audit-Log Integrity

The per-event audit record (Section 9.1) is the after-the-fact evidence that the gate operated. An attacker able to amend or delete audit records could conceal a server-side passive-individual inference. The audit log MUST be append-only; admitted records MUST NOT be retractable or amendable by the inference service operator. Where the audit record is emitted to an organisational identity substrate per [POLICYPROV], the append-only property of that substrate's ingestion surface carries the integrity requirement.¶

16.1. Provenance Class as a Consent Boundary

The gate's central privacy property is that consent is keyed to provenance class, not to trait category (Section 6.1). A principal controls not merely what is inferred about them but from what manner of observation. A principal may consent to active-class inference of a disposition while withholding consent for passive-individual inference of the same disposition; the gate honours that distinction at the wire layer. An inference service that collapses the distinction, treating consent for a trait category as consent for all provenance classes of that category, has not implemented the privacy property this memo specifies.¶

16.2. Local-Only Retention of Passive Individual Inference

The passive individual provenance class is routed to device-local compute and device-local retention (Sections 3.3, 4, 7.3). The privacy consequence is that the inference service holds no server-side, individual-attributable representation derived from passively observed individual signal. A principal's passive individual derivations are, by construction, not present in the inference service's data holdings, not subject to the service's breach exposure, and not reachable by a server-side query however authorised. The principal's later election to contribute such a derivation to a server-held inference is an active-class act (Section 4) and is independently consented.¶

16.3. Third-Party Stream Inference

A principal's authorisation of a third-party platform's data-access grant is not consent for an inference service to infer identity statements from that platform's stream (Section 6.2). Inference from a third-party stream requires a consent class distinct from, and separately revocable from, the platform authorisation. This separation matters because a principal's mental model of a platform authorisation is "this platform may use my data on this platform", not "any inference service may derive identity traits from my behaviour on this platform". The gate's consent classes make the second a separate, explicit, revocable grant. Inference from a third-party stream conducted without such a separate consent class is a privacy violation that the gate is specifically structured to prevent.¶

16.4. Regulatory Context

The compute-location gate's routing of passive individual inference off the server is consistent with data-minimisation expectations under data-protection regimes generally, and with [GDPR] in particular: a derivation that is never computed server-side produces no server-side personal datum to minimise, retain, or erase. Implementers operating in jurisdictions that categorically prohibit certain inferences in certain contexts (for instance the prohibition under [EUAIACT] of emotion inference in workplace and education settings) should note that the compute-location gate is a routing-and-consent mechanism and does not itself satisfy a categorical prohibition: a categorical prohibition bites regardless of provenance class or compute location, and an inference service subject to one MUST refuse the prohibited inference outright rather than route it. The gate composes with a categorical refusal; it does not replace one.¶

19.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[MCPDNS]

Morrison, B., "Discovery of Model Context Protocol Servers via DNS TXT Records", 2026, <https://datatracker.ietf.org/doc/draft-morrison-mcp-dns-discovery/>.

[IDPRONOUNS]

Morrison, B., "Identity Pronouns: A Reference-Axis Extension to ~handle Identity Systems", 2026, <https://datatracker.ietf.org/doc/draft-morrison-identity-pronouns/>.

[SUBSTRATE]

Morrison, B., "Substrate-Observation as an Alternative to Envelope Coordination for Concurrent Sessions", 2026, <https://datatracker.ietf.org/doc/draft-morrison-substrate-observation/>.

[POLICYPROV]

Morrison, B., "Policy Provision and Governance Inheritance from an Organisational Identity Substrate", 2026, <https://datatracker.ietf.org/doc/draft-morrison-org-alter-policy-provision/>.

[MCP]

Agentic AI Foundation, "Model Context Protocol Specification", 2026, <https://modelcontextprotocol.io>.

19.2. Informative References

[RFC3339]

Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.

[RFC6973]

Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.

[RFC7942]

Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, <https://www.rfc-editor.org/info/rfc7942>.

[GDPR]

European Parliament and Council, "Regulation (EU) 2016/679 (General Data Protection Regulation)", 2016.

[EUAIACT]

European Parliament and Council, "Regulation (EU) 2024/1689 Laying Down Harmonised Rules on Artificial Intelligence (Artificial Intelligence Act)", 2024.

[DWORK]

Dwork, C., McSherry, F., Nissim, K., and A. Smith, "Calibrating Noise to Sensitivity in Private Data Analysis", 2006, <https://www.iacr.org/archive/tcc2006/38760266/38760266.pdf>.

[SOLID]

Sambra, A., Mansour, E., Hawke, S., Zereba, M., Capadisli, S., Ghanem, A., Aboulnaga, A., and T. Berners-Lee, "Solid: A Platform for Decentralized Social Applications Based on Linked Data", 2016, <https://dig.csail.mit.edu/2016/solid/>.