Module 13 · Lesson 13.1
Two different questions
Validation and verification, separated properly — and why a model that passes one can fail the other completely.
Why this matters
'Checking' covers two activities that need different people, different evidence and different timing, and conflating them is how a thoroughly checked model turns out to be a model of the wrong structure.
The distinction has a standard form and it is worth learning in that form, because it is what a reviewer will expect and what a model record has to demonstrate.
By the end of this lesson you should be able to
- Define validation and verification precisely
- Classify a given check as one or the other
- Give an example of a model that passes verification and fails validation
- Recognise software invalidity as distinct from software error
What you should already know
- The diagnostic checks of Module 12
- Deflected shapes and load paths from Structural Behaviour, which Stage 1 relies on
The two questions
Validation: is this the right model of the real problem? Does it represent the behaviour that matters? Is the software appropriate for this question?
Verification: has the model been built as intended, and are the numbers consistent?
Verification is inward-looking and largely mechanical: geometry against the drawings, sections against the schedule, loads against the load schedule, equilibrium satisfied. Much of it can be automated and all of it can be listed.
Validation is outward-looking and cannot be listed, because it asks about the fit between a model and a reality that is not in the model. It needs judgement, and it needs someone willing to ask should this be a shell model at all? rather than are the shell elements correct?
Passing one and failing the other
Verified, not valid. A three-dimensional frame with every dimension correct, every section as scheduled, every load as agreed, equilibrium satisfied to ten decimal places — analysed linearly, when its αcr is 3. Everything about the build is right and the analysis type is wrong, so the sway moments are 50 % under-reported. No verification check catches it, because nothing was built incorrectly.
Valid, not verified. Exactly the right idealisation — right elements, right supports, right analysis — with a load applied to the wrong node. The concept is sound and the arithmetic answers a different question.
Both are failures. They are found by different activities, and a review that does only one of them will miss half of them.
Software validity
Software can be invalid without being wrong. It does what it was designed to do; you are using it for something else.
The recurring pattern in serious cases is not 'the software gave a wrong answer'. It is 'the software did not do something, and nobody knew':
- A design module that does not check punching shear.
- A floor-diaphragm routine that does not account for openings around a core.
- A steel design routine assuming full top-flange restraint the real structure does not have.
- An output that reports one displacement per floor, at the centre of mass, in a building where torsion dominates and the corners move much further.
In each case the software behaves exactly as designed and documented, and the engineer has assumed a capability it never claimed.
The question to ask of any tool is not 'is it reliable?' but 'what does it not do, and would I know?' The answer is in the documentation, and reading it is a validation activity.
Three real cases, named once
Three well-documented structural failures are routinely discussed in this context: the roof collapse at the Hartford Civic Center (1978), the loss of the Sleipner A gravity base (1991), and the collapse of the CTV Building in Christchurch (2011). Each has a published investigation, and each is worth reading in the original rather than in summary.
This course names them and stops there. It does not reconstruct their models, reproduce their member forces or retell the analyses — partly because that material belongs to its authors, and partly because a summarised failure narrative teaches less than the method that would have caught it. Every diagnostic case in this course is invented for the purpose, and the Model Doctor says so on its own page.
Check yourself
A reviewer confirms that a model's geometry matches the drawings, its sections match the schedule, its loads match the load schedule, and equilibrium is satisfied. What has been established?
Practice
A frame has αcr = 3.0 and has been analysed linearly. By what percentage are its lateral deflections under-reported? Use the amplifier α/(α−1).
Worked example
Verification and validation on the same model
Given
- A floor model gives a midspan deflection of 18 mm
- A hand calculation on the same idealisation gives 17.6 mm
- The completed floor is measured at 27 mm
Find
What each comparison establishes
Check yourself
What does a successful verification establish?
Summary
- Validation: is this the right model? Verification: was it built as intended?
- Verification is listable and largely mechanical; validation needs judgement
- A perfectly verified model of the wrong structure passes every verification check
- Software invalidity is usually a capability the user assumed and the tool never claimed
- Ask what a tool does not do, and whether you would know
This is educational material. It uses simplified examples to teach principles, and must not be relied on for real design or safety-critical decisions. Module overview and checkpoint