A file format cannot control production by itself. Control comes from a project-designated information container, a named revision and suitability state, a defined use, and evidence that the released factory input reproduces it.
The coordinated model shows one mullion position, the issued PDF shows another, and a CAD export has lost several opening marks. The factory asks which file is correct. ‘Use the latest’ is not an answer: timestamps can change during copying, file names can be reused, and the most recent model may not be authorised for manufacture. A defensible handoff identifies what has been authorised for each production action and then proves that every derived file preserves the necessary geometry, attributes and decisions. It does not make one format universally superior or decide the project’s contractual document precedence.
1. Define the production purpose before asking which file controls
ISO 19650-2:2018 describes an information-management process for the delivery phase and exchanges of information using BIM. Its public scope supports controlled production, review and acceptance of information; it does not nominate a file type as the universal manufacturing authority. Start with the exact activity: estimating, opening coordination, profile cutting, glass ordering, machining, assembly, inspection or as-built handover. The same container may be suitable for one use and unsuitable for another.
Create a project-authorised use register. For every activity, record the designated information container, identifier, revision, status/suitability, issue date, issuer, accepted native and exchange formats, and any inseparable companion schedule or instruction. Preserve the designation itself as evidence. Do not reconstruct it later from an email subject, folder position or modified date.
Treat ‘model’, ‘CAD’ and ‘PDF’ as broad families, not sufficient identities. A native authoring model, IFC exchange, DWG extract, plotted PDF, spreadsheet schedule and machine file carry different subsets of information. Record exactly what each contains and what it is permitted to drive. Where no authorised record exists for an action, the production state is hold—not whichever file opens most easily.
| Production action | Designated container and exact revision | Permitted use | Required companions | Release evidence |
|---|---|---|---|---|
| Opening coordination | [ID / revision / status] | [project-defined] | [model view / schedule / RFI] | [authorised reference] |
| Profile cutting or machining | [ID / revision / status] | [project-defined] | [dimensions / datum / hardware data] | [release reference] |
| Glass ordering | [ID / revision / status] | [project-defined] | [glass schedule / approved build-up] | [release reference] |
| Inspection and packing | [ID / revision / status] | [project-defined] | [mark list / acceptance plan] | [release reference] |
2. Give every handoff a machine-checkable identity
A controlled transmittal should identify project, originator, container ID, revision, status/suitability, issue purpose, file format and version, coordinate/unit conventions, related containers, checksum or other integrity value, and the superseded set. The recipient should acknowledge the received identity—not merely that a download link worked. If a package is re-zipped or renamed, retain the source identity and recalculate integrity evidence without pretending the content received a new design revision.
Separate semantic revision from file generation. A PDF plot, IFC export and DWG extract generated from one accepted source may have different creation times but should remain traceable to the same source revision and export settings. Conversely, an unchanged file name can conceal changed content. Compare controlled identifiers and hashes where appropriate rather than sorting by time.
Record software and schema/version because an exchange can open successfully while changing objects, properties, units, fonts, clipping, references or geometry. buildingSMART’s official IFC schema page lists distinct official releases and components. That is evidence that ‘IFC’ alone is incomplete exchange metadata, not proof that a particular IFC export is fit for a window-production purpose.
| Field | Value to preserve | Failure exposed |
|---|---|---|
| Container identity | Project/originator ID, revision and suitability | Uncontrolled or wrong-purpose issue |
| Technical environment | Native format/version, exchange schema/view, units and coordinates | Silent interpretation change |
| Derivation | Source container/revision and export settings | Orphaned PDF/CAD/IFC |
| Completeness | Expected files, references, fonts and schedules | Missing linked content |
| Integrity | Size/hash and received acknowledgement | Corruption or content substitution |
| Supersession | Withdrawn IDs and points of use | Obsolete information remains active |
3. Validate the export as an engineering comparison, not a visual spot-check
Openability is only the first gate. Compare source and derivative at the information needed for the stated use: unit scale, origin and orientation; opening marks and counts; bounding dimensions and datums; profile/member locations; panel and handing logic; glass and hardware attributes; revision notes; sections/details; and linked schedules. A clean-looking PDF can omit a layer; a geometrically plausible IFC can lose a property mapping; a DWG can change units or detach external references.
Use both deterministic checks and a high-information visual sample. Automated checks can compare file inventories, hashes, opening-mark populations, selected coordinates, property presence and schedule totals. Human review should inspect complex corners, repeated types, atypical openings, mirrored/handed units, curved or sloped geometry and details where annotation carries meaning. Record the sample and exceptions; ‘checked’ without scope is not reproducible.
Do not correct a derivative silently. If the export exposes a source error, route the correction through the authorised revision process and regenerate the derivative. If the export itself is wrong, preserve the failed file and validation record, correct the export configuration, and issue a newly identifiable package.
| Check family | Source fact | Derivative check | Disposition evidence |
|---|---|---|---|
| Population | Opening marks/types/counts | No missing, duplicate or reassigned marks | Exception list and owner |
| Geometry | Units, origin, key dimensions and handedness | Controlled comparison at sampled and critical units | Comparison output / sign-off |
| Properties | Glass, finish, hardware and status attributes | Required fields retained and mapped | Mapping report |
| Presentation | Notes, symbols, linework, fonts and clipping | Readable and unambiguous at issued scale | Plot review |
| References | Schedules, links and external references | All expected companions present | Manifest reconciliation |
4. Trace the authorised handoff into factory-facing data
Production rarely consumes a design container directly. A planner may re-key dimensions into an ERP, convert profiles into cutting lists, translate hardware into a bill of materials and create machine instructions. Each translation is a new control point. Assign a preparer and independent checker, link every output to the authorised input identity, and record transformations such as unit conversion, deductions, machining rules and rounding.
Reconcile population and critical fields in both directions: every released opening mark must appear in the production set, and every production record must point back to a released mark. Then reconcile profile, glass, hardware, finish and dimensional outputs against the designated input. A total count match can hide a swapped type or duplicated mark, so compare keys and attributes, not only totals.
Keep activity-specific holds visible. An accepted geometry set does not prove that glass, hardware, finish, performance evidence or site dimensions are released. The production matrix should show each gate separately and prevent an information export from being mistaken for a complete product release.
| Factory output | Authorised input identity | Transformation to disclose | Independent verification |
|---|---|---|---|
| Opening/work-order list | [container / revision] | Type grouping and quantity expansion | Mark-to-mark reconciliation |
| Profile cutting list | [container / revision] | Deductions, angles, units and rounding | Critical-dimension sample plus totals |
| Glass order | [schedule / approved record] | Daylight-to-order-size rule if authorised | Mark/build-up/size reconciliation |
| Hardware/BOM | [schedule / approved record] | Set expansion and handing mapping | Set-to-opening reconciliation |
| Machine data | [checked cutting/machining record] | Postprocessor and machine version | Simulation/first-piece route |
5. Make supersession reach every point of use
When information changes, identify the affected opening marks, attributes, factory outputs and physical work state. Withdraw obsolete digital packages from active locations while retaining an audit copy, then verify local downloads, print stations, planning sheets, ERP attachments and machine queues. Publishing a new model does not remove an old PDF from a cutting bench.
Use a change-impact record that asks what has already been priced, ordered, cut, coated, assembled, inspected or packed. The authorised project and commercial routes decide what happens next; the information-control record should expose the population and status without claiming entitlement or responsibility.
Audit from both ends. Select an issued container and find its validation, release, derived factory records and supersession status. Select a physical opening mark or machine job and trace it back to the authorised input. Any broken link remains an open control failure even if the geometry appears correct.
| Point of use | Old identity found? | New identity installed? | Affected work state | Verified by/date |
|---|---|---|---|---|
| Common data environment / transmittal | [record] | [record] | Information only | [record] |
| Estimator/planner local files | [record] | [record] | Priced/planned | [record] |
| ERP/work orders | [record] | [record] | Ordered/released | [record] |
| Print/shop-floor stations | [record] | [record] | Cut/assembled | [record] |
| Machine queues | [record] | [record] | Queued/processed | [record] |
FAQ
Is the BIM model always the production authority?
No. File format does not establish authority. Use the exact container, revision, suitability and permitted purpose designated through the project’s authorised procedure.
Can a signed PDF be used while the model supplies dimensions?
Only if the project has expressly defined that coordinated use and the identities, fields and reconciliation route are controlled. This guide does not establish such a rule.
Does a successful IFC or DWG export prove equivalence?
No. Validate the information needed for the intended use, including geometry, population, properties, annotations and references.
What if files disagree?
Hold the affected action, record the precise conflict and obtain an authorised disposition. Do not select a format or the newest timestamp by convention.
Should superseded files be deleted?
Remove or block them at active points of use while retaining the audit evidence required by the project’s information-management and retention procedure.
Continue the project review
Connect this guide with the proposed window and door systems, then review how Cavorlen approaches manufacturing and quality control. When your schedule is ready, send it through the project review form.
Official sources used
ISO — ISO 19650-2:2018 information management during asset delivery ↗ISO — ISO 19650-1:2018 concepts and principles ↗buildingSMART International — official IFC schema specifications and releases ↗buildingSMART International — IFC Model View Definition database ↗ISO — ISO 16739-1:2024 IFC data schema ↗Related buyer guides
This article does not interpret a contract, establish document precedence, declare BIM, CAD, PDF or any proprietary file legally controlling, approve a model for fabrication, define a universal common-data-environment workflow, or allocate design responsibility. The project’s authorised information-management procedure and responsible parties must designate the applicable record, status and permitted use. No Cavorlen software capability, BIM deliverable or production practice is claimed.