



Network Working Group                                        B. Morrison
Internet-Draft                       Alter Meridian Pty Ltd (~truealter)
Intended status: Informational                                  May 2026
Expires: 22 November 2026


    The Compute-Location Gate: Provenance-Class Routing of Identity
  Inference with Wire-Layer Refusal of Unconsented Provenance Classes
                draft-morrison-compute-location-gate-00

Abstract

   This memo specifies the compute-location gate: a mechanism by which a
   client and an identity-inference server negotiate, at the wire layer
   and before any inference is performed, the location at which an
   identity inference will compute, as a deterministic function of the
   provenance class of the input signal.  Three provenance classes are
   distinguished.  Active inference, initiated by the inferred-about
   principal, MAY compute server-side and produce a server-held identity
   vector.  Passive aggregate observation over a cohort no smaller than
   a declared minimum MAY compute server-side but yields only a
   population-level observation that is not attributable to an
   individual.  Passive individual observation is local-only: it is
   computed and retained on the device that observed it and is never
   transmitted to a server.  The gate is enforced by consent-class
   matching and by a wire-layer refusal returned when a requested
   provenance class is not consented; it is not enforced by any
   cryptographic proof concerning data that was not used.  The memo is
   Informational.  The wire surface composes with the discovery
   mechanism of [MCPDNS], the handle namespace of [IDPRONOUNS], and the
   organisational policy substrate of [POLICYPROV]; no new transport is
   introduced.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."




Morrison                Expires 22 November 2026                [Page 1]

Internet-Draft            Compute-Location Gate                 May 2026


   This Internet-Draft will expire on 2 November 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Status of This Memo . . . . . . . . . . . . . . . . . . . . .   3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   4.  Provenance Classes  . . . . . . . . . . . . . . . . . . . . .   6
     4.1.  Active Inference  . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Passive Aggregate Observation . . . . . . . . . . . . . .   6
     4.3.  Passive Individual Observation  . . . . . . . . . . . . .   6
   5.  The Device-Local Daemon . . . . . . . . . . . . . . . . . . .   7
   6.  The Cohort Floor  . . . . . . . . . . . . . . . . . . . . . .   8
   7.  Wire-Layer Negotiation  . . . . . . . . . . . . . . . . . . .   8
     7.1.  The Inference Request . . . . . . . . . . . . . . . . . .   9
     7.2.  The Negotiation Response  . . . . . . . . . . . . . . . .   9
   8.  Consent-Class Matching  . . . . . . . . . . . . . . . . . . .  10
     8.1.  Provenance Class Is Distinct from Trait Category  . . . .  10
     8.2.  The Consent Class . . . . . . . . . . . . . . . . . . . .  11
     8.3.  The Wire-Layer Refusal  . . . . . . . . . . . . . . . . .  11
   9.  Routing and Compute-Location Selection  . . . . . . . . . . .  12
     9.1.  Active Class to Server-Side . . . . . . . . . . . . . . .  12
     9.2.  Passive Aggregate Class to Server-Side, Population-Level
           Output  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     9.3.  Passive Individual Class to Device-Local  . . . . . . . .  13
   10. Audit and Build-Time Verification . . . . . . . . . . . . . .  13
     10.1.  Per-Event Audit Record . . . . . . . . . . . . . . . . .  13
     10.2.  Build-Time Data-Flow Verification  . . . . . . . . . . .  14
   11. Relation to Prior Art . . . . . . . . . . . . . . . . . . . .  14
   12. Scope Boundary: What This Memo Does Not Specify . . . . . . .  15
   13. Implementation Status . . . . . . . . . . . . . . . . . . . .  16
   14. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   15. Security Considerations . . . . . . . . . . . . . . . . . . .  17
     15.1.  Provenance-Class Misassertion  . . . . . . . . . . . . .  17
     15.2.  Cohort-Floor Evasion . . . . . . . . . . . . . . . . . .  17
     15.3.  Redirect Suppression . . . . . . . . . . . . . . . . . .  18
     15.4.  Device-Local Daemon Compromise . . . . . . . . . . . . .  18



Morrison                Expires 22 November 2026                [Page 2]

Internet-Draft            Compute-Location Gate                 May 2026


     15.5.  Audit-Log Integrity  . . . . . . . . . . . . . . . . . .  18
   16. Privacy Considerations  . . . . . . . . . . . . . . . . . . .  18
     16.1.  Provenance Class as a Consent Boundary . . . . . . . . .  19
     16.2.  Local-Only Retention of Passive Individual Inference . .  19
     16.3.  Third-Party Stream Inference . . . . . . . . . . . . . .  19
     16.4.  Regulatory Context . . . . . . . . . . . . . . . . . . .  20
   17. Relation to Companion Memos . . . . . . . . . . . . . . . . .  20
   18. Document History  . . . . . . . . . . . . . . . . . . . . . .  21
   19. References  . . . . . . . . . . . . . . . . . . . . . . . . .  21
     19.1.  Normative References . . . . . . . . . . . . . . . . . .  21
     19.2.  Informative References . . . . . . . . . . . . . . . . .  22
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  23
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  23

1.  Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

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





Morrison                Expires 22 November 2026                [Page 3]

Internet-Draft            Compute-Location Gate                 May 2026


   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 8) 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 [MCPDNS], the handle namespace of
   [IDPRONOUNS], the cross-session coordination posture of [SUBSTRATE],
   and the organisational policy substrate of [POLICYPROV].  No new
   transport, no new handle category, and no new discovery record is
   introduced.

