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

[Tyler Martin <[e-mail]>]

On 6.4, I should have said that's how I understand it. I’ll defer to the group though.

> On Aug 20, 2026, at 9:27 AM, Tyler Martin <tyler=[e-mail]> wrote:
> 
> I took a pass at the draft text and opened a PR: https://github.com/ietf-wg-aipref/drafts/pull/225
> 
> It builds on Nate's #216 (his commits are at the base, rebased onto -07) and adds a defined term, "selection step," that makes the user/system line mechanical. A selection step is an operation by any party or process other than the human user that identifies an asset: searching, browsing, ranking, recommending, resolving a description. If nobody did that, it's user-directed. If anything did, it's system-directed. System is the catch-all.
> 
> By the way, under §6.4, any category that isn't in the base document degrades to "unknown" permanently for conforming recipients. Unknown labels must be ignored, and adding new ones requires an updating RFC. If inference categories are going in, they have to be in this document before it ships.
> 
> Again, please feel free to walk any scenario through the vocabulary to resolve the category: https://claude.ai/code/artifact/a4a1f206-1759-454b-8b03-90861d8d110b
> All the mailing list examples are in there. Same input, same answer, every time.
> 
> Tyler
> 
>> On Aug 20, 2026, at 3:03 AM, Nate Hake <[e-mail]> wrote:
>> 
>> I just want to clarify for the group that the training definition actually no longer uses the "production or refinement" language. In the new Vocab V7 draft <https://datatracker.ietf.org/doc/html/draft-ietf-aipref-vocab-07>, it uses Kevin's "learned parameters" language instead -- and so that is why my PR uses that language as well. 
>> 
>> 
>> 
>> ***
>> 	
>> Nate Hake
>> Founder
>> TravelLemming.com <https://travellemming.com/>
>> 
>> On Thu, Aug 20, 2026 at 7:29 AM Tyler Martin <[e-mail] <mailto:[e-mail]>> wrote:
>>> 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] <mailto:[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.
>>> 
>> -- 
>> ai-control mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
> 
> -- 
> ai-control mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]