[ai-control] Re: Proposed "AI System Inference" and "AI User Input" categories

[Tyler Martin <[e-mail]>]

Right, from the outside the two systems look similar. But I don't think the vocabulary can assume anything about what's observable from outside a system. Policy and infrastructure get built on these definitions, so they should attach to what is possible, not known. Let the individual players make decisions around use and transparency as they may, then let the courts decide. 

> 1. infer(train(X + other_training_data), inference_inputs)
> 2. infer(train(training_data), X + other_inference_inputs)


On your two cases: in case 1, X is used once and its value persists in the weights, reaching every future answer with no further event. In case 2, X is used every time, and each use is an event that can be counted and revoked. A publisher who changes their preference tomorrow reaches tomorrow's context window and never yesterday's weights. That's the difference in kind, and it's why they deserve separate declared preferences even when the outputs look alike.

The wasteful part is the interesting part for publishers. The per-use cost of case 2 is what makes a per-use market possible and arguably necessary for fair compensation models.

Tyler

> On Aug 19, 2026, at 10:17 PM, Martin Thomson <[e-mail]> wrote:
> 
> It seems like you are missing the thrust of Ekr's queries here, which are to highlight that the distinction between training and inference is not strictly treating the system as opaque.
> 
> If you can excuse something that looks like code, the effect is that the following two things are hard to distinguish from the outside:
> 
> 1. infer(train(X + other_training_data), inference_inputs)
> 2. infer(train(training_data), X + other_inference_inputs)
> 
> Your point about where the intermediate outputs end up is perhaps why the two aren't identical, just similar.  That the model is then used for many things is perhaps where the concern comes from, whereas putting X into the context window every time is sufficiently wasteful that there is a difference in degree.
> 
> On Thu, Aug 20, 2026, at 12:43, Tyler Martin wrote:
>> One sentence we can/should add to the training 
>> definition to close it:
>> 
>> "Using outputs generated from an asset during inference in the 
>> production or refinement of a model is use of that asset under this 
>> category."
>> 
>> The alternative, documenting that train-ai=n doesn't reach synthetic 
>> data, would just be publishing the workaround.
> 
> I'm not sure that this is necessary.  Though it can get complicated. If your concern is that distillation is not considered train-ai usage, then that depends on selectively looking at scopes.  
> 
> In the example, the teacher is running inference and the student is training.  The overall process is training AI and it takes the asset as an input.
> 
> Inference excludes training already, so it would not apply in this scenario if your scope is the overall training process.  Unless you change the scope over which you look to only include the teacher model and its use of the asset for inference.
> 
> Of course, we hear that some labs are concerned that their inference is being used in distillation to train other models.  If they are ignorant of this possibility, that leads to a problem: do they have to consider train-ai when it comes to their inference?  (Most have terms of use that prohibit distillation, so maybe they can make this a responsibility of their customers.)
> 
> Some language to clarify this would seem to be helpful if we pursue one or more inference definitions.  My guess is that it need not be directly normative, but more explanatory in nature.