Data, Parameters, And Instructions Are Different

The retailer changes its return policy. Yesterday, customers had fourteen days to return an umbrella. Today, they have thirty. Someone says, “We need to teach the AI the new policy.” Before choosing a solution, we need to ask what that would actually change. Does the model need different learned values?

Does the application need to supply the current document? Or does it need a clearer instruction about using that document? Those are different interventions. A change in an assistant's answer doesn't, by itself, tell us which one happened. In Lesson three, we followed information through a physical computer. Today, we'll distinguish the roles

information plays inside an AI system. Our route is: name the parts, follow one request, then choose what needs to change. We'll keep returning to the retailer's assistant, so the differences stay concrete. Start with data. Data is information supplied to, or produced by, a process.

Calling something data is a starting point. We also need to name its role in the particular process we're discussing. Training data provides examples used during learning. A model might be trained using examples of questions and answers, images, sales records or other material, depending on the task. The examples are used by a

learning procedure to help shape the model. We aren't describing how that procedure works in detail yet; that's the next lesson. Input data during use is the material the system processes for the current task. The retailer's customer question and the policy document supplied with it can be input data. Output data is the result produced.

An answer describing the return conditions is output data. The same file can have different roles in different workflows. Suppose a policy document is included among examples used to adjust a model. In that workflow, it is training data. Suppose an application instead sends that document with today's customer question to an already trained model. In this workflow, it is input data during use.

The file's name doesn't determine its role. What the system does with it does. That distinction matters because supplying a document for one request doesn't establish that the model has learned it through a change to its internal values. The model may use information available in that request without retaining it in its learned parameters for later requests.

Parameters are values inside a model that control its computations. In many neural networks, these include weights learned during training. A weight changes how strongly one value influences another part of a calculation. You don't need to know neural-network mathematics to keep that role separate from a policy file supplied today. For a small arithmetic illustration,

imagine a calculation that multiplies an input by a value stored inside the model. Changing that stored value changes the calculation, even if the input stays the same. Real models can have many interacting parameters and more complex computations. This illustration only establishes what a parameter does: it helps determine how the model transforms inputs into outputs.

A learned weight is not necessarily a stored sentence. You shouldn't picture a model as a cabinet in which each weight contains one policy fact, neatly labeled with a source citation. Learned parameters collectively encode patterns useful to the learning objective, the result the learning process is working toward. That also means a fluent answer isn't evidence

that you can identify one weight containing its claim. A system might use patterns learned earlier, information supplied now, or both. To explain where an answer came from, we have to inspect the system's actual information sources and mechanisms. Now add instructions. An instruction supplied to an assistant can say

what behavior is wanted in the current interaction. “Answer in three bullet points” is an instruction. “Use the supplied return policy and cite its identifier” is another. These instructions enter the interaction during use. They can influence the answer without changing the model's weights. If the next request asks for a short paragraph instead of three bullet points,

the system can supply a different instruction. That is a change to what the model is being asked to do, not evidence of a new training process. The policy and the instruction have different roles, even when both arrive as text. The policy supplies information about the retailer's rules. The instruction tells the model

what to do with that information. One answers “What material is available?” The other answers “What behavior is requested?” There is also application code: the ordinary software surrounding the model. It can impose rules, validate output, limit available tools and manage permissions. Validation means checking whether an output meets a condition,

such as whether a cited identifier actually appears in the supplied policy. A natural-language instruction asking the model to cite a source and a software check of the returned citation are different controls. A request to behave correctly doesn't prove the behavior occurred. The application can inspect the result and decide whether it is acceptable to return,

whether another step is needed, or whether the request should stop. We've named the main parts: data in different roles, learned parameters, supplied instructions and application controls. Now let's follow one complete request and see where each part is working. The retailer's model has already been trained. Its learned weights are in place

before today's customer asks a question. The customer asks, “Can I return this umbrella after twenty days?” The application obtains the current return policy. For this example, the document says that eligible umbrellas can be returned within thirty days, subject to its conditions. Its identifier is Returns twenty-five.

The application supplies that document with the customer's question. The application also supplies an instruction: use this policy and cite its identifier. The policy is input context, information made available for this request. It is not necessarily part of the model's learned parameters. The instruction specifies how the model should use that context. The model generates an answer.

It can explain that twenty days is within the stated thirty-day period, while keeping the policy's eligibility conditions. It cites Returns twenty-five. That generated text is output data. Producing the answer has not, by itself, established that the weights changed or that the citation is valid.

The application can then check the citation against the supplied document. If the returned identifier is missing or different, the check can fail even though the answer sounds convincing. If the identifier matches, that establishes the identifier match. It doesn't automatically establish that every eligibility condition was interpreted correctly. The checks should be named for what they actually verify.

Notice the sequence. The model brings learned parameters. The application supplies the current question, policy and instruction. The model produces an answer. The application may check it afterward. These are related stages, but they aren't the same mechanism. Return to the change from fourteen days to thirty days. If the application keeps supplying yesterday's document,

today's answer may be outdated even with exactly the same model. Supplying the current policy can change the answer without changing a weight. As in Lesson two, we need to locate the failed step before choosing a repair. We've followed one request. The third part of our route