3.  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 RFC2119 [RFC8174] 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



Morrison                Expires 22 November 2026                [Page 4]

Internet-Draft            Compute-Location Gate                 May 2026


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

   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 [IDPRONOUNS].









Morrison                Expires 22 November 2026                [Page 5]

Internet-Draft            Compute-Location Gate                 May 2026


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

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.




Morrison                Expires 22 November 2026                [Page 6]

Internet-Draft            Compute-Location Gate                 May 2026


   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.

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

   1.  Receives passive individual signal observed on its host device.

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

   3.  Retains the derived statement in device-local storage under the
       principal's control.

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




Morrison                Expires 22 November 2026                [Page 7]

Internet-Draft            Compute-Location Gate                 May 2026


   The device-local daemon participates in the substrate-observation
   posture of [SUBSTRATE] 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.

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

   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.

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



Morrison                Expires 22 November 2026                [Page 8]

Internet-Draft            Compute-Location Gate                 May 2026


   Context Protocol [MCP] 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.

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.




Morrison                Expires 22 November 2026                [Page 9]

Internet-Draft            Compute-Location Gate                 May 2026


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

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.







Morrison                Expires 22 November 2026               [Page 10]

Internet-Draft            Compute-Location Gate                 May 2026


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




Morrison                Expires 22 November 2026               [Page 11]

Internet-Draft            Compute-Location Gate                 May 2026


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

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.











Morrison                Expires 22 November 2026               [Page 12]

Internet-Draft            Compute-Location Gate                 May 2026


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

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



Morrison                Expires 22 November 2026               [Page 13]

Internet-Draft            Compute-Location Gate                 May 2026


   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.

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 [DWORK] 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



Morrison                Expires 22 November 2026               [Page 14]

Internet-Draft            Compute-Location Gate                 May 2026


   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 [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 that was
   nonetheless 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 6) 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.

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





Morrison                Expires 22 November 2026               [Page 15]

Internet-Draft            Compute-Location Gate                 May 2026


   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 6) and its verification model is per-event audit
   plus build-time data-flow checking (Section 8).  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 [MCPDNS], the principal's
   existing transport, and [IDPRONOUNS] respectively.

13.  Implementation Status

   A reference implementation of the compute-location gate is operated
   by the present author against a production identity-inference service
   reachable at the ~truealter.com substrate.  The reference deployment
   classifies input signals into the three provenance classes of
   Section 3, performs the negotiation of Section 6 ahead of inference,
   routes by the function of Section 7, returns the wire-layer refusal
   of Section 6.3 on a consent miss, declares a cohort floor of 1000 for
   passive aggregate inference, and runs the build-time data-flow
   verification of Section 8.2 as a gate on its inference-pipeline
   build.  The device-local daemon of Section 4 is the reference
   deployment's local-execution surface for passive individual
   inference.

   In the spirit of [RFC7942], 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.





Morrison                Expires 22 November 2026               [Page 16]

Internet-Draft            Compute-Location Gate                 May 2026


14.  IANA Considerations

   This memo requests no IANA action.

   The negotiation field names and the negotiation-response type names
   used in Sections 6 and 7 are illustrative of the reference deployment
   described in Section 12.  Conforming inference services MAY name the
   corresponding fields and response types by any convention consistent
   with their transport's addressing primitive; the load-bearing
   contribution of this memo is the three-provenance-class routing
   function and the wire-layer refusal, not the field names.  No new DNS
   record types, transport identifiers, port numbers, URI schemes, or
   media types are introduced.

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

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



Morrison                Expires 22 November 2026               [Page 17]

Internet-Draft            Compute-Location Gate                 May 2026


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

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






Morrison                Expires 22 November 2026               [Page 18]

Internet-Draft            Compute-Location Gate                 May 2026


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.









Morrison                Expires 22 November 2026               [Page 19]

Internet-Draft            Compute-Location Gate                 May 2026


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.

17.  Relation to Companion Memos

   This memo composes with four Morrison-family Internet-Drafts.

   [MCPDNS] supplies the DNS-based discovery surface by which a client
   locates an inference service, and the cryptographic identity envelope
   referenced in Section 13.3.  This memo introduces no new DNS records
   or labels.

   [IDPRONOUNS] supplies the ~handle namespace by which principals and
   substrates are named.  This memo introduces no new handle category.

   [SUBSTRATE] 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.

   [POLICYPROV] 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.




Morrison                Expires 22 November 2026               [Page 20]

Internet-Draft            Compute-Location Gate                 May 2026


18.  Document History

   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.

19.  References

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




Morrison                Expires 22 November 2026               [Page 21]

Internet-Draft            Compute-Location Gate                 May 2026


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







Morrison                Expires 22 November 2026               [Page 22]

Internet-Draft            Compute-Location Gate                 May 2026


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

Acknowledgements

   This memo grew out of internal architectural work on the question of
   how an identity-inference system should decide not merely who may
   read a derived trait, but where the derivation is permitted to
   compute.  The realisation that the compute-location question is prior
   to the access-control question: an access-control refusal arrives
   after the server has already computed and persisted the datum it
   declines to serve.  That observation is the load-bearing insight
   behind this specification.

Author's Address

   Blake Morrison
   Alter Meridian Pty Ltd (~truealter)
   Email: blake@truealter.com
   URI:   alter:~blake























Morrison                Expires 22 November 2026               [Page 23]
