BUILDABILITY PARAMETER AND VALUE CHECKS

IFC models Validator

Runs in this tab · your files stay on this computer

BUILDABILITY PARAMETER AND VALUE CHECKS

IFC Buildability Parameters Validator

Open your IFC models. This page checks whether they carry the Buildability parameters the Code requires, and whether the values in them are sizes the Code publishes.

Choose your IFC file(s), the submission .zip, or its folder

Architectural, C&S and M&E can be opened together, and the more of the set you open the more parameters can be answered — an M&E parameter is unanswerable without the M&E model. Sub-folders are searched. A submission .zip is read where it is, never extracted: its models are unpacked one at a time in this tab’s memory while each is read. With the submission’s BS01 buildability workbook (.xlsx), CORENET X manifest.json and PDF drawings — inside the zip or the folder, or picked with the models — tab 4 sets what the submission declares against what its models show; anything else is ignored. From a submission, the drawings read are the ones filed under buildability, building design and structural works.

Nothing chosen yet

Nothing is uploaded, whatever the dialog calls it. In Chrome and Edge, Choose a folder opens a picker headed Select Folder and then asks to view files, which is what actually happens. Firefox and Safari have only the older control, which is headed Select Folder to Upload and warns about uploading: that is the browser’s word for handing files to a page, and it says the same thing whether a page sends them on or reads them where they sit. This one reads them here. It has no server to send them to, and the Content-Security-Policy in its own HTML — connect-src 'self', form-action 'none' — forbids it from opening a connection anywhere else or submitting the form at all. Open your browser’s Network tab and watch: reading a submission makes no requests.

Nothing is uploaded. Your files are read inside this browser tab, on this computer. There is no server and no account. Close the tab and nothing remains.

SUMMARY ANALYSIS

What the checks add up to

This summary is generated automatically from the checks on this page using fixed rules. No AI model is used, and nothing leaves your computer. Every figure can be traced back to the diagram, the Buildability Items tab, or the declared-vs-modelled comparison.

RELATIONSHIPS

From the file to the value, and where it is in the model

Read left to right: file → building block → level → space → element → Buildability item → property → value. Every box is green, orange or red, and they mean the same thing in every column: green is carried and a value the Code publishes, orange is partly carried, inferred from a name, or a size the Code does not publish, red is not carried at all, and grey is nothing here to judge. A file, a block, a level or a room takes its colour from what is measured under it — red only when every question asked under it is unanswered — and hovering it says how many of them. Click any node to light its chain — and the same elements light up in the model beside it.

The model

More about the selected node

THE LIST BEHIND THE PICTURE

Every parameter this scope asks for

BUILDABILITY ITEMS

Every required property, element by element

The Buildability data requirement issues 29 rows over 8 items, which are 33 checks here: four of its property names are not IFC+SG properties, and each one is the two the mapping actually publishes — InternalLength and InternalWidth where it says InternalDimensions, and so on. Every row below is one element and one required property, with the file it came from, its GlobalId and where in the building it is — enough to paste into a viewer and select the thing. Green is carried under the name the requirement gives it. Red is not carried at all. Orange is everything in between, and the status column says which.

The 29 checks

One row per required property. The bar is the elements behind it, coloured by their verdicts. Click a row to see those elements below.

The register

DECLARED AGAINST MODELLED

What the submission says, against what its models show

A submission gives four accounts of one building: the models, the BS01 buildability workbook that computes its score, the CORENET X manifest that lists its blocks and files, and the 2D drawings — wall schedules per storey, floor levels on the sections, column and beam sizes on the structural plans, the computation sheets, the development each title block describes. Each row below measures one thing the workbook, the manifest or a drawing declares — a wall length by system, the split of floor area between PPVC, precast and cast in-situ, a pre-requisite share, the three most common sizes, a file’s SHA-256 — in the models, and says whether the two agree. Every modelled number says how it was identified: by the IFC+SG ConstructionMethod property, which is what it is for, or only by a type name.

The BS01 workbook, manifest.json and PDF drawings, if they were not in the folder you picked. Read here, like everything else: a drawing’s text is read in this tab and never sent anywhere. These are pointers for your own checking — a difference says where to look, not that the submission is wrong.

ABOUT

What this does, and what it will not claim

  • What you need: an IFC file — the standard export from any BIM tool.
  • What you get: every parameter the Code needs, how much of your model carries it, and whether the values are ones the Code publishes.
  • Your files never leave this computer. They are read in this tab. Nothing here sends anything anywhere.
  • Missing is reported as missing, never as a low score. A parameter the model does not carry is an unanswered question.
  • Stated and inferred are different answers. A method read from a property is a fact the model asserts. One read from a type name is this tool interpreting a string.
  • The model beside the graph is boxes. One box per element, drawn from its extent. No openings, no profiles, nothing curved — it shows you WHERE a thing is, not what it looks like.
  • What it is not: not a score, not a submission, not legal advice.
What the numbers count
  • Elements read is every element in the file, sub-elements included — a curtain wall’s mullions and panels, a stair’s flights. Elements checked is the smaller number: whole elements of the classes the Code asks about. The two differ a lot on a real model, and both are shown.
  • Storeys is every IfcBuildingStorey in the file. Large exports carry hundreds — one per level per block, plus levels nobody built on. Levels with elements is the number that means something, and it is what the graph draws.
  • Open What was read above the graph for the full list: every IFC class with its count, and every level with its elevation.
What it cannot check
  • An IFC has no GFA and no building category. Both are declared to the authority under its own rules.
  • Precast and cast in-situ are the same IfcWall. Only the material and the type name tell them apart. A model that names neither reads as cast in-situ.
  • Reinforcement is rarely modelled, so the welded mesh pre-requisite usually has to be declared.
  • M&E is usually a separate file. A missing M&E parameter normally means that model was not loaded.
  • A name is not a stated value. Where a parameter can only be inferred, the schedule says what the name must contain before it counts.
  • A pass here is not compliance. It says the model carries the parameter and the value is one the Code publishes. The submission is the QP’s.
Where the parameters and the sizes come from

The whole IFC+SG submission requirement — every parameter over every IFC entity and agency — is data/ifc-sg-parameters.json, generated by tools/build_ifcsg_parameters.py from the official CORENET X IFC+SG Industry Mapping workbook, so it cannot drift from the edition it names. Property names are that workbook’s own spelling, verbatim. The Buildability items and the properties each one requires are data/buildability-items.json — the data requirement as issued, 29 rows over 8 items, readable and arguable without touching this page. The wider parameter list is data/buildability-parameters.json. The sizes it checks values against are read from the machine-readable Code of Practice on Buildability 2022 in this repository — Table 2C for door openings, Table 4D for windows, the modules for columns and floor heights. No figure is written into this page: change one in the dataset and the verdicts change with it. Export CSV gives every parameter, its coverage and the values found.