Skip to content
Queensferry

Module 13 · Lesson 13.4

The model record

What has to be written down for a model to be reviewable, and why the exclusions matter as much as the inclusions.

Why this matters

An assumption that is not written down cannot be reviewed. It also cannot be found later, when the structure is being altered and somebody needs to know whether the original analysis covered the case.

The model record is what turns a model that only its author can check into one anybody can. It is not documentation for its own sake — every field on it exists because its absence has caused a problem.

By the end of this lesson you should be able to

  • List what a model record must contain and why each item is there
  • Record exclusions as deliberately as inclusions
  • Write a limitation in a form that survives being read out of context
  • Recognise when a model has been asked a question its record does not cover

What goes in

Purpose. The engineering question this model exists to answer, in one sentence. Everything else follows from it, and a model without one will eventually be asked the wrong question.

Responsibility. Who built it, who checked it, who reviewed it, and when.

Software. Name, version, solver. Versions matter: results can change between them, and 'we used the current version' is not reproducible two years later.

Model type and analysis type. One-dimensional, two, three; linear, second-order, nonlinear, modal. And why — the justification for linear analysis is a validation statement.

Units and origin. Stated once, explicitly. Half the errors in Module 12 begin here.

Materials, sections, supports, releases, constraints. What was assumed, with the reasoning for anything not obvious. 'Bases pinned' needs a reason; 'bases modelled with rotational springs of 8 000 kN·m/rad from the geotechnical report' needs a reference.

Loads and combinations. Including which combinations were not run and why.

Warnings. What the solver reported, and what was decided about each.

Validation and verification carried out. What check, what it compared against, what the result was. 'Checked' is not a record.

Sensitivity studies. Which variables, what range, what the answer did.

Limitations. What this model cannot be used for.

Exclusions are as important as inclusions

This is the part that gets left out, and it is the part a reviewer most needs.

A model record that says what was included lets a reviewer check those things. A record that also says what was deliberately excluded, and why lets them disagree — which is the only way a review adds anything.

'Non-structural partitions excluded: they contribute stiffness at serviceability but cannot be relied on for the life of the building, and their layout is not yet fixed.'

A reviewer can now engage with that. They might agree, or point out that the vibration assessment depends on exactly that stiffness. Without the sentence they cannot tell whether partitions were considered and dismissed, or never thought about.

The same applies to load cases not run, behaviours assumed negligible, and members left out of the model. Say so, and say why.

Writing a limitation that survives

A limitation will be read by someone who has not read the rest of the record, six months later, looking for permission to do something. Write it accordingly:

Weak: 'Model is for global analysis only.'

Strong: 'This model uses one-dimensional elements throughout and contains no representation of connection geometry. It must not be used for connection design, for local stress at any joint, or for any assessment of the column base other than the overall force and moment transmitted to it.'

The second names what the model cannot do and what somebody might mistakenly try to use it for. That is the sentence that stops the misuse.

What this is not

The workspace in this course produces a Queensferry model review record. It is a teaching artefact and a reasonable structure for organising the information. It is not a category 2 or category 3 checking form, it is not a substitute for whatever your organisation's quality procedures require, and it makes no claim to satisfy any external requirement.

Try it

Model assurance workspace

Build a model record. The workspace names what is missing rather than reporting a completeness score, because the fields are not equally load-bearing.

Fields completed
0 of 14
Load-bearing fields missing
6
Record status
incomplete

Missing, and why each matters

  • Engineering question: What this model exists to answer, in one sentence.
  • Analysis type, and why: The 'why' is a validation statement.
  • Supports and releases: 'Bases pinned' needs a reason.
  • Verification carried out: What check, against what, with what result.
  • Deliberate exclusions: What was considered and left out, and why. A reviewer needs this to disagree.
  • Limitations: What this model must NOT be used for. Write it for someone reading it out of context.

This produces a Queensferry model review record. It is a teaching artefact and a reasonable structure for organising the information. It is not a category 2 or category 3 checking form and makes no claim to satisfy any external requirement.

What this model exists to answer, in one sentence.

Name and date.

Name and date.

Results change between versions.

The 'why' is a validation statement.

Stated once, explicitly.

With the reasoning for anything not obvious.

'Bases pinned' needs a reason.

Including which were NOT run, and why.

What was reported and what was decided about each.

What check, against what, with what result.

Which variables, what range, what the answer did.

What was considered and left out, and why. A reviewer needs this to disagree.

What this model must NOT be used for. Write it for someone reading it out of context.

6 load-bearing fields still empty. A completeness percentage would be misleading here — these are the ones a reviewer needs most.

What this shows: An assumption not written down cannot be reviewed — and the exclusions matter as much as the inclusions, because they are what a reviewer can disagree with.

Practice

A model record has 14 required fields. Twelve are filled, but 'exclusions' and 'limitations' are both empty. What percentage of fields are complete, and would you accept the record? Give the percentage.

Worked example

What a model record has to contain to be worth writing

Given

  • A model record states: 'Frame analysis, ULS combinations, March 2026, checked'

Find

What a reader could do with it in a year

    Check yourself

    Which entry in a model record is most often missing and most needed?

    Summary

    • Purpose first — a model without a stated question will be asked the wrong one
    • Record decisions and reasons, not settings a reviewer can read from the file
    • Exclusions let a reviewer disagree, which is the only way review adds anything
    • Write limitations for someone reading them out of context and looking for permission
    • Software version belongs in the record; results change between versions
    • The record is a teaching artefact, not a substitute for any formal checking procedure
    Progress is kept in this browser only.

    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