Submittal review preparation: check the package against the spec before the engineer opens it

Autodesk's Submittals overview 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.

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.

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 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.

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.

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.

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.

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.