P1-4.2 Input, Output, and Data¶

Section ID: P1-4.2 Version: v2026.07.20

Section 4.1 described a model as a computable representation reduced for a purpose rather than the whole real-world problem. Now we move to the first three elements that should be separated when we describe that model: what we put in, what we want to get out, and what kinds of cases we need to gather.

This section organizes input, output, and data. feature, representation, and parameter are handled in 4.3.

The running example is still: we want AI to help with customer-support messages. We keep changing that situation slightly to see how input, output, and data separate from each other.

In Part 1, the basic distinction among input, output, data, example, and label is fixed in this section. The basic distinction between model and system was fixed earlier in 4.1, and the differences among feature, representation, and parameter are handled in more detail in 4.3. Here the focus is narrower: first separate what goes in and what should come out from what kinds of cases must be gathered.

This is not yet a modeling task. The phrase “help” is too broad. That broad phrase has to be split into input, output, and data before it becomes a smaller task a model can take responsibility for.

This section organizes the following questions.

• What roles do input, output, and data each play?
• Why does the same real-world problem become a different task when input and output are defined differently?
• Why should data be read not as a pile of files, but as a collection of examples?

The relation among features, representations, and parameters returns immediately in 4.3, and the way problem definition changes model choice continues in 4.4. The structure by which input and output are turned into actual feature and representation computation reconnects later in the machine-learning chapters of Part 4 and the neural-network chapters of Part 5. Here the focus stays on separating what goes in and what comes out.

Separating Input, Output, and Data¶

• Distinguish the roles of input, output, and data.
• Understand the perspective of reading a real-world problem as a relation between input and output.
• See that the same real-world problem can require different data depending on how input and output are defined.
• Understand that data is not just a file collection, but a collection of examples that gives the model a learning standard.
• Prepare to move into features and representations in 4.3.

Three Standards¶

When a real-world problem is reduced to a computable one, the following three points should be separated first.

input, output, data, example, and label are the core terms that carry the whole section. At this stage, a broad first distinction is enough: input is the information put in, output is the result we want, data is a bundle of examples, an example is one case, and a label is the name of the desired answer. Each term is tied together once more in the body below.

The part that is especially easy to confuse here is input versus data. An input is closer to one piece of information the model receives for one judgment right now, while data is closer to a training bundle where many such input-output cases are collected together. For example, the sentence When will the delivery arrive? can be one input, while a table containing thousands of such message sentences and their correct classes is data.

Also, one input case does not have to mean only one value. We may feed in only the message sentence, but if needed we can treat message sentence + order state + customer tier + recent delivery events as one bundle of input information. In this section, the structure stays clear if we distinguish input = the bundle of information the model receives for one judgment from data = a large collection of those input bundles and output cases.

Turning a Problem into a Computable Form¶

AI models do not handle the whole real-world problem directly. People select part of the situation as input, then define what output the model should produce.

For example, we want to handle customer-support messages is not yet a modeling task. It is too broad and vague.

We can narrow it step by step.

By the third statement, the task becomes much closer to a modeling problem, because we can finally see what goes in, what should come out, and what past cases are needed.

To become an AI modeling task, the problem must be narrowed like this.

Then the real-world task is organized into the following structure.

input -> model -> output

flowchart TD
  R["Real-world problem"]

  R --> I["Input"]
  R --> T["Target output"]
  R --> D["Past cases"]

  D --> L["Training"]
  L --> M["Trained model"]
  I --> M
  M --> P["Prediction for a new case"]

This diagram shows that we do not place the whole real-world problem directly into the model. We first separate it into input, target output, and past examples, then connect them through training and prediction. The real-world problem at the top is still a broad real-world issue, and as the structure goes downward, what the model will actually see and what it will be asked to predict become narrower. The safest way to read this figure is not as a machine that solves reality directly, but as a process that cuts a real-world problem into a smaller computable task.

The Stanford Encyclopedia of Philosophy entry on AI introduces Russell and Norvig’s view of an intelligent agent as a function that receives percepts from an environment and performs actions. That perspective is useful here because it helps read an AI problem as a relation between input and output, or between perception and action.

This structure is still a simplification for learning. In a real service, there may be preprocessing, permission checks, and personal-information removal before the input, and human review, policy rules, or business-system integration after the output.

Input Is What the Model Observes¶

Input is the information the model receives for judgment. It may be a sentence, an image, a sensor value, or tabular data.

When defining input, one important point is this: what matters in reality and what actually goes into the model are not always the same.

The customer-support example makes this clearer.

In that case, the model judges only from the message sentence. Even if delivery state matters to a human, the model cannot use it if that information is not part of the input.

For example, the following two messages may look similar if only the sentence is visible, but the actual handling can differ.

So deciding the input means deciding what to show the model. At the same time, it also means deciding what not to show the model.

That is why defining input requires questions such as the following.

What information can the model actually see?
Is that information enough for the judgment?
Is any important information missing?
Does the input contain personal or sensitive information?

input, output, data, example, and label can sound similar. So they should be tied together once here as a baseline before the later paragraphs keep reading input and output definitions on top of that distinction.

