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

Introduction An identity-inference system derives statements about a principal (traits, competencies, dispositions, belonging measures) from signals the principal emits. Such systems face a question that access control alone does not answer: who may read a derived statement, and where the derivation itself is permitted to compute. These are distinct questions. Access control governs the read path of a datum that already exists. The compute-location question governs whether the datum may be brought into existence on a given machine at all. A system that answers only the first question can decline to serve an inferred trait to an unauthorised reader, but it has, by the time of that refusal, already computed and persisted the trait on its server. The compute-location question, asked earlier, prevents the server-side derivation from occurring when the signal's provenance does not warrant it. This memo specifies a mechanism, the compute-location gate, that answers the second question at the wire layer. Before an inference is performed, the client and the server negotiate the provenance class of the input signal. The provenance class deterministically selects a compute location. Where the negotiated provenance class is not covered by the principal's consent, the server returns a wire-layer refusal, and no inference is performed at any location. The mechanism rests on a principle the present author has elsewhere termed identity-as-inference: that a principal's identity is inferred from manifestation rather than declared, and that every such inference is admissible only under an explicit gate on the provenance of the signal from which it is drawn. The first clause of that principle is: no inference without a compute-location gate. This memo is the wire-layer codification of that clause. The mechanism is deliberately narrow. It specifies provenance-class negotiation, the routing function from provenance class to compute location, the consent-class match, and the refusal returned on a consent miss. It does NOT specify, and explicitly excludes from its scope (Section 11), any cryptographic proof that a particular data category was excluded from a derivation. The gate's enforcement model is consent-class matching plus wire-layer rejection. Verification that the gate held is addressed by build-time pipeline checks (Section 9) and by post-hoc audit, not by a cryptographic attestation of absence. The wire surface composes with four Morrison-family Internet-Drafts: the discovery surface of , the handle namespace of , the cross-session coordination posture of , and the organisational policy substrate of . No new transport, no new handle category, and no new discovery record is introduced.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. The following terms are defined for the purposes of this document. Terms previously defined by the referenced Morrison-family memos retain their established meaning and are reproduced here only when operative for the present specification.

Identity inference: A computation that derives a statement about a principal (a trait value, a competency estimate, a disposition, a belonging measure, or a comparable derived attribute) from one or more signals the principal has emitted.
Provenance class: A property of an input signal, established before inference, that records how the signal came to be observed. Three provenance classes are defined in Section 3.
Compute location: The machine class on which an identity inference is permitted to execute. Two compute locations are distinguished: server-side, on infrastructure operated by the inference service; and device-local, on the device that observed the input signal.
Server-held identity vector: A persisted, server-side representation of a principal's inferred identity, readable through the inference service's consented query surface. Only inference of the active provenance class (Section 3.1) may write to the server-held identity vector.
Device-local daemon: A long-running process executing on a device under the principal's control, on which device-local inference (Section 3.3) is computed and where the resulting representation is retained. The device-local daemon does not transmit individual-attributable derived statements to a server.
Cohort floor: The minimum cohort size, declared by the inference service, below which a passive aggregate inference (Section 3.2) MUST NOT be computed. The cohort floor exists so that a population-level observation cannot be narrowed to an individual.
Consent class: A unit of consent granted by a principal, keyed to a provenance class and a signal stream. A consent class is the grant against which a negotiated provenance class is matched (Section 7).
Wire-layer refusal: A typed response returned by the inference service, before any inference is performed, when a requested provenance class is not covered by a consent class. The refusal terminates the inference request; no inference is performed at any compute location.
~handle: A principal identity handle as defined by .

Provenance Classes Every input signal admitted to an identity inference carries exactly one of three provenance classes. The provenance class is established before inference and is immutable for the lifetime of the signal record. The provenance class, not the signal's content and not the trait category of the prospective output, is the value on which the compute-location gate routes.

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 8.1).

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 8.2). Its output is a population-level observation; it MUST NOT write an individual-attributable statement to the server-held identity vector.

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 governing 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.

