Fire engineering has always relied on tools that sit somewhere between understanding and abstraction. We use equations, correlations, spreadsheets, zone models, CFD, evacuation models, structural fire models, and increasingly software platforms that stack several of these layers together. These tools let us explore fire scenarios, test design assumptions, compare strategies, and demonstrate performance in buildings too complex to reason about by hand. Used well they are powerful, and used poorly they are dangerous. The issue is never the tool itself; it is whether the engineer understands what the tool is doing, why it is doing it, and whether the result actually answers the question being asked. That is the black box problem. It is the same concern, seen from the modelling side, that runs through our wider view of AI in fire engineering.

Fire engineering already has black boxes

It is tempting to talk about artificial intelligence as though it introduces an entirely new risk. In some ways it does, because AI can generate plausible outputs with remarkable confidence, obscure uncertainty behind fluent language, and produce code, explanations, and recommendations that read as authoritative even when they are wrong. But the black box problem did not begin with AI. Fire engineers have been using tools they do not fully understand for a long time.

This is not a criticism of individual engineers; it is a reality of modern practice. Many tools are complex, some are proprietary, and some demand specialist knowledge to interrogate properly. Others are built on assumptions that are difficult to see, or are used under commercial pressure without enough time for sensitivity studies, benchmarking, or careful review.

CFD is the obvious example. Computational fluid dynamics can give extraordinary insight into smoke movement, tenability, fire development, and the interaction between geometry and fire, reaching scenarios that simple hand calculations cannot touch. But CFD is not a window onto reality. It is a numerical representation of selected physical processes, governed by modelling choices, and the choices all matter: mesh resolution, boundary conditions, the definition of the design fire, turbulence and combustion treatment, radiation modelling, material properties, vents, leakage, and how the output is read. A CFD model can be beautifully visualised and still be wrong for the question in front of it.

The same applies to evacuation and human behaviour modelling, used to estimate movement times, find congestion, and compare management strategies. These can be valuable, particularly in complex buildings, but people are not particles. Human behaviour in fire is shaped by perception, familiarity, social influence, mobility, information, management action, pre-movement behaviour, and the specific population in the specific building, and any model that represents it necessarily simplifies. As with CFD, the question is not whether these tools should be used. They should. The question is whether they are used with enough understanding of their assumptions, limitations, and relevance to the design at hand.

AI may make the black box problem worse

The integration of AI and machine learning into fire modelling is already underway. Researchers are using machine learning to accelerate CFD-based fire modelling, predict smoke movement, estimate tenability, support performance-based design, and represent aspects of human behaviour. Some train models on large sets of CFD simulations; others explore neural networks, surrogate models, or physics-informed approaches that cut computational cost while trying to preserve predictive value.

This work is genuinely important. If a model that normally takes hours or days can be approximated in seconds, an engineer can explore far more scenarios, test assumptions more thoroughly, and get a much better feel for how sensitive a design really is. That is valuable. But it also adds a layer of abstraction. Instead of asking only whether the CFD model is appropriate, we now have to ask whether the AI model trained on CFD outputs is appropriate, which means understanding its training data, its domain of applicability, its generalisation limits, its validation, and what happens when it is pushed beyond the conditions it learned from.

That last point is where the danger concentrates. AI models can perform well inside the range of data they have seen and fail badly outside it. A surrogate trained on a particular family of geometries, fire sizes, and ventilation conditions may be meaningless when applied to a different design, yet the result will still look precise, the graph will still look convincing, and the interface will still feel professional. None of that demonstrates the answer is valid for the engineering question being asked. This is how AI makes the black box effect worse: it can place a black box on top of another black box while making the whole process look faster, cleaner, and easier to trust.

The problem is not complexity. The problem is unexamined complexity

Fire engineering will always involve complexity, because buildings, fires, people, design teams, and regulatory systems are all complex. The answer is not to avoid complex tools, which would be unrealistic and often irresponsible. The answer is to contextualise them. A model should not be judged on whether it is simple or sophisticated, but on whether it is appropriate, understood, and defensible for its intended purpose. A simple method can be misused, a complex model can be entirely appropriate, a prescriptive solution can fail when its assumptions are violated, and a performance-based analysis can be weak if it buries uncertainty under technical detail.

The central question is always the same: what engineering purpose does this analysis serve? Are we trying to understand a trend, test a sensitivity, demonstrate compliance with a criterion, compare design options, check whether a strategy is robust, or communicate risk to a client or approving authority? The model has to be judged against that purpose. This matters most of all for AI-assisted modelling, because the value of AI is not that it lets engineers stop thinking. Its value is that it can let them ask more questions, explore more alternatives, and interrogate assumptions more efficiently, and that only works while the engineer stays in control of the purpose, the assumptions, and the interpretation.

Transparency is not optional

If AI is to be used responsibly in fire engineering, transparency has to be built into the workflow. That does not mean every user must understand every line of code in every model. It means the user must have access to enough information to make a competent judgement: what method is being used, what assumptions are embedded in it, what input range is appropriate, what limitations are known, what validation supports it, what happens when key assumptions change, and where the method stops being useful.

These questions should not be hidden in manuals nobody reads, or reconstructed after a design has already been built around the result. They should be part of how the tool talks to the engineer, and this is where software design carries real weight. A tool that simply gives an answer encourages answer-seeking. A tool that exposes its assumptions encourages judgement, one that shows its limitations encourages appropriate use, one that allows sensitivity exploration encourages understanding, and one that links results to methods, tests, and documentation encourages defensible practice. That is the direction fire engineering software needs to move in.

Why OpenFire takes a different approach

OpenFire was created with this problem in mind. The aim is not to strip complexity out of fire engineering, but to make the use of methods more transparent, traceable, and open to interrogation. At its core OpenFire is built around open methods. Calculations are implemented in code that can be inspected, assumptions can be documented, limitations can be communicated, tests can be reviewed, and worked examples can show how a method is meant to be used. OpenFire Desktop builds on that foundation by turning those methods into an interface that supports exploration rather than concealing the engineering behind it.

The point of the tool is not simply to produce an answer. It is to help the engineer understand what sits behind that answer. If a method has limitations, those limitations are visible. If assumptions matter, the tool makes them easier to explore. If an input changes the result significantly, the engineer can see it happen. And if a calculation is being used outside its meaningful range, the user is prompted to think carefully rather than trust the number. That is the opposite of the black box effect. The ambition is not to make fire engineering automatic. It is to make it more inspectable.

You can see what this looks like across the open method library at the OpenFire method catalogue, where the assumptions, limitations, and valid input ranges sit alongside every calculation; it is open to browse without an account.

Defensibility is the key

In safety-critical engineering, the ultimate question is not whether a tool produced a result. It is whether the engineer can defend the reasoning. A defensible analysis is clear about purpose, method, assumptions, limitations, and interpretation; it lets another competent person follow what was done and why; and it makes uncertainty visible instead of pretending it is not there.

AI can support that process, but only if it is integrated carefully. It can help generate scripts, explore parameter ranges, summarise information, compare approaches, and communicate ideas, letting engineers work faster and consider more options. What it must not do is obscure responsibility, because the competent engineer remains the one who decides whether a method is appropriate, whether a model is meaningful, and whether the conclusion is justified.

This is why the future of AI in fire engineering should not be framed as a contest between human judgement and machine capability. The real opportunity is to build tools that strengthen judgement by making methods, assumptions, and limitations easier to interrogate. Fire engineering does not need more impressive black boxes. It needs better ways to open them.