When the Model Misleads

Begin with the most sobering fact in building simulation: buildings, once built and occupied, routinely use more energy and perform differently than their models predicted - often dramatically so. This is the performance gap, and it is not the exception but close to the rule. A building modelled to use a certain amount of energy may, in reality, use half as much again or more; a space predicted to stay comfortable may overheat; a design that looked efficient on the screen may disappoint in the field. If simulation were a reliable oracle, this would not happen at scale - and yet it does, everywhere, consistently.

The causes are instructive because they reveal what a model actually is. A simulation is a *simplified story* about a building: it assumes the walls are built exactly as drawn, the insulation is continuous and unbroken, the systems run as specified and are maintained perfectly, the weather matches the file, and the occupants behave according to a tidy schedule. Reality violates every one of these. Insulation has gaps and thermal bridges the model never saw; systems are installed imperfectly and drift out of tune; controls get overridden; the building is used at hours and intensities no one modelled; and people - the great unmodellable variable - open windows, prop doors, bring heaters, and generally behave like people rather than like inputs. Each divergence is small; together they open the gap.

The lesson is not that simulation is useless - it is genuinely valuable for comparing options, understanding behaviour and testing ideas. The lesson is about what kind of thing a result is. A simulated number is a *conditional* statement: this is how the building would perform IF every assumption held exactly - and in the real world none of them hold exactly. So the honest reading of any simulation output is not 'the building will use X' but 'under these assumptions, the building would use about X, and the real figure will differ, probably in the direction of worse'. Treating the model's number as a promise of real performance is a category error - and the performance gap is the world reminding us, building after building, that the map is not the territory.

The performance gap is partly about the world diverging from the model after the fact. But models also mislead from the start, through their inputs - and here the oldest rule in computing applies without mercy: garbage in, garbage out. A simulation is only as good as the assumptions and data fed into it, and a sophisticated engine will process bad inputs into a beautifully precise, completely wrong answer without a flicker of complaint. The software does not know its inputs are wrong; it simply computes.

The dangerous inputs are rarely the obvious ones. Some are guesses dressed as data: an occupancy schedule assumed rather than known, an infiltration rate taken from a default, a material property lifted from a library that does not match what will actually be built. Some are wrong scenarios: the right physics run against the wrong weather file, or a comfort model that does not suit the climate or the population. Some are structural - a model that omits a crucial effect entirely, like the urban heat island around an actual site, or the humidity that makes heat dangerous in India, or the thermal bridging that dominates a real wall. In every case the output inherits the flaw, but the flaw is invisible in the polished result: the chart is just as smooth, the number just as precise, whether the inputs were carefully verified or hastily guessed.

This is why the competent analyst spends more care on the inputs than on the run. Before trusting any result, you interrogate what went in: where did each key assumption come from, is it measured or guessed, does the weather file suit the site and the future in question, does the comfort model fit the people and the climate, and what has the model left out entirely? A model that omits the dominant physics of a situation is not approximately right - it can be confidently, precisely wrong. In the Indian context this bites hard: a comfort or overheating analysis that ignores humidity, or uses assumptions borrowed from a temperate climate, or a schedule assuming universal air-conditioning in a population that cannot afford it, will produce authoritative numbers that describe a building that does not exist. Garbage in, garbage out is not a slogan about carelessness; it is a standing reminder that a model's confidence is entirely independent of its correctness, and that checking the inputs is the analyst's real work.

There is a psychological failure that compounds the technical ones, and it is worth naming on its own: the more polished a model's output, the more we trust it - regardless of whether that trust is earned. A result delivered as a smooth colour-graded chart, a precise number, a professional report from expensive software, simply *looks* authoritative, and the look does the persuading. We are far more likely to challenge a rough hand-sketch estimate than a slick simulation printout, even when the sketch, made by someone who understands the building, is the more reliable of the two.

This false confidence is dangerous because it suppresses exactly the scrutiny a result most needs. A number that looks precise invites you to design to it precisely; a chart that looks scientific discourages the awkward question of whether the inputs were any good; a report that looks expensive feels rude to doubt. And the danger compounds down the chain: the analyst's tentative result becomes the designer's working assumption becomes the client's firm expectation becomes the marketing team's confident claim - the caveats and ranges stripped away at every handover until a hedged, conditional estimate arrives at the end as a hard fact. The polish that reassured everyone was, all along, just formatting.

The antidote is a deliberate inversion of instinct: treat polish as a reason for *more* scrutiny, not less. The smoother and more confident a result looks, the harder you should ask what it rests on - which is simply the discipline of remembering that presentation quality and accuracy are completely unrelated. A model is a tool for thinking, and the best practitioners hold their own models at arm's length, actively hunting for the ways they might be wrong rather than admiring how right they look. This is not anti-technology cynicism - simulation is powerful and this course champions it - but it is a hard-won humility. False confidence is how good tools produce bad decisions, and the only defence is to keep a sceptical human, and where the stakes are real an expert one, standing between the polished output and the decision it is about to drive.

All of this converges on a single practical skill: knowing when to distrust a model's result, and never letting the model replace the humans who should judge it. Distrust is not a mood; it is a set of checks you run on every result before you let it drive a decision.

First, sanity-check against reality. Does the number make physical sense - is it in the right ballpark for a building like this, in a climate like this? A result that is wildly better or worse than comparable real buildings is a red flag, not a discovery; the burden is on the surprising result to prove itself, not on you to accept it. Where you can, calibrate against measured data from real, similar buildings - a model tuned to reality is far more trustworthy than one run blind. Second, interrogate the inputs and the omissions, as the previous section demands: a result is only as good as what went in and what was left out. Third, test the result's sensitivity: change the shaky assumptions and see how far the answer moves - if it swings wildly, the result is fragile and should be trusted less. Fourth, distrust more when the stakes are higher: a rough comparison of two options can tolerate a loose model, but a result that will drive a life-safety decision - will this building keep people alive in a heatwave with the power off? - demands validation, expert review and conservative margins.

Underneath every check is one principle: keep human and expert judgement in the loop. A model informs judgement; it does not replace it. The experienced building-physics engineer who looks at a result and says 'that overheating figure is too low for a west-facing glass box in this city - something is wrong with the inputs' is doing something no software can: bringing knowledge of how real buildings actually behave to bear on a number that looks fine on its own. That is why this course defers every binding result - the building-physics, energy, thermal-comfort, structural and climate-risk engineering, and any compliance or life-safety determination - to qualified engineers, verified data, validated and calibrated tools, and the governing codes (NBC India, ECBC, IS). The model is where thinking starts, never where it stops. Trust it least exactly when it looks most trustworthy, and keep a knowledgeable human between its polished output and the people whose safety depends on the decision.