Classification & Standards

Return to the literal-reader picture and make it precise. A rule references two things about the world: a class of element (corridors, doors, stairs, plots) and one or more properties of that class (clear width, clear opening, occupancy, area). To run, the rule must locate elements of that class in the model and read those properties by name. Every step of that depends on both sides agreeing on the words. If the rule looks for class Corridor and the model stored the same physical thing as class Space, or CirculationArea, or an untyped element, the rule's selection returns nothing relevant and the corridor is never tested. If the rule reads property clear_width and the model called it width, or corridorWidth, or stored it only as raw geometry, the rule finds no value to compare. The design might be perfect; the check is defeated purely by mismatched vocabulary.

This is a different failure from the data-quality faults of the last lesson, and worth separating. There, a single model had internally wrong data - a missing value, a wrong unit. Here, the model can be internally fine, but it does not line up with the vocabulary the rule expects, so the two cannot be compared. Both break checking; this one is fixed not by better data entry but by agreeing, in advance and in common, what things are called - which is exactly what a standard is.

Think of it as translation. When a rule and a model are authored by different people, in different tools, at different times, they will only meet if they both refer to the same external reference - a shared taxonomy of classes, a shared dictionary of property names and units. That shared reference is the standard. With it, 'Corridor' in the rule and 'Corridor' in the model denote the same class, and clear_width means the same measured quantity in the same unit on both sides, so the comparison is meaningful. Without it, every rule-model pairing needs its own bespoke, brittle mapping, which does not scale and quietly loses meaning.

So the deep reason standards matter is not tidiness; it is that checking is fundamentally a comparison between two separately-authored artefacts, and a comparison is only valid if both sides use the same terms. Shared standards are the common ground that makes the comparison possible - the backbone, as this lesson's title has it, on which rules and models can actually be run against each other. Everything else in automated checking assumes that backbone is in place.

The shared vocabulary is not one thing but a small stack of complementary standards, and it helps to separate them because they answer different questions.

First, a classification system answers 'what is this element?'. It is a shared taxonomy that gives every kind of building thing - a corridor, a fire door, an office, an external wall, a plot - an agreed name and often a code, so the same class means the same thing across projects, tools and parties. Well-known examples in the industry include tables like Uniclass and OmniClass, and the object classes defined within IFC itself; these are illustrative and evolving, not a specification. The point is that a rule selects elements by class, so a shared classification is what lets 'find every corridor' work reliably rather than depending on whatever a modeller happened to name a layer.

Second, a naming and property standard answers 'what does this element know, and in what terms?'. It fixes the agreed property names, their data types and, critically, their units: clearwidth is a length in metres, firerating is a duration in minutes, occupancy is a count. Standardised property sets - agreed bundles of properties attached to a class - are the common mechanism. This is the layer that prevents the unit-mismatch and missing-property faults from the last lesson at the level of the whole industry rather than one model: if everyone agrees clear_width is metres, a rule written against that standard reads every conforming model correctly.

Third, an open exchange schema answers 'how does this data travel between parties?'. Because checking is a hand-off between authoring tool, checking engine and reviewer, the classified, property-bearing data must move between them without being locked to one vendor - the role of IFC and the broader openBIM idea, developed in the next section.

The practical upshot is that a checkable model is one authored against agreed classification and property standards, so that the elements are named and coded consistently and their properties carry standard names and units. This is unglamorous but decisive work, and it is where a great deal of real-world automated-checking success or failure is actually determined. It is also why structured-modelling practice invests in agreed naming conventions and property templates up front: they are the substrate that makes any downstream checking - by any engine, for any rule - possible at all. And they never change the boundary that the authoritative rule is the actual code and byelaw, never the standard or its encoding.

Standards matter most because automated checking is never a single-tool, single-party affair - it is a chain of hand-offs, and every hand-off is a place where meaning can be lost. The design is authored in one tool, perhaps coordinated across several disciplines each in their own software; the checking may run in a separate engine; the result is reviewed by a designer and, ultimately, submitted to an authority. For a corridor's classification and clear_width to survive that whole journey intact, the data must be exchangeable in a form every link can read the same way. That property - the ability of independent systems to exchange data and use it correctly - is interoperability, and open standards are how it is achieved.

Contrast the two worlds. Without a shared standard, every pair of tools needs its own translation, and each translation is brittle and lossy; meaning leaks at every step, and the arrangement does not scale as more parties join. With an open standard, each tool speaks one common language, and everyone downstream reads the same data - the classic value of an open, vendor-neutral format. In building, this is the role of IFC as an open exchange schema and of openBIM as the principle of exchanging models in open standards rather than proprietary silos. The reason this is called the backbone of checking is literal: without shared, open standards, the rule and the model authored by different parties cannot reliably be brought together at all, so no amount of algorithmic cleverness in the engine helps.

Two honest cautions keep this from becoming a sales pitch. First, open standards enable interoperability but do not guarantee data quality: a valid, standards-conformant file can still contain mis-classified or incomplete elements, so the last lesson's discipline still applies on top of this one. Second, standards are living, contested and evolving - classification tables are revised, property definitions change, IFC has versions - so any named standard here is illustrative and fast-moving, not a fixed specification you should cite as authority.

And the deepest boundary remains. Shared standards let a rule and a model speak the same language, which is necessary for automated checking to function - but the language of the check is never the language of the law. The authoritative rule is always the actual building code and byelaw - the National Building Code of India, the applicable local development-control regulations, the relevant IS standards - interpreted by accountable humans. Standards make the machinery of checking possible; they do not, and cannot, make a check into a determination of compliance.

It is worth ending on the human and Indian reality of standards, because it is easy to treat them as if they simply exist. A standard is only useful if it is agreed and adopted - a shared vocabulary works only when the people writing rules and the people authoring models both commit to the same reference. That agreement is itself a governance task: someone must define the classification and property standards, keep them current as construction and regulation evolve, and get tools and practitioners to conform. Where that agreement is strong and widely adopted, automated checking has firm ground; where it is weak or fragmented, checking is unreliable no matter how good any single tool is. This is why standards are as much an institutional achievement as a technical one - and why the governance of rules and data, treated later in the course, matters so much.

The Indian context sharpens this. India's plan-scrutiny centres on quantitative development-control parameters - setbacks, ground coverage, floor-space index, height - which are exactly the checkable kind, so there is a genuine fit for shared, standardised data. But two realities temper it honestly. First, byelaws and development-control regulations vary enormously across thousands of urban local bodies, each with its own parameters and definitions, so a 'shared vocabulary' has to bridge real local variation - a substantial standards-and-governance task, not a given. Second, structured modelling itself is still emerging in much Indian practice, with many submissions still 2D, so agreed classification and property standards are often aspirational rather than in place. The encouraging reading is that the development-control checks that matter most need a relatively modest, achievable set of standardised data (a classified plot, footprint, floor areas, height), so adoption can start where the payoff is clearest.

The durable lesson is a shift in how you regard the unglamorous work of naming things. Classification, naming and property standards are not bureaucratic friction to be minimised; they are the backbone that lets rules and models be compared at all, and neglecting them is the quiet reason many automated-checking efforts fail. But hold the boundary to the end: shared standards make checking possible and make it scale, and open standards let many tools and parties interoperate - yet the standard is never the law. The authoritative rule is always the actual code and byelaw, the encoded rule and the data standard are only aids, and whether a design truly complies, together with the authoritative interpretation of every regulation, stays with the qualified professional of record, the approving authority and the governing law itself.