_YouTube Thumbnail (10)

The AI-Enabled Submittal Process for Architects Part 2: Submittal Review

How AI can organize the evidence while the architect keeps the decision

Submittal review is not difficult because of one isolated comparison. The burden comes from repeatedly moving between specifications, drawings, schedules, product data, review templates, prior decisions, and correspondence – often under tight deadlines and within a fee-compressed phase of the project.

In Part 1 of our AI-Enabled Submittal Process for Architects series, we showed how AI can support submittal intake: identifying the package, extracting metadata, checking administrative completeness, preparing a log entry, and routing the item for review. Part 2 begins after intake is complete and the package has been routed to the appropriate design-team reviewer.

The objective is not to have AI practice architecture or make the architect’s decision. It is to prepare and organize the evidence so the responsible professional can spend more time applying judgment – and less time searching, comparing, formatting, and drafting.

Breaking the process into manageable components

We divided the submittal process into three components:

  1. Submittal Intake
  2. Submittal Review
  3. Submittal Tracking and Resubmittals

Each component has different inputs, risks, outputs, and human decision points. Breaking the workflow apart makes it easier to test what AI can do, identify where it must stop, and convert a successful experiment into a repeatable firm process.

In Part 2, the simplified workflow is:

Routed for review -> Sources mapped -> Information compared -> Omissions checked -> Comments drafted -> Architect decides -> Response prepared

The four review documents

Our fictional door-hardware demonstration uses four documents:

  1. Door-hardware specification: Establishes the general requirements.
  2. Door Schedule: Identifies the project-specific conditions at each opening, such as fire rating, smoke control, and assigned hardware set.
  3. Contractor-reviewed submittal: Shows the products and hardware schedule being proposed.
  4. Blank review record: Provides the firm’s destination for findings, comments, and the architect-supplied disposition.

The relationship among the first three documents is especially important:

The specification gives us the rules, the Door Schedule tells us where those rules apply, and the submittal shows what the contractor is proposing.

Not every specification section has a corresponding schedule. Door hardware is a useful example because requirements frequently depend on the conditions at individual openings.

Building the review prompt by prompt

Before recording the demonstration, we broke the review process down and asked AI to help propose a sequence of prompts. We then ran those prompts repeatedly, examined the results, corrected problems, and refined the instructions.

The recorded demonstration shows the prepared prompt-and-response history rather than waiting for every Cowork task to run live. This keeps the episode focused on the workflow, results, and human controls.

The sequence asks AI to:

  1. Map each review criterion to its governing source.
  2. Compare the submitted products and scheduled openings with the cited requirements.
  3. Classify findings using neutral preliminary labels.
  4. Run a second pass for omissions and cross-document conflicts.
  5. Draft concise, cited review comments.
  6. Recommend – but not decide – a disposition.
  7. Apply the architect-supplied decision to draft deliverables.
  8. Package the tested process as a reusable skill.

The preliminary labels used in the demonstration are:

  • Appears Consistent
  • Variance
  • Needs Clarification
  • Not Submitted

These labels help AI organize the comparison without prematurely declaring that a product is approved, rejected, or acceptable.

Why a second pass matters

The first comparison identifies visible differences between the submitted products and the project requirements. The second pass asks AI to look specifically for omissions and conflicts across the documents.

In our fictional demonstration, the review surfaced issues such as:

  • A Grade 2 lockset where the specification calls for Grade 1.
  • Submitted finishes that differ from the specified finish.
  • Missing fire-door listing information for a closer at a rated opening.
  • No submitted smoke-seal product for a smoke-control opening.
  • Preliminary functions and quantities that still require clarification.

A critical instruction in this step is:

Add only evidence-supported findings.

AI systems are designed to be helpful, but that helpfulness can become a liability when the model fills gaps with unsupported assumptions. Requiring citations and separating missing information from documented facts makes the result easier for the architect to verify.

Preserving the architect’s decision

After the comparison, omission check, and draft comments are complete, AI may recommend a preliminary disposition. In the demonstration, the recommendation is Revise and Resubmit.

That recommendation is not the project decision.

The architect or authorized reviewer must still determine:

  • Whether each variance is material.
  • Whether an alternate product or finish may be acceptable under the project requirements.
  • Whether clarification is sufficient or a corrected submission is required.
  • Whether consultant coordination is needed.
  • The final comment language and disposition.
  • Whether the response is ready to be stamped, issued, and entered into the project record.

For the controlled demonstration, the human-supplied decision is Revise and Resubmit. Cowork is then instructed to produce two separate drafts:

  1. A completed draft review record.
  2. A draft response or resubmittal request summarizing the required corrections.

Nothing is automatically stamped, issued, logged, or sent. This is the central control:

AI organizes, compares, cites, drafts, and recommends. The architect decides.

The imperfect result is part of the lesson

The demonstration also includes two useful examples of why these workflows must be tested.

During one step, Cowork treated the previous task as complete and temporarily stopped using the attached documents. The next instruction had to explicitly tell it to proceed with the same sources.

Later, Cowork created the completed review record but failed to create the separate resubmittal request. We corrected the instruction to require two specifically named deliverables and asked Cowork to display the draft communication in the task.

These are not reasons to abandon the workflow. They are exactly why a firm should develop it prompt by prompt before turning it into a reusable skill. Every failure reveals an instruction, output requirement, or human gate that should be preserved in the final process.

From a successful prompt sequence to a firm skill

A long prompt history is useful while designing the workflow, but it is not how most employees should use it every day.

Once the sequence produced a satisfactory result, we asked Cowork to package the process as a reusable Submittal Review skill. The skill preserves:

  • Required source documents.
  • Source-mapping and citation rules.
  • Preliminary review labels.
  • The separate omission check.
  • Draft-comment requirements.
  • Human gates before disposition and file creation.
  • The requirement to preserve blank templates.
  • The boundary that AI never approves, stamps, issues, logs, or sends the response.

The skill can then be tested in a clean task, shared with an approved pilot team, measured, and improved as real project exceptions appear.

The potential operational value

Our target across the complete intake, review, and tracking workflow is to return approximately one staff hour per submittal event. That is a pilot target – not a universal industry benchmark – and every firm should measure its own baseline and results.

For a firm processing approximately 50 submittal events per month, one hour per event would represent about 50 hours of regained monthly capacity across project architects, technical reviewers, project managers, and construction-administration staff.

The goal is not to remove a position. It is to give each person back time currently spent on repetitive handling so they can focus on coordination, professional judgment, client service, and project delivery.

Where Part 3 begins

Part 2 ends with a draft review package ready for the architect’s verification and official action.

Part 3 begins after the architect approves and issues the response:

Review issued -> Log updated -> Contractor revises -> Resubmittal received -> Changes compared -> Item closed or repeated

In the final episode, we will show how AI can support status updates, deadlines, ball-in-court tracking, version history, resubmittal comparisons, unresolved-comment detection, and project-record continuity.

The larger lesson is transferable well beyond submittals:

Break down the manual process, build and test the prompts, preserve the human decisions, and package what works into a reusable firm workflow.

If you have questions or need help please reach out to us.   

ArchIT specializes in providing IT services for architecture, design, and engineering firms