Page 135 -

132 J.M. Galán et al.

We also distinguish between errors and artefacts (Galán et al. 2009). Errors
appear when a model does not comply with the requirement specifications self-
imposed by its own developer. In simple words, an error is a mismatch between
what the developer thinks the model is and what it actually is. It is then clear that
there is an error in the model if and only if the model is not correct. Thus, verification
is the process of looking for errors. An example of an implementation error would
be the situation where the programmer intends to loop through the whole list of
agents in the program, but he mistakenly writes the code so it only runs through a
subset of them. A less trivial example of an error would be the situation where it is
believed that a program is running according to the rules of real arithmetic, while
the program is actually using floating-point arithmetic (Izquierdo and Polhill 2006;
Polhill and Izquierdo 2005; Polhill et al. 2005, 2006).
In contrast to errors, artefacts relate to situations where there is no mismatch
between what the developer thinks a model is and what it actually is. Here the
mismatch is between the set of assumptions in the model that the developer thinks
are producing a certain phenomenon and the assumptions that are the actual cause
of such phenomenon. We explain this in detail. We distinguish between core and
accessory assumptions in a model. Core assumptions are those whose presence
is believed to be important for the purpose of the model. Ideally these would be
the only assumptions present in the model. However, when producing a formal
model, it is often the case that the developer is bound to include some additional
assumptions for the only purpose of making the model complete. We call these
accessory assumptions. Accessory assumptions are not considered a crucial part
of the model; they are included to make the model work. We also distinguish
between significant and non-significant assumptions. A significant assumption is
an assumption that is the cause of some significant result obtained when running
the model. Using this terminology, we define artefacts as significant phenomena
caused by accessory assumptions in the model that are (mistakenly) deemed non-
significant. In other words, an artefact appears when an accessory assumption that
is considered non-significant by the developer is actually significant. An example
of an artefact would be the situation where the topology of the grid in a model
is accessory; it is believed that some significant result obtained when running the
model is independent of the particular topology used (say, e.g. a grid of square
cells), but it turns out that if an alternative topology is chosen (say, e.g. hexagonal
cells), then the significant result is not observed.
The relation between artefacts and validation is not as straightforward as that
between errors and verification. For a start, artefacts are relevant for validation
only to the extent that identifying and understanding causal links in the model’s
referent is part of the purpose of the modelling exercise. We assume that this is
the case, as indeed it usually is in the field of agent-based social simulation. A
clear example is the Schelling-Sakoda model of segregation, which was designed
to investigate the causal link between individual preferences and global patterns
of segregation (Sakoda 1971; Schelling 1971, 1978). The presence of artefacts
in a model implies that the model is not representative of its referent, since one
can change some accessory assumption (thus creating an alternative model which