Prescriptive vs Performance

A prescriptive rule specifies the solution directly. It does not ask you to reason about outcomes; it hands you a requirement and says: meet it. "The clear width of a corridor shall be not less than 2.0 m." "Provide at least two exits from this occupancy." "A ramp shall have a slope no steeper than 1 in 12." "The setback from the front boundary shall be at least 3 m." Each names an element, a measurable property and a threshold. There is nothing to interpret about the *goal*; the drafter already did that reasoning, decided a corridor of 2.0 m is wide enough for the crowds an assembly building holds, and froze the conclusion into a number.

This is precisely why prescriptive rules are the natural home of automated compliance. A rule of the form "for every element of this kind, this measured property must satisfy this threshold" is directly runnable against a structured model: find the corridors, read their clear widths, compare to 2.0 m, flag the failures. The check is fast, it is consistent (the same rule gives the same verdict every time, removing the disagreement two human examiners might have), and it can run early and often while the design is still cheap to change. When a vendor demonstrates automated code checking catching an under-width corridor or an over-long travel distance, they are almost always showing prescriptive rules - and the demonstration is honest, because for this class of rule the technology genuinely delivers.

The strengths of prescriptive rules are certainty and checkability. A designer knows exactly what is required; an examiner knows exactly what to verify; a machine knows exactly what to test. But those strengths come from their defining move - freezing one solution - and that is also their weakness, which the next section examines. For now, hold the key fact for automation: prescriptive rules are the checkable subset. The setbacks, coverage, FSI and height limits that dominate Indian plan-scrutiny are overwhelmingly prescriptive, which is exactly why automated plan-scrutiny has advanced furthest there. When someone claims automated compliance "works", they are, correctly, describing the prescriptive part of the code - and the skill is recognising how much of any given regulation actually is prescriptive, and how much only looks it until you read the exceptions and definitions that surround the tidy number.

A performance rule (also called performance-based, outcome-based or, in some systems, objective-based) does the opposite: it states the *goal* the building must achieve and leaves the *means* to the designer. "The structure shall safely resist the design loads." "The building shall be provided with adequate means of escape such that occupants can reach a place of safety." "The building shall limit the spread of fire." "Thermal performance shall be sufficient to maintain reasonable comfort with reasonable energy use." These rules do not tell you the corridor is 2.0 m; they tell you people must be able to get out safely, and invite any solution that demonstrably achieves it.

The appeal is flexibility and rationality. A performance rule accommodates designs the drafter never imagined - an unusual geometry, a new material, an innovative fire strategy - as long as they meet the goal. It ties the requirement to what actually matters (safe escape, structural adequacy) rather than to a proxy that may not fit every case. This is why modern codes increasingly offer performance routes, and why demanding or novel projects often use them. But the cost is exactly what makes performance rules resistant to automation: demonstrating that an outcome is achieved requires *analysis and judgement*, not a measurement. Proving a structure "safely resists the design loads" means structural engineering calculation. Proving occupants can "reach a place of safety before conditions become untenable" may mean fire and evacuation modelling, assumptions about occupant behaviour, and an assessment of tenability. There is no single number in the model to compare against; there is a question about whether the design, analysed properly, achieves the goal under the scenarios that matter.

So an automated checker generally *cannot* pronounce on a performance rule. At most it can check inputs or bookkeeping around the edges - that an analysis was submitted, that assumed parameters fall in expected ranges - but the substantive judgement (is this fire strategy sound? is this structural design adequate?) belongs to a qualified engineer and, ultimately, to the approving authority. This is not a temporary limitation waiting for better software; it is intrinsic. Performance compliance is a demonstration and a judgement, and demonstrations and judgements are human work. When automated-compliance marketing glosses over this, it is quietly conflating the prescriptive rules it can check with the performance rules it cannot - the single most common way the field is over-promised.

