When Judgment Is Required

A workable go/no-go starts with two questions asked of every rule in front of you. Is the rule clear and quantitative - does its text nearly equal its meaning, so that satisfying it is a matter of comparing a number in the model to a number in the rule? And is the data it needs actually present and correctly classified in the model? Only when both answers are yes can the rule be run and its result trusted as an early flag - and even then a human reviews, because a pass means only that the encoded rule found no flaggable issue in the data given. If the rule is not clear and quantitative, or the data is absent, the tool's output is not a compliance result at all, and the decision belongs to a human.

This framing matters because it replaces a vague slogan with a repeatable test, and because it is honest about a third outcome that immature tooling hides. A good checker returns not two states but three: pass, fail, and cannot-determine. The cannot-determine bucket is where the go/no-go lives - it holds every rule that is too open to encode, every rule whose data is missing, every situation the encoding did not anticipate. A tool that collapses this bucket into a silent pass is dangerous precisely because it disguises a no-go as a go. The competent user treats cannot-determine as the most informative output of all: it is the tool correctly saying 'a human must decide this', which is exactly what you want it to say.

The rest of this lesson populates the no-go side with the five situations that keep recurring. Notice the through-line: in each, the failure mode of forcing code is not that the tool refuses to answer but that it answers confidently and wrongly, because the situation contains something - analysis, novelty, conflict, an unforeseen fact, a purpose - that lives outside what the encoding can see. The instrument you are building is the discipline to recognise those situations early, before a green tick lulls you, and to route them to the accountable human rather than to the checker. Automation earns its keep on the go side; judgement protects you on the no-go side; and knowing which side you are on is the whole skill.

The first two no-go situations are where a rule demands reasoning the checker cannot do, or a design the encoding never anticipated.

Performance rules state an outcome to be achieved rather than a dimension to be met: 'the structure shall safely resist the design loads', 'the means of escape shall allow occupants to reach safety in the available time', 'the building shall limit fire spread'. Whether such a rule is satisfied is not a width you can read off a model; it is the conclusion of an analysis - a structural calculation, a fire-engineering study, an egress simulation - carried out and signed by a qualified professional who takes responsibility for the assumptions and the method. A checker can confirm prerequisites (that a member exists, that an exit is present) but it cannot perform or vouch for the analysis that decides compliance, and treating a prerequisite check as if it settled the performance rule is a serious category error. Performance requirements are, by design, delegated to expert judgement; that is what 'performance-based' means.

Novel designs are the second trigger. Encoded rules embed assumptions about ordinary buildings - typical geometries, familiar materials, the cases the rule-writer had in mind. A genuinely new configuration - an unusual section, a material used in a way the rule did not foresee, a hybrid occupancy, a form that the model's classifications do not cleanly fit - falls outside those assumptions. The checker may run and return a result, but the result is unreliable, because the rule (and its encoding) was never calibrated for this case; the honest answer is that a human must decide whether and how the rule even applies. Novelty is exactly where design advances and exactly where automated checking is least trustworthy, which is a tension worth naming: the more original the work, the more the tool's confident output should be distrusted. In both situations the discipline is the same - recognise that the decision requires analysis or fresh judgement the encoding cannot supply, route it to the qualified professional and, where the design is genuinely new, expect to engage the approving authority directly rather than lean on a checker. The tool can inform the conversation; it cannot be the conclusion.

The remaining three triggers are where rules collide, run out, or say less than they mean.

Conflicting rules are routine on real projects. A fire requirement wants a door to swing outward while a security or accessibility requirement wants something else; two byelaws overlap; a general provision and a more specific one both apply; the demands of egress and of energy pull in opposite directions. Resolving a conflict is not a lookup - it requires understanding the intent behind each rule and finding a design that honours both, or deciding, with reasons, which governs. That is interpretation of exactly the kind expert bodies and authorities perform, and no checker does it: a tool can flag that two rules are both triggered, which is genuinely useful, but the reconciliation is a human decision that someone must stand behind. Edge cases are the second: situations at the boundary of a rule's intended scope, or combinations the rule-writer never imagined, where the encoded logic produces an answer that is technically derived but practically wrong because the case sits outside what the rule was written for. A checker cannot tell that it has left the territory the rule was meant for; a human can.

Spirit versus letter is the subtlest and most important. Every rule exists for a purpose - a safety, an amenity, an equity the words are trying to secure. Usually meeting the words serves the purpose. But designs can meet the letter while defeating the spirit (a technically-compliant exit route that no one in a panic would actually find and use) or, occasionally, miss the letter while fully serving the intent (a solution the rule did not anticipate that achieves the same safety by other means). Recognising these cases requires understanding what the rule is for - something the encoding, which only has the letter, cannot access. This is why forcing everything into code produces false precision: the tool confidently reports on the letter and is silent on the spirit, and a user who trusts the tick mistakes letter-compliance for real compliance. The mature response is to treat the checker's letter-level pass as necessary but not sufficient, and to ask, for anything that matters, whether the purpose is actually met - a question that, on the rules that carry real safety or fairness, only an accountable human should answer, in coordination with the authority and the governing code.

There is a real pull, once you have a checker, to route everything through it - to convert every rule into a number, every judgement into a threshold, every open term into a proxy, so that the whole of compliance becomes a dashboard of green ticks. The pull is understandable: ticks are legible, comforting and easy to show a client or a boss, while 'a human must judge this' is uncomfortable and looks like the tool failing. But giving in to that pull is precisely how automated compliance causes harm, because it manufactures false precision - a confident, plausible, checkable-looking answer to a question that was never checkable, replacing an honest 'this needs judgement' with a dishonest 'this passed'.

Resisting the temptation is a discipline with a few concrete moves. Keep the cannot-determine bucket alive and visible, and treat it as valuable output rather than a failure of the tool - a checker that honestly says 'I cannot decide this' is doing its job. When someone proposes encoding an open or performance rule via a proxy, ask what the proxy silently assumes and where it would be wrong, and label the check as 'proxy for' rather than 'compliance with'. Watch for the five triggers - performance, novelty, conflict, edge case, spirit-versus-letter - as signals to stop and hand the decision to a human. And frame the tool, to yourself and to clients, as an early-warning assistant for the checkable subset, never as a compliance verdict, so that its silence on the judgement rules is never mistaken for their satisfaction.

Behind all of it stands the accountability that does not move. The point of the go/no-go is not tidy classification for its own sake; it is to keep binding decisions with the people the law actually holds responsible. An automated check is not a legal determination of compliance and never an approval; the authoritative rule is always the actual code, byelaw or law - the National Building Code of India, the local building byelaws and development-control regulations, the relevant IS standards - never its encoded version. Whether a design actually complies, how any regulation is interpreted, and legal responsibility all rest with the qualified professional of record, the approving authority and the governing law. Force nothing into code that needs a human; use the tool wholeheartedly for what it is genuinely good at; and keep the judgement, and the accountability, human.