The Device-Local Daemon Inference of the passive individual provenance class is computed on a device-local daemon. The device-local daemon is a process under the principal's control, executing on the device that observed the input signal. The device-local daemon:

Receives passive individual signal observed on its host device.
Computes the identity inference locally. No input signal of the passive individual class, and no statement derived from it, leaves the device for the purpose of the inference.
Retains the derived statement in device-local storage under the principal's control.
Exposes the derived statement to the principal, and only to the principal, through a device-local interface. The principal MAY, by a subsequent active-class act, elect to contribute a derived statement to a server-held inference; such an act re-enters the pipeline as active-class signal (Section 3.1) and is gated afresh.

The device-local daemon MUST NOT expose an interface by which a server, or any party other than the principal operating the device, can read an individual-attributable statement of the passive individual class. The transition of a passive-individual-derived statement to server-side visibility occurs only through a fresh active-class act by the principal, never through a daemon-exposed read surface. The device-local daemon participates in the substrate-observation posture of for the purpose of cross-session coordination of the principal's surfaces; that participation is orthogonal to the present memo and introduces no path by which passive individual derived statements reach a server.

The Cohort Floor A passive aggregate inference (Section 3.2) MUST NOT be computed unless the cohort over which it is computed is no smaller than the cohort floor. The cohort floor is a positive integer declared by the inference service and exposed at the negotiation surface (Section 6) so that a client can determine, before requesting an inference, whether a passive aggregate request is admissible. The cohort floor exists to ensure that a passive aggregate inference yields a population-level observation and not an individual-attributable one. An inference computed over a cohort smaller than the floor risks re-identification: with a sufficiently small cohort, a population parameter is a near-individual statement. The floor is the structural boundary between the passive aggregate class, which MAY compute server-side, and the passive individual class, which MUST NOT. The cohort floor is a parameter of this mechanism, not a fixed constant of this memo. An inference service SHALL declare its cohort floor and SHALL NOT compute a passive aggregate inference over a cohort below it. A service whose declared cohort floor is so low that a population parameter computed at that size is individually identifying has not satisfied the intent of this section; the floor is a number, but a number chosen so that the resulting observation is genuinely population-level. The reference deployment described in Section 12 declares a cohort floor of 1000. As Section 12 records, no live inference path yet reaches that floor, and it is not yet exposed at the negotiation surface. The cohort floor governs the aggregate boundary only. It is not a privacy budget, it is not a noise-calibration parameter, and it does not compose additively across queries. The relationship of the cohort floor to the statistical-disclosure-control literature is discussed in Section 10.

Wire-Layer Negotiation Before an identity inference is performed, the client and the inference service negotiate the provenance class of the input signal and, by the routing function of Section 8, the compute location. The negotiation is a request-response exchange carried over the client's existing transport to the inference service; this memo introduces no new transport. Where the inference service is reached as a Model Context Protocol surface, the negotiation is a tool invocation and its response; where it is reached over another transport, the negotiation is the corresponding request-response pair.

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 7.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 7) 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.

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 7), the routing function (Section 8) 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 7.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 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.

Consent-Class Matching The compute-location gate is enforced by consent-class matching. The asserted provenance class of an inference request is matched against the consent classes the principal has granted; an inference proceeds only when a matching consent class is found.

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.

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 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.

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.

Routing and Compute-Location Selection The routing function maps a consented provenance class to a compute location. The function is total over the three provenance classes and is deterministic: the same provenance class always selects the same compute location. A signal that the service's own classifier cannot place in one of the three provenance classes SHALL NOT be routed server-side. The routing function fails closed to device-local compute only. This is distinct from the provenance-not-routable refusal of Section 7.3, which answers a client asserting a class the service does not admit. Here no client has asserted a class, so there is no party to refuse, and the most restrictive compute location is the one selected.

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.

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.

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.

Audit and Build-Time Verification The compute-location gate is verifiable in two complementary ways: by a per-event audit record written at negotiation time, and by a build-time check on the inference pipeline's data-flow.

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 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 . 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.

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.