At this stage, it is enough if the following distinction remains: input is the information put in, output is the result we want, data is the bundle of such cases, and label is the name of the desired answer.

Output Is the Job Given to the Model¶

Output is the result the model must produce. Even with the same input, the problem changes completely depending on how we define the output.

For example, the same customer-support sentence can be connected to several different outputs.

So saying we use AI to handle customer-support messages is not enough. We must decide whether the model should output a category, a number, a sentence, or a review flag. The way each output form leads to a different modeling task is organized separately in 4.4.

Suppose the input is the following sentence.

I ordered yesterday, but tracking still does not work.

Even this single sentence becomes a different task depending on the output definition.

The important point here is that even when the input stays the same, once the output changes, the required data changes too. To build a model that chooses a message type, past messages must have labels such as delivery, refund, and exchange. To build a model that generates draft replies, good answer examples or answer-writing standards are needed instead.

Defining output requires questions such as the following.

Does the model only need to choose one category?
Does it need to output a numeric score?
Does it need to generate a sentence?
Is an intermediate result for human confirmation enough?
Is this output actually connected to the real business goal?

Data Is a Collection of Input-Output Examples¶

Data is the collection of cases the model uses for reference or training. In supervised learning, we usually use examples that contain both input and the desired output.

Google’s introductory material explains that an example in supervised learning contains features and a label. In this section, we read that more simply: one example is a bundle of input + desired output.

This table is simple, but it shows an important structure.

example 1 = input 1 + output 1
example 2 = input 2 + output 2
example 3 = input 3 + output 3
...

To say it more slowly, data is a collection of past cases shown to the model.

When this kind of input came in,
people expected this kind of output.

The model adjusts the relation between input and output through this repeated set of cases. Since this section does not yet go deeply into features, it is enough to understand data as examples where the input the model looks at and the desired output are kept together.

The pace should also slow down when creating data. Even with the same customer-support message, if the label standard keeps shifting, the model has difficulty learning.

Data like this may exist as files, but it is hard to call it good learning data. The standard the model is supposed to learn keeps moving.

A better dataset needs the label standard to be organized first.

Learning-based models use these examples to adjust the relation between input and output. But the existence of data does not automatically guarantee a good model. A model cannot reliably learn relations that are absent from the data, and it can also learn the wrong relations if the data itself is wrong. We have to check whether the data represents the real usage environment, whether the output labels are consistent, and whether incorrect cases are mixed in.

When Input and Output Change, Data Changes Too¶

One real-world problem does not always correspond to one fixed dataset. The shape of the dataset changes depending on what input and output are chosen. In this section, we only confirm the shape of the data; task definition and evaluation criteria continue in 4.4.

Consider the goal we want to reduce delivery problems.

This example shows that the input and output definitions determine the shape of the data. Even with the same business goal, different input and output choices require different data.

Put the other way around, it is not enough to say only let’s collect a lot of data. We have to decide first what input and output that data is supposed to teach.

Even under the same broad phrase delivery problem, the shape of the data changes as soon as the job given to the model changes. The questions of how to define the task, what candidate models fit it, and what evaluation criteria should be used continue in 4.4.

Input and Output Definitions Must Be Checked First¶

The reason a model fails is not always in the algorithm. The input or output definition may have framed the problem incorrectly from the start. Section 4.2 only confirms this as an early warning.

For example, suppose the goal is to reduce customer complaints, but the input is only the message sentence and the output is only the message type. That model may classify messages, but it does not directly solve whether the cause of the complaint is delivery delay, product quality, or refund policy.

Mistakes like the following are common.

Whether the data matches the real environment, whether performance holds after deployment, and how sensitive information should be handled are discussed in more detail later under problem definition, evaluation, and service architecture.

Can this input really support judging this output?
Is this output connected to the problem we actually want to solve?
Does this data represent the situation in which the model will really be used?

A Short Exercise in Role Distinction¶

Look at the cases below and first separate whether the issue is closer to an input-definition problem, an output-definition problem, or a data-definition problem.

The key to this exercise is not to treat every model-performance problem as an algorithm problem immediately. In practice, the first trouble often appears in what was put in, what the model was asked to predict, and what cases were gathered.

Checklist¶

• I can distinguish the roles of input, output, and data.
• I can rewrite a real-world problem into the structure input -> model -> output.
• I can explain that even with the same input, different output definitions can require different data.
• I can explain that data is a collection of input-output examples.
• I can explain that data becomes the basis for adjusting the model’s internal standards.
• I can explain that if input and output are defined badly, the problem can begin before data preparation does.
• I can explain that a real-world problem becomes a model problem only after input, output, and data are defined.
• I can explain that even for the same real-world problem, changing the input or output definition changes the data that must be collected.

Sources and Further Reading¶

• Stanford Encyclopedia of Philosophy, Selmer Bringsjord and Naveen Sundar Govindarajulu, Artificial Intelligence, 2018-07-12, accessed 2026-06-22.
• Google for Developers, Supervised Learning, accessed 2026-06-22.