What a Consultation Event Is
The disclosure defines a consultation event as an event in which a generative model queries a reference artifact through retrieval-augmented generation, structured neighborhood resolution, or an analogous mechanism. The term is given an explicit definition in the specification: a consultation event is recorded as a deterministic record comprising the variance-derived unique identifier of the consulted artifact, the governing policy object, the variance proximity score between the consulted artifact and the generation output, and a timestamp. Consultation logging is the function that captures these events. It does not describe a passive trace of access in general; it describes the specific moment at which a model under governance reaches into a governed corpus and pulls a reference artifact into the generation of an output.
The component that performs this capture is named in the platform claim: a consultation event logger configured to deterministically record, for each generation event that consults a reference artifact through retrieval or structured neighborhood resolution, a consultation record. The word deterministic is load-bearing in the source. The same generation event consulting the same reference artifact under the same policy produces the same record, so the log is reproducible rather than an artifact of incidental observation.
The Consultation Record
A consultation record comprises four fields, each named in the specification. The first is the variance-derived unique identifier of the consulted artifact, the structurally computed content UID that the rest of the platform uses to refer to that artifact independently of its storage location or transmission metadata. The second is the governing policy object, or an identifier of the cryptographically signed policy object under which the consultation was authorized. The third is the variance proximity score between the consulted artifact and the generated output. The fourth is a timestamp. The platform measures structural similarity throughout as cosine similarity of multi-axis variance vectors, and the variance proximity score is the structural-proximity measurement carried by a consultation event.
These four fields are sufficient for the downstream uses the disclosure describes. They do not require access to model weights, to training logs, or to proprietary platform internals. The record is built entirely from the structural identity of the consulted artifact, the policy that governed the consultation, the measured structural proximity between the consulted reference and the output it influenced, and the time of the event.
Why the Log Exists
The purpose of consultation logging in the disclosure is to make creator compensation computable. The specification states the principle directly: content creator compensation for generative AI use of training data should be computable from verifiable structural proximity measurements rather than from approximations of training data influence derived from model weight analysis. Reverse-engineering which training examples shaped a model output is intractable and contested. The disclosure sidesteps that problem by shifting attribution to the point of consultation. When a model consults a reference artifact within a policy-defined similarity neighborhood, that consultation is logged as a computable attribution event from which compensation obligations may be derived under policy-declared schedules.
Because the record attaches to a governed consultation event rather than to an inference over opaque weights, payment becomes computable from the consultation event log rather than from estimates of training influence. The shift is from approximation to measurement: the platform does not guess how much a given source contributed; it records each governed consultation and computes from those records.
Pre-Conditions for Logging
The disclosure states three pre-conditions for the attribution and compensation architecture that consultation logging feeds. First, the training data artifact must have a registered UID in the anchor network, so the consulted reference can be identified structurally. Second, the creator must have registered an alias for that UID with a compensation routing field specifying a payment address and a compensation schedule, so an obligation can be routed. Third, the generative model must operate within a governed execution environment that logs consultation events when the model queries reference artifacts through retrieval-augmented generation or structured neighborhood resolution during inference.
The third pre-condition locates consultation logging inside a governed execution environment. The log is produced because the model runs under governance, not because an external observer watches it. Outside such an environment the consultation event, as the specification defines it, does not arise.
From Records to Attribution Weights
Consultation records are not consumed one at a time. An attribution computation module aggregates consultation events per consulted artifact and computes an attribution weight as the product of consultation frequency and mean variance proximity score. Frequency captures how often a given reference artifact was consulted; mean variance proximity captures how structurally close that reference was, on average, to the outputs it influenced. Their product is the attribution weight. A reference that is consulted often and sits close to the outputs it shaped earns more weight than one consulted rarely or only at the margins of similarity.
A related claim describes the same aggregation for retrieval-augmented generation specifically: consultation events arising from retrieval-augmented generation operations, in which a generative model queries a reference corpus by variance-band-indexed neighborhood resolution, are aggregated to compute attribution weights for each consulted reference artifact based on consultation frequency, variance proximity of the consulted reference artifact to the candidate content artifact, and policy-declared compensation schedules.
From Attribution Weights to Payment
The compensation computation module multiplies the attribution weight by the schedule rate drawn from the compensation schedule reference and produces a payment obligation record. The payment routing module then credits the computed obligation to the payment address associated with the consulted artifact's alias record, under the declared jurisdictional scope. The compensation schedule reference is a versioned, machine-evaluable, cryptographically signed document specifying the rate structure under which attribution weights translate to payment obligations. The disclosure enumerates schedule formats: per-consultation flat rates, proximity-weighted rates in which higher cosine similarity scores produce proportionally higher payments, category-specific rates, and jurisdiction-specific rates.
Schedule versioning is what keeps the computation reproducible. Compensation computations are reproducible and auditable from the schedule version in effect at the consultation event, so a later revision of the rate structure does not retroactively change what a past consultation was worth.
The Append-Only Audit Relationship
The compensation audit log maintains an append-only record of payment obligation records, each comprising the consulted artifact UID, the computed attribution weight, the schedule version applied, the payment obligation amount, the payment address credited, the jurisdictional scope, and a timestamp. The disclosed auditability property is a verification relationship between two logs: the compensation audit log is verifiable against the consultation event log. Any party may confirm that payment obligations are consistent with the corresponding consultation events, the compensation schedules in effect at the relevant times, and the computed attribution weights, and may do so without requiring access to model weights, training logs, or proprietary platform data.
Admissibility decisions across the broader platform are likewise reproducible and auditable from versioned policy objects and consultation event logs. The consultation event log is therefore not only an input to compensation but part of the platform's general audit surface: the record of which governed consultations occurred, under which policy, against which structurally identified artifacts.
Consultation Events in Streaming Provenance
Consultation event records also appear in the streaming provenance pathway. For real-time streaming content, the UID derivation system operates over a sliding window of the stream, producing window-level UIDs that are registered with the anchor network. When the cosine similarity between a window-level UID and a registered reference UID exceeds the policy-declared similarity threshold, the system generates a real-time match event that may trigger policy enforcement actions, among them the generation of a consultation event record. This shows the same record serving provenance tracking on live content, generated at the point where a streamed window is found structurally to match a governed reference.
Disclosure Scope
The disclosure within PCT International Application No. PCT/US26/28630 covers the consultation event logger and the consultation record it produces: a deterministic record, captured for each generation event that consults a reference artifact through retrieval-augmented generation, structured neighborhood resolution, or an analogous mechanism, comprising the variance-derived unique identifier of the consulted artifact, the governing policy object under which the consultation was authorized, the variance proximity score between the consulted artifact and the generation output, and a timestamp. It covers the aggregation of consultation events into attribution weights computed as the product of consultation frequency and mean variance proximity score, the translation of attribution weights into payment obligations under versioned, cryptographically signed compensation schedules, and the routing of those obligations to the payment address in the consulted artifact's alias record under a declared jurisdictional scope.
The scope extends to the append-only compensation audit log and its verification against the consultation event log, by which any party may confirm payment obligations are consistent with the recorded consultations, the schedules in effect, and the computed attribution weights without access to model weights, training logs, or proprietary platform data. It extends to the pre-conditions of a registered artifact UID, a registered creator alias with a compensation routing field, and a governed execution environment that logs consultations during inference, and to the generation of consultation event records within the streaming provenance pathway when a window-level UID matches a registered reference UID above the policy-declared threshold.
