A description that works for what we see now may still fail to predict what happens after an action. If hidden conditions have different consequences, treating them as the same can hide a difference that matters. Watch which distinctions are needed to predict change, and which details can safely be left out.

Start a fresh run. The observer receives zero: the lamp is off. That reading fits either hidden configuration u or hidden configuration v. We do not get a cutaway showing which one is actual. The letters name hidden configurations; zero and one name lamp outputs. Zero means off and one means on. We want to predict the lamp after a button called PULSE. Does the current reading tell us enough?

The rules are supplied with this teaching model. If the device started in u, PULSE would take it to w. The lamp is one in w. If it started in v, PULSE would leave it in v. The lamp there is zero. These are calculations from the known rule. We have not pressed the button on the actual device.

Before comparing the results, predict the answer. Given only the received zero, must the lamp be on after PULSE, must it be off, or is the result still undetermined?

[SILENT HOLD:5SECONDS;NOT SPOKEN]

The two possible runs start with the same lamp output, zero. Starting in u gives w and then output one. Starting in v gives v and then output zero. So the result is still undetermined. The current reading has not selected one of those starting configurations. No predicted output has become a new received reading.

Now build prediction groups for all four configurations in the model. Configurations can share a group only when the group supports the same future lamp predictions for the available buttons. We must give u and v different groups: PULSE is a concrete reason to separate them. These boxes are a description of possibilities. Splitting a box does not create a new physical configuration.

Compare the other two configurations, w and z. Both have output one. They are not candidates for our earlier zero reading; we are comparing model cases to finish the prediction groups. PULSE leaves w at w and z at z. Their lamps stay on. Press PULSE again and the same thing happens. Any number of PULSE presses keeps both outputs one. There is one other available button: RESET. Its known rule sends every configuration to u. Starting in w or starting in z, the first RESET therefore brings both cases to that same state u. Every finite sequence either has no RESET, or has a first RESET. Without RESET, we just checked the repeated PULSE case. With RESET, both cases reach u together; the same later buttons then give the same states and outputs. That is why w and z can stay together.

The full model has four configurations. For lamp predictions using PULSE and RESET, three groups suffice: u, v, and w-or-z. Members of each group are predictively equivalent: they make the same specified future predictions. The combined w-or-z group reports one. PULSE keeps it in that group; RESET takes it to the u group. From u, PULSE actually goes to w. Its group destination is called w-or-z because that label groups w with z; it does not mean the button might send u to z. The other rows are shown too, so we can update the group without choosing a member inside it. But the group cannot answer every question. If the task were to report the exact configuration name, w or z would matter. Our grouping preserves this lamp-prediction task, not all possible information.

Return to the fresh run. The only received reading is still zero. All the button presses we traced were hypothetical model cases. The actual device has not been operated. We now know why u and v need separate prediction groups. Does the observer know which of those groups its device occupies?

[SILENT HOLD:5SECONDS;NOT SPOKEN]

No. Both u and v still fit the evidence. A table can show which difference matters without giving us an experiment that obtains it. Later episodes ask what observations and actions are actually available.

u and v look the same now but must be separated for future lamp predictions. w and z are different configurations that can stay together for this specified task. A useful description preserves the distinctions the task needs. We have not assigned probabilities or measured the cost of finding out. Episode four asks how uncertainty and usefulness differ.