Fire & Life Safety

Fire egress - the means by which occupants escape - is written in most codes as a chain of quantitative rules, which is precisely why it automates well. The chain begins with occupancy load: the code assigns each use an occupant-load factor (so many square metres per person for an office, fewer for an assembly hall, and so on), and the load of a space is its area divided by that factor. That single derived number drives almost everything downstream, and computing it from a model that knows each room's area and use is straightforward and consistent - far more reliable than a human totting up loads by hand across a large building.

From the load the code sizes the escape provision, again numerically. Required exit width is the load multiplied by a width-per-occupant figure; a minimum number of separate exits is required once the load or the travel distance crosses thresholds; stairs and corridors that serve the escape must meet minimum clear widths and provide capacity for the load they carry. These are direct calculations and comparisons - required versus provided - that a checking engine performs precisely. Then the spatial egress rules: the travel distance from the most remote point in a space to the nearest exit must not exceed a maximum; two exits must be a minimum distance or angle apart so a single fire cannot block both; dead-end corridors (from which you can escape in only one direction) must be short enough; refuge areas and the like must be provided where required.

Travel distance is the most illustrative case. By hand it is tedious and error-prone - you must trace the actual walking path around furniture and walls to the nearest usable exit, for many points, and re-do it every time the plan changes. For a checking engine working on a structured model that knows the geometry and where the exits are, this is a path-finding computation it can run instantly and repeat on every design revision. That is a genuine, substantial win: egress is a body of rules that is both safety-critical and highly mechanical, so automating the mechanical part catches real, common failures - an over-long travel distance, an under-sized exit, too few exits for the load - early and consistently, while the plan is still cheap to change. Fire egress is, alongside accessibility, one of the clearest cases where model-based checking does exactly what it promises.

Follow an egress check and its dependence on good data becomes clear. To compute occupancy load the engine needs every space to carry both an area and a correctly classified use, because the occupant-load factor is chosen by use - misclassify an assembly space as an office and the computed load, and everything derived from it, is wrong. To size required egress it applies the encoded width-per-person and minimum-exit rules to that load. To check travel distance it needs the model to know the geometry of the escape route and which openings are actually exits - a door tagged as an exit, a stair that discharges to a place of safety - and it traces the path from each remote point to the nearest such exit, comparing the length to the encoded maximum. To check exit separation it measures the distance or angle between exits. Each of these is a defined computation, which is why the results are consistent - but each also depends on the model being classified and complete.

This makes egress checking powerful and, like accessibility, honestly three-valued. Where the data is present and clean, pass and fail are confident: this exit is wide enough, this travel distance is too long. Where the data is missing or ambiguous, the correct output is could-not-determine: the space had no use assigned, so no load could be computed; the exits were not tagged, so no travel distance could be traced; the stair discharge was not modelled, so the route could not be completed. A mature egress checker surfaces those gaps rather than silently passing them - all the more important because egress is safety-critical, and a silent gap here is not a cosmetic risk but a life-safety one.

It is also worth being clear about what the check is measuring versus what actually matters in a fire. The check measures compliance with prescriptive egress geometry - distances, widths, counts - which the code sets as a proxy for the real goal: everyone escaping before conditions become untenable. That proxy is well founded and the rules encode hard-won experience, but it is still a proxy. Whether people actually escape in a real fire depends on smoke, alarm, behaviour, management and maintenance that the geometry check never sees. So even a clean egress pass verifies that the escape geometry meets the code's prescriptive requirements in the data given - a genuine and useful thing - not that the building is safe. Reading the could-not-determine list and remembering the gap between the proxy and the goal are both part of using the check honestly.

Now the boundary, which is sharper in fire than in almost any other domain. The numeric egress rules a checker tests are the visible surface of a fire-safety strategy, and the strategy itself is expert engineering that no geometry check touches. The strategy asks how the building resists fire (fire-resistance ratings of structure and compartment walls, so the building stands and the fire is contained long enough), how it limits spread (compartmentation, fire-stopping, separation), how it manages smoke (which kills more often than flame), how detection and alarm and suppression work together, and how all of this coordinates with the escape provision so that people can actually get out while conditions stay survivable. Some pieces of this are themselves checkable - a fire-resistance rating required for an element, a compartment size limit, a required separation - and a checker can test those numbers usefully. But the coherence of the strategy as a whole, the reasoning that ties the pieces into a building that is genuinely safe in a fire, is engineering judgement, not a set of independent numeric checks.

And there is a whole mode of fire design that lies entirely outside prescriptive checking: performance-based fire engineering. Instead of following the prescriptive rules, a fire engineer may demonstrate by analysis - fire and smoke modelling, tenability calculations, evacuation simulation - that an alternative design achieves the required level of safety, often to justify a departure the prescriptive rules would forbid (an atrium, an extended travel distance, an unusual geometry). This is exactly the performance-based approach the course flagged from the start: the rule is effectively 'achieve this level of safety', and demonstrating it needs modelling and expert judgement, not a width comparison. An automated egress checker cannot evaluate a performance-based case at all; at best it can note that the design does not meet the prescriptive rule and therefore requires such an engineered justification - which a qualified fire engineer must produce and the fire authority must accept.

So fire is the domain where the honest boundary bites hardest, and the reason is the stakes. Automated egress checking is genuinely valuable for catching prescriptive egress failures early - and genuinely partial, because the fire strategy and any performance-based engineering are expert work it does not do. Above all: a check that finds no egress problem is never a fire-safety sign-off. It has tested a slice of the prescriptive rules against the model data; it has not judged the fire strategy, evaluated any performance case, or certified that people will get out alive. Fire-safety compliance and sign-off belong to the qualified fire-safety professional, the fire authority and the governing code - never to a passed check.

In India, fire and life safety is governed principally by Part 4 (Fire and Life Safety) of the National Building Code, together with state fire-service rules and local byelaws, and it is one of the most consequential and most enforced areas of building regulation - fire clearances are a serious gate, especially for high-rise, assembly and institutional buildings. The quantitative core of Part 4 - occupancy loads and load factors, exit widths, number of exits, travel distances, corridor and stair widths, compartment and refuge-area provisions - is exactly the checkable kind, so as submissions become more structured, automated egress checking has clear value for self-checking a design against these parameters before it goes to the fire authority. That is a real and useful application, particularly given how often fire-related shortfalls cause costly late redesigns or rejections.

The usual two boundaries apply with extra force because lives are at stake. Garbage in, garbage out: an egress check is only as good as the model, and where submissions are still 2D drawings without classified spaces or tagged exits - common in India - a rich automated egress check simply cannot run. And a check is never a sign-off, least of all here: the fire authority grants fire clearance, the encoded rules may be wrong or out of date, the model may be incomplete, the fire strategy and any performance case are untouched by the geometry check, and over-trusting a green tick in a life-safety domain is exactly the automation bias that can get people killed.

So use automated egress checking as a disciplined early-warning and self-check tool - valuable precisely because fire failures are common, costly and dangerous to catch late - but hold the boundary without compromise. The binding requirements are the actual code and rules: Part 4 of the National Building Code, the state fire-service regulations and local byelaws, and the relevant IS standards - never their encoded version. Whether a design actually satisfies fire and life safety, how any ambiguous or performance-based provision is judged, and legal responsibility for fire safety all stay with the qualified fire-safety professional of record and the fire authority. A passed egress check is a useful signal that the prescriptive egress geometry looks right in the model - and nothing more. It is never a certificate that the building is safe in a fire.