Ask a room of architects what building energy simulation is and most will name a piece of software. That answer is the reason so many models are built and so few change anything.
A model is an argument. It says: given these assumptions about how this building is made, used and operated, here is what we should expect. The software is the part that does the arithmetic. Everything that determines whether the argument is any good happens before and after it.
Where the judgement actually sits
Three things decide whether a model earns its cost, and none of them is a menu item.
The question. "Model this building" is not a question. "Will external shading on the west façade save more than upgrading the glazing, at this budget?" is. The first produces a report. The second produces a decision.
The assumptions. Occupancy, schedules, infiltration, setpoints, the gap between how a system is specified and how it will run. These are where most of the uncertainty lives, and they are chosen by a person, not calculated by a tool. A modeller who can state their assumptions and defend them is worth more than one who knows every dialog box.
The translation. A result that arrives as a table of annual figures, three weeks after the decision was made, is not an input to design. It is a record of it.
The tool computes. The modeller decides what is worth computing, and what the answer means.
Why this matters more as tools improve
Every year the software gets easier. Interfaces improve, defaults get smarter, and increasingly the mechanical work of building a model is automated. That does not make the skill less valuable — it moves it. What gets automated is the arithmetic. What does not is knowing which question to ask, which assumptions to trust, and when a result is too good to believe.
If your professional value is that you know where the buttons are, that value is on a downward slope. If it is that you can frame a performance question and defend the answer, it is on an upward one.
What to practise instead
- Before opening any software, write the decision the model is meant to inform, in one sentence.
- Write your three most uncertain assumptions and what you would do differently if each were wrong.
- Run the comparison, not the case. A single absolute number invites false confidence; a difference between two options is what people can act on.
- Report the decision, then the evidence. Not the other way round.
None of that is software-specific. That is exactly the point — it survives the next version, and the one after that.