Okay, let me expand a bit on that post from last week. If a language transform takes one known class of input and produces one known class of output, that boundary gives us something unexpectedly useful: a place to define what the transform actually owes the system.
Imagine a practice scene where someone is trying to respond to a manager pressing for an immediate answer. The learner says, “Sure, whatever you want.”
Did they agree? Give in reluctantly? Push back with sarcasm? I don’t think the model can discover some hidden, objective truth about the learner’s feelings. But it may be able to interpret what that reply communicates in this scene, given the relevant exchange and the kinds of communicative moves the system knows how to handle. And if the language doesn’t support a clear interpretation, “unclear” should be a possible result. “Unclear” is something a chatbot or an agent is really bad at. But an isolated process tasked with mapping input against probable meanings from a list, with a confidence cutoff the process was not given context on, but the system owns unambiguously? That’s a little different.
Now we can test the transform. Give it different ways people express agreement, reluctance, and pushback. Change the surrounding exchange where that changes the meaning. Look closely at the cases where human readers disagree, because those are the cases where a confident label can do the most damage.
Then test the system separately. Given a particular interpretation, does the scene follow its authored rules? Does it preserve the learner’s progress? Can it ask for clarification rather than treating an ambiguous reply as a decision? Those are ordinary, repeatable questions about system behavior.
This doesn’t mean every transform has to produce a label. It might produce dialogue, code, or some other representation the system can use. Maybe it even is allowed to propose a result class that is novel: so long as 1: the proposed result is proposed in a predefined format, and 2: an unrelated transform maps that against allowable patterns and encodes it as concrete data or rejects it. The point is to define the input and output classes for that operation, then evaluate whether the meaning that matters survives the trip between them.
That’s the distinction I was trying to reach in my essay on testing LLMs like software. We can evaluate the semiotic work at its boundary, and test the rules and state of the system that makes use of it. When you just ask an LLM chatbot to “Evaluate this for me” you’re collapsing thousands of tiny transforms, assumptions, processes, and decisions and hoping the model “figures it out” for you each time.