Agree what the recipient will accept
Before the deadline, confirm the purpose, recipient, permitted distribution, delivery location and approval process. Agree model scope, format, schema, naming convention and required supporting information. Ask the recipient to test a small package early enough to correct compatibility problems.
Adapt this workflow to the project information requirements, delivery agreement and any required client templates.
Include enough context to reproduce the delivery
| Package item | What it should answer |
|---|---|
| Model and companion assets | Which files must stay together for the recipient to open the result? |
| Delivery manifest | What is this revision, who prepared it and what is its intended use? |
| Source revision list | Which discipline models and revisions were included or excluded? |
| Export configuration | Which application version, scope, format options and transformations were used? |
| Coordinate note | Which units, origin, axis convention and project reference apply? |
| Validation evidence | Which checks ran, what failed and what was accepted as an exception? |
| Change and issue list | What changed since the last delivery and what remains unresolved? |
| Recipient instructions | How was the package tested and where should questions be recorded? |
Use paths that remain valid after the recipient extracts the package. Test a copy from a different folder so missing assets or references to your workstation are discovered before delivery. Avoid placing access tokens, passwords or private workstation paths in the manifest.
Example delivery manifest
Delivery: Example project / coordination review / R03
Prepared by: [name and team]
Prepared on: [date and time zone]
Purpose: [agreed review task]
Model files: [file names and sizes]
Source revisions: [list or attached schedule]
Export application and version: [value]
Format and schema: [value]
Scope and exclusions: [value]
Units and coordinate reference: [value]
Applied transformations: [value or none]
Receiving application tested: [name and version]
Validation evidence: [report names]
Open issues and exceptions: [identifiers]
Approval status: [pending / accepted / rejected]
Reviewer and decision date: [value]
Distribution: [approved recipient group]If checksums are used, state the algorithm and calculate them on the final files. A checksum can help detect a changed or incomplete file; it does not by itself prove who created or approved the package.
Release the package in a controlled sequence
Freeze the candidate
Identify source revisions and export configuration. Place outputs in a new revision folder rather than overwriting the last accepted delivery.
Review the final files
Run checks on the files that will actually be sent. If output changes, repeat affected checks and refresh the manifest.
Transfer through the agreed channel
Send the complete package to the approved location and confirm the recipient can access it.
Obtain a receiving decision
Record receipt separately from acceptance. Ask the recipient to confirm the tested application and report issues against the delivery identifier.
Preserve the evidence
Keep the accepted package, decision and superseded revision history according to the project's retention process.
Keep handover issues tied to the model
BIM Collaboration Format (BCF) supports exchanging model-related issues between applications. Where both teams support it, use it to retain issue context alongside the agreed model revision. A BCF issue package does not replace delivery of the model itself.
Official references