Neither kind of rule is simply better; each buys something and pays for it, and mature codes use both on purpose. Prescriptive rules buy certainty and checkability and pay with rigidity. Because they freeze one solution, everyone knows exactly what is required and a machine can verify it - but that same fixity can be a poor fit. A prescriptive rule may be over-conservative for a simple case (demanding more than the goal really needs) or, worse, inadequate for an unusual one the drafter did not foresee, and it can obstruct a perfectly safe innovative design simply because the design is not the one the number assumed. Performance rules buy flexibility and rational fit and pay with cost, uncertainty and judgement. They let any solution that achieves the goal through, and tie compliance to what truly matters - but demonstrating the outcome takes analysis, expertise and time, the result can be contested, and it depends heavily on the competence and honesty of whoever does the demonstration and whoever reviews it.

Because of this, real building codes are typically *hybrid*. A very common and important pattern is the deemed-to-satisfy provision: the code states a performance objective, then offers a prescriptive recipe that is *deemed* to satisfy it. Follow the recipe (the 2.0 m corridor, the two exits) and you comply without having to prove the outcome from first principles; or, if your design does not fit the recipe, take the performance route and *demonstrate* that you meet the objective another way. This gives designers a fast, certain, checkable default and an escape hatch for the unusual case - and it maps directly onto automation. The deemed-to-satisfy prescriptive path is exactly what automated checking can verify; the performance alternative is exactly what it cannot, and must defer to engineering analysis and the authority.

For automated compliance the practical reading is clear. Expect a code to contain both kinds of rule, often side by side for the same goal. Recognise that the tool can meaningfully check the prescriptive and deemed-to-satisfy provisions and cannot settle the performance ones. And never let a green tick on the prescriptive path be read as compliance with a performance objective the tool never evaluated - the design might follow a performance route the checker cannot see, or might satisfy the recipe on paper while failing the real outcome. Knowing which route a design is taking, and which the tool actually assessed, is part of reading any automated result honestly.

In practice, prescriptive and performance are not two boxes but the ends of a *spectrum*, and most rules sit somewhere along it. At the purely prescriptive end is a bare number: "2.0 m". Move a little toward performance and you get a rule that is still quantitative but conditional: "the width shall be sufficient for the occupant load, determined from the following table" - checkable, but only once you compute the occupant load and look up the table, so more of the work is required before the number appears. Move further and you reach a rule that references a calculated quantity: "the aggregate exit width shall be not less than the value required by the egress calculation" - now the threshold itself is the output of an analysis, so checking it means either trusting or redoing that analysis. At the far end sits pure outcome language: "adequate means of escape", "safely resist the loads" - no number at all, only a goal. As you travel from the prescriptive end to the performance end, *checkability falls*: the rule needs progressively more analysis, more judgement and more information beyond the model before it can be evaluated, until at the far end it cannot be automatically evaluated at all.

This spectrum gives you a practical diagnostic. Take any rule and ask: how far along is it? Is the requirement a fixed number I can measure directly (near the prescriptive end - checkable), a number I must first compute from other model data (mid-spectrum - checkable with more work and more data), a threshold that is itself the output of an engineering analysis (far along - the analysis is the real work, not the comparison), or a pure outcome with no number at all (the performance end - not automatable)? Where the rule sits predicts, better than its topic or even its domain, how much of it a machine could ever check.

Carry three things forward. First, prescriptive rules are the engine room of automated compliance - real, valuable, honest, and the majority of what any credible tool actually verifies. Second, performance rules are not a gap to be closed by better software; they are an intrinsic home of engineering analysis and human judgement, and pretending a checker settles them is the field's signature over-promise. Third, because codes are hybrid and rules sit on a spectrum, reading *where a rule falls* is a core compliance-literacy skill - and the binding verdict on any rule, prescriptive or performance, is always the actual code as applied by the qualified professional and the approving authority, never the tool's tidy tick on the part it happened to be able to test.