Q QuantumSteel Design

Long-form field guide · 11:50

Steel Project Handoff: Submittals, Revisions, and Release Control

Coordinate steel submittals, review comments, RFIs, revisions, partial releases, and fabrication data with a clear source baseline and documented handoff.

Practical context

How coordinated steel information reaches the shop and field

A reliable steel handoff identifies the receiver, the decision, the applicable source baseline, and the permitted use. This field guide follows submittal comments, an RFI, and a fictional B12 member change through related drawings, material lists, and shop outputs. It explains how visible holds, defined release boundaries, change records, and recipient communication support a coordinated project workflow.

Educational estimating and coordination examples only. Current contract documents, adopted standards, and the responsible project professionals control actual work. This video does not authorize design, procurement, fabrication, modification, or erection.

Video chapters

Jump to each structural steel topic.

Chapter links open the published YouTube video at the selected part of the field guide.

  1. Why handoff control matters
  2. 1. Responsibilities and inputs
  3. 2. Submittals and review comments
  4. 3. Questions and documented decisions
  5. 4. Revision impact and a worked example
  6. 5. Partial releases and shop handoff
  7. 6. Practical controls and final review

Companion reading and practice

What should travel with a partial release?

Imagine a training package that releases Area A but holds Area B while an RFI remains unanswered. Both areas appear in the same model, so a model file alone does not describe the permitted scope.

List the included marks, held work, source revisions, output files, exceptions, and authorized decision. A report generated from saved records can support this recordkeeping, but the report itself does not release steel for fabrication. File recipients still need the actual controlled deliverables.

Try it with a sample

Create a fictional project with one held item and prepare a handoff preview. Check that the hold is still visible before printing.

Prepare a handoff practice record

Examples are fictional learning exercises. This companion text adds context to the video; the transcript below records the narration.

Primary sources

References and further reading

Use the edition and requirements adopted for the project. These references support further reading; a short video does not reproduce the complete standards.

Published by Quantum Steel Design. Sources and editorial approach · Report a correction · Companion guide updated .

Accessible transcript

Steel project handoff and release control transcript

