For owners: specification pack
Draft — pending operator review Three blocks · copy or download as plain text
An owner mandates the model; the practice, the contractor or the bureau pays for it because a clause requires the file. This page is the clause. It is written so that the properties Structura can actually demonstrate — a named model view definition, identifiers that survive a revision, a register of every default applied, a stated level of development, a published accuracy report — become the acceptance criteria in someone else's contract exhibit.
Nothing here asks you to trust a claim. Every requirement in these blocks maps to an artifact you can open before you cite the page: the sample deliverable, the accuracy methodology and the stated limits are all linked below.
Draft — pending operator review
This text is legal-adjacent and has not yet been through operator review (PRD open question
W-6). Read it, take it, adapt it — but have your own advisor check it before it goes into a
binding document, and treat the wording as subject to change until this flag is removed.
Model delivery clause
Paste this into a BIM standard or a contract exhibit. It names the schema and the model view definition, fixes identifier stability across revisions, makes the assumptions register a deliverable, states a level of development per class and requires a published accuracy report for the release that produced the file.
Why it is worded this way
- Names the MVD, not just "IFC" — the clause an owner already has usually names IFC 2x3 Coordination View, so paragraph 2 states the fallback position instead of pretending the older clause is not there.
- Ties acceptance to artifacts a supplier either has or does not: a register, a report, a review record.
- States the caps and the out-of-scope classes inside the clause, so scope is agreed before appointment rather than argued at delivery.
STRUCTURA — MODEL DELIVERY CLAUSE Draft language for an owner's BIM standard or contract exhibit. Describes Structura v0.6.0. 1. Schema and model view definition. The as-existing architectural model shall be delivered as an IFC4 Reference View [ReferenceView_V1.2] file, with that model view definition named in the file header. The spatial structure shall resolve Project -> Site -> Building -> Building Storey, and every delivered element shall be assigned to a storey. 2. Position on legacy IFC 2x3 Coordination View clauses. Where an existing clause requires IFC 2x3 Coordination View exported by certified software, delivery under paragraph 1 shall be accepted in substitution for that requirement for as-existing conversion work, provided the supplier names the view definition in both the file header and the delivery note. Where a receiving system cannot read IFC4, the parties shall record in the BIM Execution Plan which party performs the downconversion to IFC 2x3 Coordination View and with which tool: the supplier does not produce an IFC 2x3 export and does not hold buildingSMART software certification at the release named above (roadmap, no date). This paragraph is written to supersede the legacy clause, not to ignore it; a standard that leaves both in force is contradictory and shall be resolved before appointment. 3. Identifier stability across revisions. Every delivered element shall carry a GlobalId that is a deterministic function of that element's stable identity, so that re-export of a revised model preserves the identifier of every element whose identity has not changed. A correction to an element's classification, its dimensions, or a room's name or number shall not change its GlobalId. The supplier shall demonstrate this on request by re-exporting an unchanged model and comparing identifiers. 4. Assumptions register. Each delivery shall be accompanied by a machine-readable assumptions register listing every default the conversion applied, with its scope (building, storey or element), its value and the basis it was taken from — including any storey height inferred rather than measured, any wall thickness assumed from a single modelled face, any element class the input route did not reconstruct, and any room boundary recorded without its interior holes. The register is a contract deliverable, not an internal report. 5. Level of development. The model shall be delivered at the supplier's published, per-class level of development, and that published position shall accompany the delivery. For this supplier the position is approximately LOD 200, with LOD 300 dimensional intent on walls, across these 8 classes and no others: IfcWall, IfcDoor, IfcWindow, IfcColumn, IfcSlab, IfcStair, IfcRoof, IfcSpace. Mechanical, electrical, plumbing, structural framing, furniture and equipment classes are out of scope and shall not be claimed. 6. Accuracy report per release. Each release of the conversion software shall be accompanied by a published accuracy report giving, per element class, precision, recall and F1; dimensional error against ground truth; storey accuracy; and floor-area error for rooms — together with the threshold each figure is graded against, the input route it was measured on, and a description of the corpus, including whether that corpus is synthetic. A class the report does not grade shall be shown as not graded rather than scored. 7. Acceptance. A delivery is accepted when: the file opens in the Appointing Party's nominated IFC viewer without error; the spatial structure resolves per paragraph 1; the assumptions register per paragraph 4 accompanies it; the accuracy report per paragraph 6 names the release that produced the file; and every element the supplier's review queue flagged has been accepted, reclassified, dimensionally corrected, renamed or rejected by a named reviewer before issue. 8. Limits acknowledged by both parties. Conversion input is DXF — vector 2D plan and elevation sheets, or a 3D mesh export. Raster scans and PDF documentation are out of scope. One conversion covers up to 15 storeys and up to 50 sheets. Rooms are reconstructed on the 2D plans route only.
ISO 19650-3 RFP boilerplate
For an owner commissioning an Asset Information Model for a building it already operates. ISO 19650-3 is the operational-phase part of the standard — the one that governs information for an asset in use, which is exactly what a conversion appointment produces.
Why it is worded this way
- Written as requirements on the Appointed Party, so it drops into a procurement document without rewriting.
- Requires the response to declare unreconstructed classes before appointment.
- Puts federation, clash and coordination duties out of scope explicitly.
STRUCTURA — ISO 19650-3 RFP BOILERPLATE Draft language for a request for proposal to convert existing documentation into an Asset Information Model. Describes Structura v0.6.0. Scope. This appointment delivers an update to the Asset Information Model (AIM) of an asset already in use, under the operational-phase information management process of BS EN ISO 19650-3. It is a conversion appointment, not a design appointment: the deliverable is a semantic model of the existing fabric, derived from the Appointing Party's existing 2D CAD documentation. 1. Asset Information Requirements. The Appointing Party shall state, per element class, the level of information need and the purpose that class serves in operation. The Appointed Party shall state in its response which of those classes it reconstructs and which it does not — before appointment, not at delivery. 2. Information container and exchange format. Each delivered container is an IFC4 Reference View [ReferenceView_V1.2] file, accompanied by a tabular schedule of the same elements (.xlsx and .csv) and by the assumptions register described at 5. Storey labels follow a stable scheme (L00, L01, and upward) and every element carries its storey, its class, its per-class dimensions, its confidence, the input route it came from and its GlobalId. 3. Level of information need. Geometrical: approximately LOD 200, with LOD 300 dimensional intent on walls, for these classes and no others: IfcWall, IfcDoor, IfcWindow, IfcColumn, IfcSlab, IfcStair, IfcRoof, IfcSpace. Alphanumerical: as listed at 2, plus name, number and floor area for rooms. Documentation: the assumptions register and the published accuracy report for the release that produced the container. 4. Revision and identification. Each delivered version is immutable and identified; a later version supersedes it without overwriting it. Element GlobalIds are stable across revisions, so a revision can be reported as a difference — elements added, changed, renamed, removed — rather than as a wholly new set of identifiers. 5. Quality assurance and acceptance. Each container is accompanied by (a) the assumptions register listing every default applied and its basis, (b) the published accuracy report for the release, and (c) a review record showing every element the pipeline flagged as low-confidence and the disposition a named reviewer gave it. Acceptance criteria are those set out in the model delivery clause. 6. Federation and coordination. The AIM produced under this appointment covers architectural fabric only. Federation with mechanical, electrical, plumbing or structural models, and any clash or coordination duty, is out of scope and remains with the Appointing Party or another Appointed Party. 7. Security-minded approach and personal data. The appointment requires drawing files only. No personal data, no occupancy records and no asset security information are required to perform the conversion, and none shall be requested. Drawing files shall be handled under the Appointing Party's stated security-minded approach. 8. Exclusions to be stated in the response. Vendor-native 2D CAD binaries, raster scans and PDF documentation are not converted. Rooms are reconstructed on the plans route only. Classification references (for example Uniclass or OmniClass tables) and COBie deliverables are not produced at the release named above (roadmap, no date). Certification of the exporting software against a buildingSMART programme is not held (roadmap, no date).
Declared LOD position
Procurement needs a level of development to compare quotes against, and the market prices those tiers explicitly. Structura publishes one instead of leaving it to be inferred: approximately LOD 200, with LOD 300 dimensional intent on walls, and the 400 to 500 band refused in writing.
Why it is worded this way
- Per class, not one number for the whole model.
- Names what each class does not carry, which is the half a procurement officer cannot otherwise check.
- Refuses the premium band out loud rather than staying silent and being asked for it later.
STRUCTURA — DECLARED LEVEL OF DEVELOPMENT Draft position statement. Describes Structura v0.6.0. Headline position. Approximately LOD 200, with LOD 300 dimensional intent on walls, across the 8 element classes Structura reconstructs. The position is declared per class, republished per release, and checkable against the accuracy report for that release. Per class: IfcWall — LOD 200 + LOD 300 dimensional intent. Length, thickness and height, measured from the sheet set. A wall seen from one side only on the mesh route takes an assumed thickness and says so in the assumptions register. No layered construction, no material build-up, no connection detail. IfcDoor — LOD 200. Placed in a host wall with measured width and height. No door type, hardware, fire rating, swing schedule or manufacturer data. IfcWindow — LOD 200. Placed in a host wall with measured width, height and sill. No frame profile, glazing specification or performance data. IfcColumn — LOD 200. Position and section extents from the plan, extruded to the storey height. No structural analysis, no connections, no reinforcement. Not reconstructed at all on the mesh route. IfcSlab — LOD 200. Storey footprint and thickness. Where the drawings state no thickness, a canonical default is applied and recorded in the assumptions register. No layers, no falls, no penetrations. IfcStair — LOD 200. Footprint and the storeys it connects. No tread, riser, landing or balustrade geometry. Not reconstructed at all on the mesh route. IfcRoof — LOD 200. Faceted roof surface reconstructed from the mesh route. No build-up, no drainage, no rooftop plant. IfcSpace — LOD 200. Outer-ring boundary per storey with a computed floor area, plus name and number where the sheet labels the room. Interior holes are not carved out of the boundary; that is recorded per room in the assumptions register. Plans route only. Refused in writing. Structura does not deliver LOD 350, LOD 400 or LOD 500, and a specification that requires that band should not name Structura as the route to it. Specifically: no connection or assembly detail, no fabrication or installation geometry, no as-built verification against a survey, no manufacturer, warranty or maintenance data, and no mechanical, electrical, plumbing, structural framing, furniture or equipment classes. Nothing in the pipeline authors geometry that a reviewer draws. A reviewer accepts, reclassifies, corrects dimensions, renames or rejects what was detected; a reviewer cannot model a missing element into the file. An element the drawings do not contain is not in the deliverable, and the assumptions register says so.
Level of development, class by class
The same position as the block above, laid out for a reviewer who needs to check one class at a time. The classes are read from the release's own class list, so this table cannot drift from what the pipeline emits.
| Class | Position | What the file carries — and what it does not |
|---|---|---|
| IfcWall | LOD 200 + LOD 300 dimensional intent | Length, thickness and height, measured from the sheet set. A wall seen from one side only on the mesh route takes an assumed thickness and says so in the assumptions register. No layered construction, no material build-up, no connection detail. |
| IfcDoor | LOD 200 | Placed in a host wall with measured width and height. No door type, hardware, fire rating, swing schedule or manufacturer data. |
| IfcWindow | LOD 200 | Placed in a host wall with measured width, height and sill. No frame profile, glazing specification or performance data. |
| IfcColumn | LOD 200 | Position and section extents from the plan, extruded to the storey height. No structural analysis, no connections, no reinforcement. Not reconstructed at all on the mesh route. |
| IfcSlab | LOD 200 | Storey footprint and thickness. Where the drawings state no thickness, a canonical default is applied and recorded in the assumptions register. No layers, no falls, no penetrations. |
| IfcStair | LOD 200 | Footprint and the storeys it connects. No tread, riser, landing or balustrade geometry. Not reconstructed at all on the mesh route. |
| IfcRoof | LOD 200 | Faceted roof surface reconstructed from the mesh route. No build-up, no drainage, no rooftop plant. |
| IfcSpace | LOD 200 | Outer-ring boundary per storey with a computed floor area, plus name and number where the sheet labels the room. Interior holes are not carved out of the boundary; that is recorded per room in the assumptions register. Plans route only. |
Check the evidence first
Deliverable
What is in the file, and the sample package to open before you write the clause.
Accuracy
The methodology and the per-class figures the clause's paragraph 6 asks a supplier for.
Limits
What is not converted, what is roadmap, and how a file out of scope is refused.
Read this before quoting a figure
The published accuracy report measures the pipeline against synthetic, seeded fixtures whose
ground truth is built from the same parameters as the drawings. That demonstrates
self-consistency, not survival of messy real CAD. Cite the methodology, and read the caveat
on the accuracy page before putting any figure into a specification.