# Submittal review preparation: check the package against the spec before the engineer opens it > A proposed submittal workflow: confirmed spec checklists, sourced completeness findings, original files intact and engineering judgment kept with reviewers. Canonical URL: https://techtideai.io/blog/engineering-submittal-review-preparation Markdown URL: https://techtideai.io/blog/engineering-submittal-review-preparation.md Publisher: TechTide AI, Columbus, Ohio (https://techtideai.io) Author: Alex Cinovoj, Founder & CTO, TechTide AI ยท CTO & Co-Founder, CPG Playbook Type: Field Note Published: 2026-10-29 Collection: August 2026 editorial collection (a label, not the publication date) Reading time: 4 min Topics: submittal review process, construction submittal automation, specification checklist, engineering review Site index: https://techtideai.io/llms.txt Offer summary: https://techtideai.io/offers.md --- A contractor uploads a submittal package for a pump. The engineer opens it, scrolls through product data, and discovers that the performance curve is for a different model, the motor data sheet is missing, and the package references an old revision of the specification section. The review stops before it starts, the submittal goes back, and the schedule loses a cycle. Much of that lost time comes from completeness problems that could have been caught before the engineer looked. Preparing a submittal for review is a good place for assisted checking: comparing what was submitted with what the specification asks for, and making the gaps visible. The engineering review itself, and any approval or stamp, stays with the qualified reviewer. This is a proposed workflow. Specification formats, contract requirements and review responsibilities vary by project, and the project's own documents and contract define what a submittal must contain. ## Understand the formal process you are supporting Autodesk's [Submittals overview](https://help.autodesk.com/cloudhelp/ENU/Build-Submittals/files/getting%5Fstarted%5Fsubmittals/Submittals%5FOverview.html) describes submittals as a formal process for submitting documents, materials and equipment for approval by architects, engineers, clients or other stakeholders. Its Forma Build tool organizes submittals by spec section and package, supports review templates with required and optional reviewers, and logs submittal activity. Whatever platform a project uses, the workflow I describe sits in front of the formal review. It prepares information for the submittal manager and reviewers. It does not change review assignments, responses or the official record. ## Turn the spec section into a checklist Each specification section usually lists what must be submitted: product data, shop drawings, samples, certificates, calculations or warranties. The first step is to turn those requirements into a structured checklist for the section, with each item quoted from the specification and linked to its paragraph. A model can help draft that checklist from the specification text, but a person on the design team should confirm it once per section. That confirmed checklist becomes the reference for every submittal against that section, and it should record the specification revision it came from. ## Compare the package against the checklist When a package arrives, the workflow can classify each attachment, match it to checklist items, and list what appears to be missing. It can also check simple consistency: whether the model numbers in the cover sheet match the product data, whether the referenced specification revision is current, and whether required certifications are present. Every finding should point to the document and page that supports it. "Motor data sheet not found" is useful only if the reviewer can quickly confirm it is genuinely absent rather than buried in a combined PDF. Findings are questions for the submittal manager, not rejections. Autodesk's documentation on [submittal attachments](https://help.autodesk.com/cloudhelp/ENU/Build-Submittals/files/work-submittals/Submittal_Attachments.html) distinguishes submission, for-review, review-response and final-response attachments, and notes that adding a file from the project's files creates a copy in the submittal while the original stays unchanged. The preparation step should respect those distinctions and never modify the contractor's submitted files. ## Keep technical judgment with the reviewer Some questions look like completeness checks and are actually engineering judgments. Whether a proposed substitute is equivalent, whether a performance curve meets the duty point under the project's conditions, or whether a deviation is acceptable are decisions for the qualified reviewer. The workflow can surface relevant facts for those decisions, such as the specified duty point next to the submitted curve, but it should label them as information, not conclusions. I would not have it suggest a review response such as approved or revise and resubmit. That response carries professional and contractual weight. ## Decide what happens with an incomplete package Projects handle incomplete submittals differently. Some return them immediately; others review what is there and note what is missing. The workflow should support the project's chosen practice, which means the submittal manager decides whether to forward the package, return it, or request specific items, using the findings as input. If the project returns packages for completeness, a clear list of missing items with specification references makes the return faster and less contentious. The contractor can see exactly what is required and where the requirement comes from. ## Protect project documents Specifications, drawings and submittals are project documents with their own access rules. The preparation step should run inside the project's approved environment and only see documents for that project. If a model service is involved, confirm the project's data terms allow it before any documents are sent. ## Measure whether it helps reviewers In a pilot, compare the workflow's findings with what reviewers actually noted on the same packages. Track missing items it caught, missing items it missed, and false findings reviewers had to dismiss. Ask reviewers whether the findings saved them time or added noise. The acceptance condition I would agree: for the pilot spec sections, the confirmed checklist matches the specification, every finding links to its source, false findings stay rare enough that reviewers keep reading them, and nothing in the formal review record is changed by the workflow. Bring a few past submittals, their specification sections and the review comments they received. [Send the project brief](https://techtideai.io/contact). ## Sources - [Submittals overview](https://help.autodesk.com/cloudhelp/ENU/Build-Submittals/files/getting%5Fstarted%5Fsubmittals/Submittals%5FOverview.html) - [submittal attachments](https://help.autodesk.com/cloudhelp/ENU/Build-Submittals/files/work-submittals/Submittal_Attachments.html) ## Related Field Notes - [Engineering document transmittals: reconcile versions before distribution](https://techtideai.io/blog/engineering-transmittal-reconciliation) ([Markdown](https://techtideai.io/blog/engineering-transmittal-reconciliation.md)): A proposed transmittal workflow that reconciles documents, revisions, approvals and recipients into a reviewable packet before distribution. - [Engineering review comments: cluster duplicates without closing decisions](https://techtideai.io/blog/engineering-review-comment-triage) ([Markdown](https://techtideai.io/blog/engineering-review-comment-triage.md)): A proposed review-comment workflow that suggests duplicate groups while keeping every original comment, its revision and an authorized closure decision. - [Construction RFI automation: turn field questions into reviewable requests](https://techtideai.io/blog/construction-rfi-intake-automation) ([Markdown](https://techtideai.io/blog/construction-rfi-intake-automation.md)): A proposed RFI intake workflow that preserves drawing references, routes questions, and keeps contractual decisions with authorized reviewers. - [Building asset handover: check equipment data before the facility team accepts it](https://techtideai.io/blog/building-asset-handover-data-review) ([Markdown](https://techtideai.io/blog/building-asset-handover-data-review.md)): A proposed handover workflow using a COBie-style structure: data needs per asset type, schedule matching, sourced attributes and owner-recorded acceptance. All Field Notes: https://techtideai.io/blog