The Checking Tools

The software in this space sorts, loosely, into three families - loosely because real products blur the lines, but the sorting clarifies what each is for. The first is model-checking platforms: tools that load a structured model, let you select or import rule sets, run them against the model, and produce a report of pass, fail and cannot-determine results, usually with the ability to visualise flagged elements. These are the tools a designer or consultant runs to check a design against a body of rules - the engine of Module 4 made concrete. What matters about them is which model formats they accept (open exchange formats matter for interoperability), which rules they ship or let you add, and how clearly they present results.

The second family is rule-authoring environments: tools where the encoded rules themselves are written, tested and maintained. Because a checking platform is only as good as the rules it runs, someone must translate a regulation into machine-readable logic - the work of Module 3 - and rule-authoring environments are where that happens, whether through structured rule languages, decision tables, or visual rule builders. Some model-checking platforms bundle an authoring environment; some rules are authored centrally and distributed. For most designers this family is behind the scenes, but knowing it exists explains where the rules a platform runs come from, and why their quality and currency depend on human authors and a maintenance process.

The third family is authority and permit systems: the software regulators and local bodies use to receive submissions and run scrutiny from their side. This includes online single-window building-permission portals, e-permitting systems, and automated or semi-automated plan-scrutiny tools that check submitted drawings or models against development-control parameters - setbacks, coverage, floor-space index, height. In India this is the family with the most visible public momentum, as cities and states digitise approvals. These systems matter because they are where an automated check can carry real regulatory weight - and precisely there, the honest boundaries bite hardest: an automated pre-scrutiny is a filter and an aid, not the grant of approval, which the authority makes.

The three families interlock: authors write rules in the second, designers and authorities run them via the first and third. No single product is purely one family, and the landscape shifts constantly - which is exactly why the categories, and the questions in the next section, matter more than any name.

Because products move fast, judge a tool by durable questions rather than features or brand. Six questions cut to what actually matters, and they work on any tool in any of the three families, this year or next.

Which rules does it run? The single most important question. A tool is only as useful as the rules it can actually evaluate, and - from the previous lesson - only the codeable, quantitative rules are ever in scope. Ask which rule sets it ships, whether they match the code, byelaw or standard you must satisfy, and how much of your relevant rulebook it genuinely covers versus leaves to you.

On which model formats? A tool that reads only its own proprietary format locks you in and may not fit your workflow; one that reads open exchange formats interoperates. Ask what it ingests and how faithfully, because a lossy import silently degrades the data the checks depend on.

How transparent is it? Can you see *why* a rule passed or failed - which element, which property, which threshold - or does it hand you a bare verdict? A tool that shows its reasoning lets you verify it; a black box asks for trust it has not earned. Transparency includes reporting matched-element counts and cannot-determine cases honestly rather than hiding them as silent passes.

How current are its rules, and who maintains them? An encoded rule can drift out of date as the real code, byelaw or standard changes. Ask when the rule set was last updated, against which version of the regulation, and who is responsible for keeping it current - because the authoritative rule is always the actual law, never the tool's possibly-stale copy of it.

How does it handle what it cannot check? A trustworthy tool is explicit about its limits - it surfaces cannot-determines and does not pretend to have covered the uncheckable rules. A tool that implies a clean run means full compliance is misrepresenting itself.

Who is accountable for the result? No tool, however good, is the professional of record or the approving authority. Ask what the vendor claims - and be wary of any product whose marketing suggests it certifies, approves or guarantees compliance, because none of them do. These six questions, not a brand name, tell you whether a checking tool deserves your trust and where its help stops.

One fact survives every change in the tooling landscape: the report lands on a human, and a human accountable for the design decides what it means. A checking tool - platform, authoring environment or permit system - does something genuinely valuable: it narrows a vast rulebook to a short, structured list of flags and unresolved questions, fast and consistently, for the checkable rules. But narrowing is not deciding. Someone still has to read the report critically, and that someone is not the software.

Reading it critically means applying everything the module has built. Check the matched-element counts, so a rule that tested nothing is not mistaken for a pass. Read the cannot-determine list as carefully as the failures, because both are open questions - the fails to fix or justify, the cannot-determines to resolve with better data or human judgement. Remember the checkability boundary, so a clean run across the codeable rules is never read as compliance with the whole code. And treat every verdict as a statement about the model and the encoded rules, not about the building or the law. The tool's output is the start of the professional's work, not a substitute for it.

This is also the honest answer to the hope that better tools will eventually remove the human. They will not, because the human is not there only to run the software - they are there to exercise the judgement the software cannot: to interpret, to assess performance, to decide which rule applies, to weigh the uncheckable, and to take responsibility. A more capable tool changes how much mechanical work the human is spared; it does not change who is accountable. That accountability is not a formality; it is the reason automated checking is safe to use at all. The moment a green tick is treated as the decision rather than an input to it, automation bias has replaced judgement, and the tool has become a hazard instead of a help.

So hold the whole module's discipline in one stance. Use checking tools for what they genuinely offer - fast, consistent, early evaluation of the checkable rules, and an honest list of what could not be checked. Judge any tool by the durable questions, not its brand or its marketing. Never let a clean run stand in for compliance. And keep the human reading the report and carrying the responsibility - because the qualified professional of record, the approving authority and the governing law, not the software, remain accountable for whether a design truly complies. Any tool named anywhere in this field is illustrative and fast-moving, never a specification or an endorsement.

The tooling will keep changing, so the right thing to walk away with is a posture, not a product list. Three commitments make that posture concrete and keep you steady no matter what appears next.

First, think in categories and questions, not brands. When a new tool crosses your desk, place it in a family - is it a platform, an authoring environment, a permit system, or a blend? - and run the six durable questions: which rules, which formats, how transparent, how current, how it handles the uncheckable, and who is accountable. This works identically for a product launched this year and one launched in five, and it protects you from marketing that leads with capability and hides limits.

Second, match the tool to the checkable subset, and only that. From the previous lesson, automation earns its place on the geometric and quantitative rules with present data. A tool's job is to run those well and to be honest about everything else. Judge it by how much of your genuinely-checkable rulebook it covers and how clearly it flags what it could not check - not by claims to handle compliance whole, which no tool can honour.

Third, keep the accountability where it belongs. The tool augments; it never replaces. The professional of record stands behind the design, the approving authority grants approval, and the governing law - the National Building Code, the local byelaw and development-control regulations, the IS standards - is the authoritative rule that the tool's encoded version only approximates. When encoding and law disagree, the law wins and a human must catch it.

Held together, these commitments let you use a fast-moving field without being captured by it. You can adopt a genuinely useful tool the week it appears, judge it soundly, get real speed and consistency on the checkable rules, and never once mistake its output for a legal determination. That is the whole module in a working posture: model-based checking runs encoded rules on a structured model through a definite pipeline; only the codeable rules are in scope; the report is a to-do list of flags and open questions; and the accountable human, the authority and the law decide what compliance means. The tools are illustrative and fast-moving; the discipline is what lasts.