Relation to Prior Art The compute-location gate is structurally distinct from the prior-art families with which it is most likely to be confused. Differential privacy and the broader statistical-disclosure- control literature address the population-versus-individual boundary at the algorithmic layer: a query mechanism adds calibrated noise so that the presence or absence of any single record is statistically masked, and a privacy budget composes the guarantee across queries. The compute-location gate addresses a different boundary at a different layer. The cohort floor of Section 5 is not a privacy budget: it does not compose additively across queries, and it calibrates no noise. It is a categorical admissibility threshold: below the floor, the passive aggregate class is simply not the applicable provenance class, and the inference is not computed server-side at all. Differential privacy makes a server-side individual-sensitive computation safe to release; the compute-location gate routes the individual-attributable computation off the server entirely. The two are composable: a passive aggregate inference admitted by the cohort floor MAY additionally apply differential privacy to its population-level output. They are not substitutes. Decentralised personal-data architectures (Solid and comparable personal-data-store designs) move the storage of personal data to a principal-controlled pod and govern the read path through access control. The compute-location gate governs the compute path: it determines where a derivation is permitted to run, not merely where its result is stored or who may read it. A personal-data store can hold a passive-individual trait computed server-side and copied to the pod; the compute-location gate precludes the server-side computation in the first place. The two are complementary (a device-local daemon (Section 4) may use a personal-data store as its retention surface), but the gate's contribution is the routing of computation, which a storage-layer architecture does not address. Consent-management and access-control frameworks generally govern which parties may read which data. The compute-location gate's consent classes (Section 7) govern, in addition, the provenance class under which an inference may be brought into existence. A consent framework that admits a reader of a derived trait has not, by that admission, said anything about whether the trait may be derived server-side from passively observed individual signal; that is the question the provenance-class consent of this memo answers. The contribution of this memo is the wire-layer composition of the compute-path question with provenance-class consent: a negotiation, ahead of inference, that routes computation by provenance class and refuses at the wire layer when the provenance class is not consented.

Scope Boundary: What This Memo Does Not Specify This memo specifies the compute-location gate: provenance-class negotiation, the routing function, consent-class matching, and the wire-layer refusal. It deliberately does not specify several adjacent mechanisms, and an implementer SHOULD NOT read the gate as providing them. This memo does not specify a cryptographic proof, attestation, or guarantee that any specified data category, provenance class, or derivation pathway was excluded from a particular computation. The gate's enforcement model is consent-class matching plus wire-layer rejection (Section 7) and its verification model is per-event audit plus build-time data-flow checking (Section 9). A refusal under this memo asserts that an inference was not performed; it does not produce, and does not rely on, any object that proves (verifiably without access to the underlying data) that a data category did not contribute to some output. Such a proof is a different mechanism, addressed by separate work, and is outside the scope of this specification. An implementer requiring a cryptographic exclusion guarantee MUST NOT infer one from the audit record or the build-time check described here; neither is such a proof, and the compute-location gate does not become one by composition. This memo does not specify the internal inference algorithms, the trait taxonomy, the identity-vector representation, or the device-local daemon's storage format. These are implementation matters of an inference service; the memo specifies only the wire surface at which compute location is negotiated. This memo does not specify a discovery mechanism, a transport, or a handle namespace. It composes with , the principal's existing transport, and respectively.

