Cross-file Buildability · One project, many IFC files

A FEDERATED SET, READ AS ONE PROJECT

What is in this delivery, how do the files link, and what can it actually answer?

Open the whole submission. This page reads the files as one project: what each file is, how they link, where they contradict each other, and which Buildability parameters the set can answer at all.

Choose the IFC file(s) or the folder of this submission

Select every file at once, or the folder that holds them. Sub-folders are searched. Names like BLK-A-ARC.ifc are read for the block and the discipline.

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.

An invented two-block set, with the five defects a real submission has

Nothing is uploaded. Every file is opened and read inside this browser tab, one at a time, on this computer. There is no server, and no copy is kept anywhere — and after one visit this page works with the network off entirely.

First time here?

THE SET

What was delivered

—answerable

CAN THE SET ANSWER THE CODERequired parameters, by blockevery parameter against every block —

Each row is a parameter a buildability assessment needs; each column a block. Available means the discipline that carries it was delivered. Value is what the merged models for that block actually measure — availability and value are different questions, and a tool that ran them together would report a missing M&E model as a low M&E score.

WHERE THE FILES DISAGREE

Conflicts across the set

Nothing here is visible in any single file. These are the defects that only exist between them — and every one of them silently corrupts a figure taken over the set.

Export the set — the node and edge rows Databricks already uses

FILE BY FILEWhat each file isblock, discipline, elements and units, and whether the name agrees with the contents

The block and discipline of each file, and whether its name and its contents agree. Exports are the node and edge rows Databricks already uses, not a picture — see the method tab.

KNOWLEDGE GRAPH

How the files are linked

Read left to right, one column per layer: project → building → discipline → file → level → space → component, and at full scope on through value → pass/fail → clause → section → Code of Practice. Columns rather than a settled cloud, because this graph has a direction and a real submission drawn as a cloud is one dark cluster with every label over every other. Click a node to light its path both ways; the canvas scrolls sideways when the chain is long.

Scope Show labels Max nodes

WHERE THE MODEL IS

Every element, nested by block, discipline and class

Area is element count, because the question a treemap answers here is which file carries the weight of the delivery. A block whose architectural tile dwarfs its structural one is a block whose C&S model is behind.

THE DELIVERY STRUCTURE

Every block against every discipline

A tree of what the project needs, not of what arrived — so a discipline that was never delivered is a stump on the diagram rather than something you have to notice is not there. Storeys hang off the file that models them; a red one is a floor two files put at different heights. At full depth each block also carries its verdicts, and the clause and section of the Code behind each one.

Depth

TRACEABILITY

From the file to the clause, in one chain

Read left to right: project → file → level → space → component → value → pass/fail → clause → section → Code. Instances roll up into shared type nodes, so a component is a class with its count and not half a million elements. Click any node to light its path in both directions — back to the files that evidence it, forward to the clause it answers.

View Block Max nodes

WHAT THIS TOOL IS

The question that comes before the score

Every other tool here reads one model. A submission is not one model, and almost every question the Code asks spans several. This reads the set: what each file is, how they link, where they contradict each other, and which parameters the set can answer at all.

Availability and value are separate. A block with no M&E file has no M&E prefabrication level — that is not a score of zero, and reporting it as one would be a lie in the most consequential direction.
The filename is a declaration; the contents are evidence. When they disagree the filename is used, because the delivery structure is a fact about the project rather than the geometry — and the disagreement is reported.
Storeys are the join. They are the only thing a federated set genuinely shares. Two files putting one floor at two heights is the classic defect, and it corrupts every per-level figure downstream.
Nothing leaves the tab, and after one visit nothing needs the network either.

The traceability chain

The sixth tab draws one graph from the delivery to the clause: project → file → level → space → component → value → pass/fail → clause → section → Code. It is the join this repository has always implied and never drawn — the take-off knows which components sit on which level, the validator knows what it measured and whether that clears the published threshold, and the Code dataset knows which table that threshold came from and which section the table sits in. A component node is an IFC class, not an element: a submission has half a million elements and no useful picture of them, and thirty classes and a very useful one. The graph is capped at a stated number of nodes, the smallest are dropped first, and what was dropped is reported rather than silently lost.

How the output moves to Databricks

The exports are not a picture or a PDF. They are the same node and edge rows the lakehouse builds its own graph from, with the same column names as Databricks/buildability/graph.py — node_id, node_type, label, sub_label, file_id, status, props and edge_id, src_id, src_type, rel, dst_id, dst_type, props — plus a flat coverage fact table keyed on block and parameter. A notebook reads them into Delta without a translation layer, and a translation layer is exactly where a graph and the tables behind it drift apart.

What this cannot know — read before relying on it

Block and discipline come from filenames. A set named consistently reads perfectly; a set named final_v3_REVISED.ifc reads as one unclassified block, and the tool says so rather than guessing.
An IFC carries no federation. There is no field saying "this is the C&S model of block B". The relationships drawn here are inferred from names, storeys and shared ids — they are a reading of the set, not a declaration by it.
Storey matching is by normalised name. "Level 3", "L3" and "3RD STOREY" are treated as one floor. A project that names floors in a way this does not recognise will show them as separate, which is visible on the tree as a block with too many levels.
Elevation alignment assumes a shared datum. Two models set out from different origins will show every floor as misaligned. That is worth knowing, but it is one finding, not one per floor.
Values are computed per block, over that block's merged models. Where a discipline is absent the parameters it carries are reported as unavailable, never as zero.