Module 1 · Lesson 1.3
Responsibility for the output
Who owns a computational result, what a review is for, and why 'the software gave me that' is not a defence.
Why this matters
Structural failure is rare, and when it happens the analysis is usually not the sole cause. But there is a recurring pattern in investigations of failures involving computation: the model produced an answer, the answer was used, and nobody had established what the model could not tell them.
This lesson is about the professional position that follows from that, and about what a review has to do in order to be worth having.
The position
The engineer is responsible for the computational output, including the parts nobody looked at.
This is not a matter of opinion about software quality. Professional analysis software is written carefully, tested against benchmarks and used by thousands of engineers. Bugs exist and they are rare. The failures that matter are almost always in the model, in the interpretation, or in the gap between what the software does and what the user believed it did.
That third one deserves naming. The most consequential category is not 'the software was wrong' but '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. An output that reports displacement at one point per floor. In each case the software behaves exactly as designed and documented, and the engineer has assumed a capability it never claimed.
What a review has to do
A review that reads the same model the same way, from the same assumptions, adds very little. To be worth its cost a review has to bring something independent:
- A different route to the answer. Hand calculation, simplified model, alternative software.
- A different set of eyes on the assumptions. Not 'is the model built correctly' but 'is this the right model'.
- The questions that were not asked. What load case was not run, what behaviour was assumed away, what does this model not cover.
That last one is where reviews earn their keep and where they are most often skipped, because it requires the reviewer to think about the structure rather than to check the model.
Recording assumptions
An assumption not written down is an assumption that cannot be reviewed. The model record introduced in Module 6 and completed in Module 13 exists for this: it is the difference between a model somebody could check and a model only its author can.
And write down what you decided not to check, and why. A reviewer who knows you considered a load case and dismissed it can disagree with your reasoning. A reviewer who cannot tell whether you considered it has to redo your work to find out.
Practice
A model reports a total vertical reaction of 4,820 kN. The building is 6 storeys, 32 m × 18 m on plan, and the design permanent plus imposed load is 9.5 kN/m² at the serviceability limit state. Estimate the expected total reaction in kN, and state the ratio of model to estimate to two decimal places.
Check yourself
An analysis is run on a vendor's cloud solver. Where does responsibility for the analysis sit?
Summary
- The engineer is responsible for the output, including the parts nobody looked at
- The commonest serious failure is not a software bug but a capability the user assumed and the software never claimed
- A review is only worth its cost if it brings an independent route, independent eyes on assumptions, or the questions nobody asked
- Write down what you decided not to check, and why
- An unexplained disagreement is a finding, and it stays open
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