The visible transcript makes the video content available to people and search systems without requiring playback.

  1. A steel model can look complete while the information sent to the shop is still incomplete, outdated, or misunderstood. The handoff connects technical work to the next person’s decision. This guide follows that connection through submittals, review comments, revisions, and release, using a fictional change example that you can adapt to your own coordination process.
  2. We are discussing information control, not assigning professional responsibility or approving construction. Contracts, adopted standards, project procedures, and the responsible professionals establish the actual requirements. A checkbox, file name, or model status cannot independently authorize fabrication or erection. Treat the example workflow as a discussion aid and adjust it to the real project.
  3. Begin by naming the receiver and the decision they must make. An engineer reviewing design intent needs different information from a fabricator preparing a work package or an erector planning delivery. Ask what documents, context, and unresolved items that receiver needs. A handoff succeeds when the next action is clear and supported.
  4. Document who supplies design information, who develops connection details, who checks the work, who routes submittals, and who controls release under the project procedures. Clarify the required inputs and deadlines for each role. Do not assume that a familiar job title settles the scope or that using the same software settles responsibility.
  5. Create an issue register for the drawings, specifications, models, addenda, and accepted decisions used in the work. Capture document identifiers, revisions, dates, and status. A folder named latest is not an issue register. The baseline must let a reviewer identify what was used, what was replaced, and what remains unresolved.
  6. Received means a file arrived. Checked means a stated check was performed. Reviewed describes a review process with its own scope. Released means the project process authorized a defined next use. Those words are not interchangeable. Define the status vocabulary and permissions for the project, then show them consistently in registers and transmittals.
  7. A useful submittal identifies its purpose, included areas, documents, revision level, and requested review action. It should also identify related information and unresolved exceptions. Avoid making the reviewer guess whether the package is a complete area, a limited early issue, or a response to previous comments. That ambiguity can travel downstream.
  8. Build the package from a controlled list of documents and outputs. Check that the model, drawings, schedules, and referenced details tell a consistent story for the submitted scope. Include a transmittal and an exception list where needed. A clear list of what is included helps expose what is absent before formal review begins.
  9. When comments return, give each actionable item a stable identifier. Record the affected document or member, the proposed response, the responsible person, and the completion state. Some comments require clarification or design input. Others correct drafting or coordination. Distinguish those paths so a simple closed label does not conceal an unresolved technical question.
  10. Read the response wording and attached comments, not just the color of a stamp. The meaning of an approval or resubmittal status depends on the project process and stated conditions. A reviewed package may still have exceptions or required follow up. Carry those conditions into the work that follows and obtain the required disposition.
  11. After resolving comments, check the related model elements, shop drawings, erection drawings, schedules, and exported data as applicable. A corrected drawing and an unchanged machine file can still create a failed handoff. Record the checks performed and identify any output that must be regenerated, rechecked, or held before the package moves forward.
  12. An effective request for information describes a specific issue and the decision needed to proceed. Identify the location, cite the conflicting or missing information, and explain the affected work. If you propose an option, label it as a proposal. Make the needed response date visible without pretending that a deadline resolves the underlying question.
  13. Imagine a fictional beam at grid C four. The schedule and a referenced detail show different elevations. The question should identify both documents and revisions, state the discrepancy, and ask which elevation controls. Include a marked view if helpful. Do not silently choose one value and let that assumption become shop data.
  14. A detailer may offer a practical option, but the proposal does not automatically become the project instruction. Record who responded, the response date, and the scope of the decision. If a response is unclear or introduces another conflict, seek clarification. Informal familiarity with the issue is not a substitute for a usable decision record.
  15. Closing a question means more than receiving an email. Identify the affected items, incorporate the decision, perform the required checks, and link the decision record to the revised output. If part of the work is already released, follow the project’s change and notification process. Preserve the evidence that the answer reached the downstream user.
  16. A revision is not just a newer file. It can change geometry, quantities, connections, finishes, dates, or dependencies. Preserve the prior baseline and compare the affected scope. Review the linked information and current release state. The most useful question is not only what changed, but who is relying on the information that changed.
  17. Suppose beam B twelve changes length after its shop drawing was reviewed. This example concerns information flow only; the engineering decision belongs to the responsible project team. First identify the source instruction, the member identity, the current document revision, and the work status. Has material been ordered, cut, fabricated, shipped, or installed?
  18. Trace the length change through the model, dimensioned drawing, bill of material, CNC output if used, erection information, and purchasing or shipping records as applicable. The connection geometry may also need review. Build an explicit affected item list rather than assuming a software update automatically reaches every issued file and every recipient.
  19. If affected information is already released, follow the established change process before new work proceeds on that basis. Identify obsolete outputs, communicate the scope of the change to the responsible recipients, and seek acknowledgment where required. A new file in a shared folder does not guarantee that a shop or field crew received it.
  20. The required response depends on the actual work status. Material not yet processed raises different questions from a fabricated or installed member. Document the status and route the issue to the responsible parties. Do not turn an information workflow into an improvised repair instruction. Any physical modification must follow the applicable technical and project authorization process.
  21. For the fictional B twelve change, closure includes the source decision, affected item list, revised outputs, checks, recipient notifications, and the final disposition of outstanding work. Keep the old baseline identifiable without letting it be mistaken for current instructions. This creates a history that another reviewer can follow without relying on someone’s memory.
  22. Partial releases can help a project schedule, but their boundaries must be clear. Identify the exact members, drawings, revisions, and work activities covered. State exclusions and unresolved interfaces. A release for one area does not automatically release an adjacent area or all related connection work. The authorized project process determines what may proceed.
  23. If an item is held, show the hold in the applicable register, documents, and output controls. State why it is held, who owns the next action, and what evidence will clear it. A vague note buried in one file may not reach the person preparing a cutting list or planning a delivery.
  24. Before issuing fabrication data, check the source revision, member identity, geometry, units, processing assumptions, and consistency with the checked documents. Confirm that the output format fits the receiving workflow. Software export success proves that a file was written, not that the file is correct for the intended machine or fabrication process.
  25. The shop and field need reliable links between physical pieces and their information. Use the project’s marking and identification procedures consistently. Material identification and full traceability are related but different requirements, so confirm what the contract calls for. Avoid casually renaming marks or merging records in a way that breaks the established links.
  26. A handoff manifest lists the files and revisions issued, the scope, the intended use, the change summary, and any outstanding restrictions. Identify the sender, receiver, and issue time. File checksums can support integrity checks when useful, but they do not replace review. The receiver still needs understandable instructions and a clear status.
  27. Start with a small set of controls that the team can maintain. Use consistent naming, a source register, a comment log, a release register, and a change impact record. Automate repetitive checks where practical, but make failures visible and assign an owner. The process should help people make decisions, not merely generate more files.
  28. Automation can compare identifiers, flag missing references, and check whether files share a revision. It cannot resolve an ambiguous design instruction simply by passing a script. Define what each check proves and what it does not. Keep a route for human review when source information is inconsistent, incomplete, or outside the programmed assumptions.
  29. Before the next issue, ask: is the source current for this scope? Are the documents and outputs coordinated? Are comments and questions resolved or visibly held? Is the permitted use clearly stated? And can the receiver identify what changed? If one answer is uncertain, record the issue and route it through the project process.
  30. After issue, retain the manifest, source baseline, decision links, review evidence, and release status in an organized record. Use searchable identifiers and avoid depending on a single person’s inbox. Good closeout does not stop at archiving files. It preserves enough context for the next question, revision, inspection, or project team member.
  31. A reliable handoff combines current inputs, visible responsibilities, coordinated outputs, and a documented decision path. Treat comments, questions, revisions, and releases as connected work. Explore the Quantum Steel Design learning hub for related steel detailing guides, and use the responsible project professionals and procedures to settle the actual requirements on your project.

Keep watching

More structural steel detailing and fabrication videos.

View the complete video library