Implementation Status A reference implementation of the compute-location gate is operated by the present author against a production identity-inference service. The reference deployment classifies input signals into the three provenance classes of Section 3 by a total classification function, routes by the function of Section 8, returns the wire-layer refusal of Section 7.3 on a consent miss, and declares the cohort floor of Section 5 for passive aggregate inference. The routing function contains no branch by which a passive-individual inference computes server-side, and an unrecognised provenance class fails closed to local-only. Three parts of this memo are specified but not exercised by the reference deployment. The negotiation of Section 6 is performed internally ahead of the trait write rather than as an exchange with the client: no client asserts a provenance class on the wire, and the accepted-response compute-location field is not returned. The refusal of Section 7.3 carries all three required fields on the deployment's HTTP surface but only the reason on its tool-invocation surface. The cohort floor is declared and enforced in code but is not reached by any live inference path, and is not exposed at the negotiation surface as Section 5 requires. The build-time data-flow verification of Section 9.2 is not implemented. The device-local daemon of Section 4 receives passive individual signal on the member's own device and retains it there, and its egress path is deliberately unbuilt. It does not yet perform the local inference of Section 4 clause 2; a local-only routing decision presently terminates in a member-visible record rather than in a local computation. In the spirit of , the present author notes that this section documents implementation experience and is expected to be removed before the document advances beyond the Independent Stream. No claim of interoperability is made; the reference deployment is a single service operated by the specification's author.

Security Considerations The compute-location gate concentrates an admissibility decision (where an identity inference may compute) at a wire-layer negotiation performed ahead of inference. The following considerations arise.

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.

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.

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 , 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.

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.

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 , the append-only property of that substrate's ingestion surface carries the integrity requirement.

Privacy Considerations The compute-location gate is, in its substance, a privacy mechanism; its routing function is a privacy decision. The considerations of apply, and three are operative here.

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 7.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.

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, 8.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.

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 7.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.

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 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 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.

Relation to Companion Memos This memo composes with four Morrison-family Internet-Drafts. supplies the DNS-based discovery surface by which a client locates an inference service, and the cryptographic identity envelope specified in Section 7. This memo introduces no new DNS records or labels. supplies the ~handle namespace by which principals and substrates are named. This memo introduces no new handle category. supplies the substrate-observation posture under which the device-local daemon (Section 4) coordinates with the principal's other sessions; that coordination introduces no path by which passive-individual derived statements reach a server. supplies the organisational identity substrate to whose audit-signal ingestion surface the per-event audit record (Section 9.1) SHOULD be emitted. An inference service operated alongside an organisational identity substrate inherits that substrate's append-only audit posture for the compute-location gate's audit trail. The compute-location gate is the wire-layer codification of the first clause of the identity-as-inference principle: no inference without a compute-location gate. The companion memos codify adjacent clauses and surfaces of the same principle; this memo is the clause concerning where inference is permitted to compute.

Document History draft-morrison-compute-location-gate-02 (September 2026):

Corrects the Implementation Status to separate what the reference deployment exercises from what it specifies. The three-class routing, the local-only structural property, the pre-inference refusal and the cohort-floor declaration are recorded as operating; the Section 6 client negotiation, two of the Section 7.3 refusal fields on the tool surface, the reached cohort floor and the Section 9.2 build-time verification are recorded as not exercised. The Section 4 daemon is recorded as retaining local signal without yet performing local inference.
Specifies in Section 8 that a signal the service cannot classify fails closed to device-local compute, and distinguishes that case from the Section 7.3 refusal.
Removes a repeated phrase in Section 6.2.
Names the three companion documents in the Abstract in words rather than by citation, and drops two redundant phrases, in Sections 7.2 and 10.
States in Section 5 what the Implementation Status records about the reference deployment's cohort floor, so the two sections agree.
Adds the missing -01 entry to this history.

draft-morrison-compute-location-gate-01 (July 2026):

Repairs the internal section cross-references, which pointed one section short throughout, and moves the Status of This Memo text to the document generator. No change to the mechanism.

draft-morrison-compute-location-gate-00 (May 2026):

Initial submission.
Defines the three provenance classes (active, passive aggregate, passive individual) and the immutability of a signal's provenance class.
Specifies the device-local daemon as the compute location for passive individual inference.
Specifies the cohort floor for passive aggregate inference.
Specifies the wire-layer negotiation (inference request, negotiation response) performed ahead of inference.
Specifies consent-class matching, the distinctness of provenance class from trait category, and the wire-layer refusal.
Specifies the routing function from provenance class to compute location.
Specifies the per-event audit record and the build-time data-flow verification.
States the scope boundary excluding cryptographic exclusion guarantees from the specification.