Consistency is a verification attribute because it is as
much a logical concept as a science concept. Outside the strict mathematical
meaning, consistent means "free of contradiction." A mathematical example of inconsistency
would be the logical statement of the form "If P then Q1 and Q2"
where Q1 and Q2 cannot be true simultaneously. A physical
example of inconsistency might be a statement of values that cannot possibly be
simultaneously true, such as the following values for percentages of nitrogen
and oxygen in the atmosphere - [N] = 75%, [O] = 75% - which could not possibly be
true as the result adds to more than 100%.
According to the Routledge
Dictionary of Philosophy, the term "justification" belongs to a set of terms
that also includes "rational", "reasonable" and "warranted". These terms don't have universal definitions or relationships. For our use, justification would
involve derivation or mathematical proof. An example would be any mathematical
mistake such as misapplication of differentiation to get an improper answer.
Justification should be reasonably intuitive to people since the common meaning
is also the technical meaning. In general, justification is giving evidence.
Law-like verification involves indicating the scientific
laws used in investigations. At the verification stage, this means that the
model should start from known physical laws. (The issue of whether the results
of a model agree with physical laws will be discussed in model validation).
Consider a model of a chemical reaction. A verification to show that the model
is law-like would be a mathematical proof that mass is conserved in the model.
Reasons are propositions that meet
certain conditions such as being true or believed by someone. Suppose we have a
proposition Q and we also have a statement "If Q then P" then we have some
"reason" to believe P. But we need an external reason to believe Q. So for
someone to actually believe P, they must also believe Q as a reason to
believe P.
Unfortunately, often when
performing verification testing we do not have access to the full details of
the model implementation, and must perform verification testing by looking for symptoms
of a model with verification errors. In particular, in the case of a model that
has been implemented as a computer simulation, we may very well not have the
code. Even in the case where we do have the code, as an external reviewer it
can be prohibitively time consuming to browse through possibly thousands of
lines of someone else's computer code. As a result, in verification testing we
often do not check to see if the tenets of verification themselves are being
upheld, but instead we look for the symptoms of a failure of verification.
When creating computer simulations
based on models, one must start from assumptions and laws and implement them
into computer instructions. One of the most common cases of a model that cannot
be justified is one in which the implementation of the model has errors in
those computer instructions - it has bugs! Some symptoms of buggy programs are
obvious... the code will not compile, the code crashes frequently, the code will
not run on a given platform, the results of the code display improperly. Other
symptoms of buggy programs are harder to find, and may not be noticed until
validation testing.