State what the release authorizes
A coordination model, a design model and a fabrication model support different tasks. Do not rely on the phrase “approved model” without saying what has been reviewed and what the recipient may do next. Write the intended release purpose against a named package: detailing, coordination, material planning or another agreed use. The project’s appointment and review procedures determine authority; the model’s visual detail does not expand that authority.
Define the package by identifiable objects
Specify included assemblies, zones or member identifiers and the version of their upstream design information. Keep exclusions explicit, especially connections, temporary conditions and interfaces awaiting another discipline. A file boundary is not always a package boundary. If one file contains both released and unreleased objects, give the recipient a reliable selection and status convention, and test that the export preserves it. A colour alone is too easy to lose or reinterpret.
Check the information the next team consumes
Ask the fabricator or detailer which identifiers, member properties, connection references and document links they need for the agreed use. Run a small recipient check before the full issue. Confirm that a member arriving in the receiving workflow can be related back to its reviewed source. Separate transmission success from technical acceptance: a file can open correctly while a critical interface remains unresolved. Log unsupported properties or ambiguous mappings as delivery issues.
Read diagram notes
- Define
- Name package, purpose and release status.
- Check
- Review interfaces and unresolved dependencies.
- Transmit
- Issue an immutable version reference and register entry.
- Respond
- Route late changes through a new controlled release.
Keep review comments attached to their baseline
Comments should reference the model revision and identifiable objects that were actually reviewed. If a new revision arrives during review, decide whether to finish the earlier package or restart the affected scope. Do not mix comments from both versions into an apparently complete approval record. AISC’s model-review resources are useful workflow background; project-specific agreements still control what a review signifies and who is entitled to release fabrication information.
Handle a partial steel release
Suppose a repetitive floor package is ready while the perimeter connection depends on a facade reaction. Identify the released internal assemblies and explicitly hold the affected edge assemblies. Link the outstanding reaction and connection decision to those objects. The recipient should be able to select the released set without reading an informal email and guessing. When the edge condition is resolved, issue a new package reference and show exactly which hold has been removed.
Treat the release as a maintained record
Retain the reviewed deliverables, object scope, transmittal, comments and disposition together. Subsequent changes need their own impact assessment and communication to the downstream party; overwriting a shared file is not a substitute. A practical release record answers four questions: what was supplied, for which use, against which reviewed information, and what remains excluded. That clarity is more valuable than a highly detailed model with an uncertain status.