The Model as Data

Start with what a traditional drawing actually is to a computer. A CAD drawing, even a beautifully detailed one, is fundamentally a collection of geometry: lines, arcs, hatches, text labels, arranged on layers. It is made to be read by a human, who supplies all the meaning. When you look at two parallel lines with a door swing between them, you understand 'this is a corridor with a door'; the file only holds the coordinates of some strokes. The layer might be named 'CORRIDOR', but that is a convention for humans, not a guarantee a machine can trust - the same line could be on the wrong layer, or a corridor could be drawn with no layer at all. Nothing in the geometry knows what it represents.

A structured model inverts this. Instead of storing the building as strokes on sheets, it stores it as a set of objects - a wall object, a door object, a space object - each of which explicitly records what it is and what it knows about itself. This is the essence of building information modelling: the model is not a drawing but a database of elements, from which drawings can be generated as one view among many. The corridor is no longer two lines that happen to look like a corridor; it is a Corridor element, with an identity, a type, and a set of named properties.

The difference matters precisely because automated checking is read-and-run, as the earlier modules put it. A rule such as 'every escape corridor in an assembly building must be at least the required clear width' can only run if something in the design can answer three machine questions: which elements are corridors, which of those are escape routes in an assembly building, and what is each one's clear width. A drawing cannot answer any of them without a human. A structured model can answer all three - because the meaning is stored as data, not left in a person's head. That is the whole point of the shift, and why the rest of this module is about the quality of that data: geometry alone is a picture, and you cannot run a rule against a picture. What you can run a rule against is geometry plus meaning, held as structured, machine-readable data.

The single most important idea in this lesson is semantic modelling: elements carry meaning. In a structured model, a corridor is not inferred from geometry - it is declared. The element is classified as a corridor (or, more precisely, a circulation space of a particular kind), and that classification is data the machine can act on. On top of the classification sit properties: named attributes with values and, crucially, units. The corridor's clearwidth is 1.2 m; its occupancytype is Assembly; its isegressroute flag is true; its length is 18 m. Each property answers a specific question a rule might ask.

This is why the course keeps repeating the phrase 'a corridor that knows it is a corridor and knows its width'. A checking rule does not look at pixels; it looks up elements of a class and reads their properties. If the corridor is correctly classified and carries a clear_width property with the right value and unit, a minimum-width rule can evaluate it in milliseconds. If the same corridor is modelled as a generic space with no width property - or worse, mis-classified as a room - the rule either cannot find it or reads the wrong thing. The meaning has to be present, correct and machine-readable, or the check has nothing to work with.

Properties also carry the context that decides which rule applies, not just whether one passes. The occupancytype tells the engine that the stricter assembly-building width applies rather than the residential one; the isegress_route flag tells it to include this corridor in escape-route checks; the fire rating on a door tells it which compartment rule is relevant. This is the semantic model doing real work: it is not enough for elements to have shapes; they must carry the attributes that regulation actually keys on. A rich model therefore looks less like a drawing and more like a structured record - each element a small labelled entry with a type and a set of properties.

The honest caution is that this meaning is authored by people. A corridor knows its width only because a modeller entered it, or a tool computed it, correctly. Semantics are powerful because they make a design legible to a machine - and fragile because they are only as true as whoever supplied them. That fragility is the subject of the next lessons; here the point is simply that meaning, not geometry, is what a check reads.

If a checkable design is a structured model, a second question follows immediately: in what format is that data stored, and can more than one tool read it? Most authoring tools have their own native format, but automated checking, and above all submission to an authority, needs data that is not locked to a single vendor. This is the role of open formats, and the best-known in building is IFC - Industry Foundation Classes: an open, vendor-neutral schema for describing a building as classified objects with property sets, so that a model authored in one tool can be read by another tool, a checking engine, or a reviewer. IFC and the wider practice around it are often called openBIM: the idea that the model is exchanged in an open standard rather than a proprietary silo.

Why does openness matter so much for compliance? Because checking is inherently a hand-off. The people who author the model, the engine that runs the rules, and the authority that reviews the result are usually different parties using different software. If the data can only be read by the tool that made it, none of that hand-off works reliably. An open, standardised container means a corridor exported as an IfcSpace with a defined property set is recognisable as a corridor with a width by any conforming reader - the classes and properties mean the same thing on both sides. That shared understanding is what lets rules and models 'speak the same language', a theme the classification lesson develops further.

It is worth being precise, and honest, about what IFC is and is not. It is a way to represent and exchange the model's data; it is not itself a set of rules, not a checker, and not a guarantee of quality - a valid IFC file can still contain mis-classified or incomplete elements. Nor is any format the authoritative building: the binding design remains the professional's coordinated work, and the authoritative rule remains the actual code and byelaw, never the file. Named formats here are illustrative and fast-moving, not a specification. In India, where many submissions are still 2D and structured BIM is often absent, open model formats are more an emerging direction than a universal reality - which is exactly why understanding them as the data foundation of checking matters before anything is automated.

Pull the threads together into the practical claim of this lesson: automated checking needs data, not just geometry, and that reframes what a designer is producing when they model for compliance. You are not only drawing a building that looks right; you are authoring a dataset that answers regulatory questions. Every rule that can be run corresponds to some element class and some property the model must carry: a minimum-width rule needs corridors that carry clearwidth; a travel-distance rule needs egress paths and exits with positions; a coverage or floor-space-index rule needs a plot, a footprint and floor areas; an accessibility rule needs doors that carry clearopening and routes that carry gradients. If the model does not hold those classes and properties, the corresponding rule simply cannot run, no matter how good the checking engine is.

This is why the model-as-data mindset comes before tools. A common and costly misunderstanding is to imagine that automated checking is mainly about clever software that 'looks at the design'. It is not: the intelligence that matters most is in the structure and completeness of the data the software is given. A modest checker over a rich, correct model beats a sophisticated checker over a thin, geometry-only model every time - because the second has nothing to read. The reason so many real attempts at automated compliance stumble is not the rules engine; it is that the model was authored as a set of shapes to produce drawings, with the semantic properties either absent, inconsistent or wrong.

So the takeaway is a shift in responsibility as much as technology. To make a design checkable, someone must decide what the elements are, classify them correctly, and populate the properties the applicable rules need - deliberately, not as a by-product. That is real work, and it belongs to accountable people; the next lesson is about what 'good enough' data actually means. And none of it changes the boundaries the course insists on: a structured model makes checking possible, but a check is still not an approval, the encoded rule is still not the law, and whether the design truly complies remains with the qualified professional of record, the approving authority, and the governing code and byelaws - the National Building Code of India and the applicable local development-control regulations - never with the data or the tool alone.