is choosing what needs to change. Three approaches are often confused: fine-tuning, retrieval and conversation memory. We'll learn their implementation and selection in later modules. Here, we need to identify what each changes. Fine-tuning updates a model's parameters using additional learning data and an objective. It is another learning process applied to a model.

For example, a team might use suitable examples to improve a model's recurring response behavior. The relevant point here is that parameter values are updated. Fine-tuning isn't simply attaching a current document to one request. Retrieval selects external information during use and supplies it as context. In the retailer's example, the application can find the current return-policy document and include it with the question.

The selected document changes what information is available in the interaction. That doesn't, by itself, change the learned weights. Conversation memory stores selected information for later use through an application mechanism. Suppose a customer explicitly says, “I prefer concise answers.” The application can preserve that preference and supply it in a later request.

The assistant may then produce a concise answer even though the model's parameters are unchanged. Conversation memory here is an application feature. It isn't the working memory hardware we discussed in Lesson three. Both involve information being available for use, but they refer to different levels of the system. Name the mechanism so the

word memory doesn't hide the distinction. These approaches can all improve a product, but each changes a different part. Fine-tuning changes parameter values. Retrieval changes which external material is supplied during use. Application memory preserves selected information and reintroduces it later. A change in behavior alone doesn't tell us which approach caused it.

Let's diagnose three situations using that distinction. First, a policy changes every week. The task requires the current policy, including conditions that may change again next week. Retrieving the current document may be more appropriate than repeatedly updating model weights to teach each revision. That is a diagnosis of the information need, not a guarantee that retrieval will be implemented well.

The application still needs the right document, appropriate access and checks of the resulting answer. Selecting an approach doesn't remove the need to evaluate the whole product. Second, the assistant repeatedly uses an unwanted format. Perhaps the retailer wants short, clearly separated answers, but receives long paragraphs. Clearer instructions may address that behavior.

Fine-tuning with suitable examples and an objective may also be considered for a persistent behavior problem. We need evidence about what is failing before deciding which intervention is justified. Third, the application forgets a user's explicitly stated preference between sessions. That may call for an application memory mechanism that stores the preference and supplies it later.

Updating model weights is not the only way to make the preference available. We should first check whether the product preserved and reintroduced it at all. This is why “make the AI better” isn't a sufficiently precise repair plan. Is the problem missing current information, unwanted response behavior, or a preference

that the application didn't carry forward? The answer determines which part of the system deserves investigation. There is also an economic connection. Each intervention brings different development costs, costs of serving requests, maintenance work, evaluation requirements and rights questions. Development means building or changing the system. Serving means operating it for users.

Maintenance includes keeping information and software usable as circumstances change. For the retailer, someone must keep the policy source current and manage access to it. A fine-tuning approach also requires appropriate learning data, a learning process and evaluation of the changed model. An application memory feature needs a deliberate choice about what to retain and how to use it.

These aren't interchangeable purchases with the same ongoing obligations. Rights questions include whether the organization has permission to use material in the intended way. Possessing private documents doesn't automatically justify building a new foundation model, a broadly trained model that can support many tasks. A business may need better access to existing information rather than a new general-purpose learned system.

Start with the actual information and behavior problem. We've now completed our route: name the parts, follow the request, then choose what needs to change. Let's check your understanding before the recap. First question. An assistant uses your preferred concise tone because the application stores the preference and supplies it in future requests.

Must the model's weights have changed? No. The application can preserve and reintroduce the preference without changing weights. You need evidence about the implementation before calling that mechanism training or fine-tuning. This checkpoint highlights the distinction: the observed change in behavior doesn't establish how it was produced.

Second question. The application supplies a current return-policy document and separately says, “Cite the policy identifier.” Which part supplies task information, and which part specifies the requested behavior? The policy supplies input context for the task. The instruction asks the model to use it in a particular way.

Both may be text in the same interaction, but their roles are different. Neither act of supplying them, on its own, proves a parameter update occurred. One final question. The model produces an answer with a policy identifier. Has the instruction to cite it already proved that the identifier is valid?

No. The instruction requests a behavior. A check afterward can compare the returned identifier with the supplied source. A matching identifier is evidence of that match, not proof of every other property of the answer. To recap, data takes its role from the process: examples used in learning,

inputs supplied during use, or outputs produced. Parameters are internal values controlling computations. Supplied instructions can guide behavior without changing those values. Application code can provide additional controls and checks. Our retailer could supply a new policy, change an instruction, preserve a preference, or update parameters through learning. Those interventions can change an answer for different reasons.

Before choosing one, identify the part that needs to change, the evidence for that diagnosis, and the costs and responsibilities that follow. For a practical check, take a familiar assistant interaction. Identify the current task information, the requested behavior, any information retained from an earlier interaction, and anything you actually know about the model's learned values. If the implementation is unknown, say so.

Distinguishing evidence from assumptions is part of understanding the system. Next, we'll follow training and inference step by step. Today we separated the roles of examples, learned values and supplied information. Lesson five shows how a learning process adjusts a simple model, and how using the resulting model differs from changing it.