What vocabulary is best suited to answer questions about the how a particular inputoutput mapping is calculated? To explore this question, let us consider an example calculating device, a Turing machine (Turing, 1936). This calculator processes symbols that are written on a ticker-tape memory divided into cells, where each cell can hold a single symbol. To use a Turing machine to add (Weizenbaum, 1976), a user would write a question on the tape, that is, the two numbers to be added together. They would be written in the format that could be understood by the machine. The Turing machine would answer the input question by reading and rewriting the tape. Eventually, it would write the sum of the two numbers on the tape—its answer—and then halt.
How does a Turing machine generate answers to the written questions? A Turing machine consists of a machine head whose actions are governed by a set of instructions called the machine table. The machine head will also be in one of a set of possible physical configurations called machine states. The machine head reads a symbol on the tape. This symbol, in combination with the current machine state, determines which machine table instruction to execute next. An instruction might tell the machine head to write a symbol, or to move one cell to the left or the right along the tickertape. The instruction will also change the machine head’s machine state.
A Turing machine does not answer questions instantly. Instead, it takes its time, moving back and forth along the tape, reading and writing symbols as it works. A long sequence of actions might be observed and recorded, such as “First the machine head moves four cells to the right. Then it stops, and replaces the 1 on the tape with a 0. Then it moves three cells to the left.”
The record of the observed Turing machine behaviours would tell us a great deal about its design. Descriptions such as “When given Question A, the machine generated Answer X” would provide information about the input-output mapping that the Turing machine was designed to achieve. If we were also able to watch changes in machine states, more detailed observations would be possible, such as “If the machine head is in State 1 and reads a ‘1’ on the tape, then it moves one cell left and adopts State 6.” Such observations would provide information about the machine table that was designed for this particular device’s machine head.
Not all Turing machine behaviours occur by design; some behaviours are artifacts. Artifacts occur because of the device’s design but are not explicitly part of the design (Pylyshyn, 1980, 1984). They are unintentional consequences of the designed procedure.
For instance, the Turing machine takes time to add two numbers together; the time taken will vary from question to question. The amount of time taken to answer a question is a consequence of the machine table, but is not intentionally designed into it. The time taken is an artifact because Turing machines are designed to answer questions (e.g., “What is the sum of these two integers?”); they are not explicitly designed to answer questions in a particular amount of time.
Similarly, as the Turing machine works, the ticker tape adopts various intermediate states. That is, during processing the ticker tape will contain symbols that are neither the original question nor its eventual answer. Answering a particular question will produce a sequence of intermediate tape states; the sequence produced will also vary from question to question. Again, the sequence of symbol states is an artifact. The Turing machine is not designed to produce a particular sequence of intermediate states; it is simply designed to answer a particular question. Multiple Levels of Investigation 43
One might think that artifacts are not important because they are not explicit consequences of a design. However, in many cases artifacts are crucial sources of information that help us reverse engineer an information processor that is a “black box” because its internal mechanisms are hidden from view.