Compares the vendor's submittal text against the controlling spec section and produces a numbered findings list. Each finding has a severity tag (Critical / Major / Minor / Info), a side-by-side quote pair (spec text vs submittal text), a category (substitution, omitted requirement, conflicting standard, etc.), and a recommended action. Composes an overall review_result — Approved, Approved as Noted, Revise and Resubmit, or Rejected — and persists the findings onto submittal_revisions so the tracker shows the decision history.
Submittals fail in predictable ways. A sub proposes a manufacturer not on the approved-equal list. The data sheet shows a smaller motor than the spec'd horsepower. A finish color is two shades off from the spec'd RAL number. Most of these slip past reviewers because a single sub may submit 40 pages and the reviewer has 30 other submittals waiting. Submittal Reviewer reads the whole package, compares it line-by-line to the controlling spec, and produces the numbered list of every deviation.
Hard violation of a numeric spec requirement. The sub must revise the submittal or formally request a substitution per spec 01 25 00. Engine output: severity Critical, recommended action "Revise and Resubmit."
Sub proposes Carrier 50TC where spec basis-of-design is Trane and approved equals are York / Daikin. Substitution may be acceptable on equipment match, but the request requires architect approval per spec 01 25 00. Engine output: severity Major, recommended action "Approve as Noted — submit substitution form 1.5."
Inside the spec'd tolerance band but worth flagging for the PM to confirm photometric performance still meets the LDRA targets. Engine output: severity Minor, recommended action "Approve as Noted — verify photometric report."
Manufacturer's data sheet doesn't state warranty period. Spec 23 09 00 requires 5-year compressor warranty. Not a violation — possibly an omission on the sub's part. Engine output: severity Info, recommended action "Approve as Noted — submittal must include warranty letter."
The reviewer is meant to run before the formal submittal review — it pre-flights the package, surfaces the deviations the sub should fix, and lets the GC kick obvious problems back to the sub instead of consuming the architect's review window.
v1 is text-only — pasted text or PDF extract. v2 (post-PDF sidecar) adds drawing-bbox pin overlays on shop drawings.
The controlling spec section (CSI MasterFormat). PDF extracted to text or pasted directly. Multi-section comparison is supported — e.g., 23 09 00 + 23 09 23.3 for a controls submittal.
Shop drawing notes, product data, manufacturer cut sheets, sample descriptions. PDF text extract or paste. The engine handles equipment schedules and tabular data in the cut sheets.
Approved-equal lists from prior submittals on this project, the substitution-request log, contract general conditions, prior architect responses. The engine uses these to predict the likely approval result and calibrate severity.
Sample review for a packaged rooftop unit submittal against spec 23 73 13:
One of four standard stamps composed by the engine based on the finding mix. Approved = no findings above Minor. Approved as Noted = no Critical, ≤3 Major needing acknowledgment. Revise and Resubmit = ≥1 Critical or >3 Major. Rejected = irreconcilable substitution or wholesale spec violation. The PM stamps the actual decision — the engine just suggests the starting point with the math behind it.
Submittal Reviewer is a hub in the field-phase chain. The findings drive the submittal tracker, the RFI drafter, and the change-order engine all at once.
v1 is text-based. Native PDFs with extractable text parse cleanly. Scanned PDFs flow through OCR with a slight accuracy hit and a confidence flag per finding. Equipment schedules and tabular cut sheets are recognized as tables. Pasted text from email or a spec viewer works the same way. v2 (shipping when the PDF sidecar lands) adds drawing-bbox pin overlays that point to the exact spot on a shop drawing where a finding lives.
It learns. The first time a substitution request goes through on a project, the engine doesn't know whether this architect tends to approve Daikin-for-Trane. After 4–6 closed substitution requests, the empirical approval rate per manufacturer pair becomes part of the recommendation. Pre-empirical, severity defaults to Major for any off-list manufacturer.
Ambiguity is itself a finding. If the spec is silent on a parameter the submittal addresses (e.g., refrigerant type isn't specified, sub picks R-32), the engine surfaces this as an Info finding noting the spec gap. The PM decides whether to accept the sub's choice or RFI the architect for clarification — either way, the gap is captured in the audit trail.
The full package parses against each controlling spec section. Each section's findings get their own numbered series (F1–F5 for spec 23 09 00, then F1–F3 for 23 09 23.3, etc.). The overall review_result is composed from the worst severity across all sections. Typical 200-page submittal processes in under 60 seconds.
Yes — the engine works the same for subs reviewing their own submittal before sending to the GC. Pro plan covers both roles. Subs typically use it to catch their own deviations before formal submission, which reduces rejected resubmittals.
Yes. For every Critical or Major finding, the engine drafts a one-sentence note in PM voice: "Provide cooling capacity of 30 tons nominal at 95/78 design conditions per spec 23 73 13 §2.3.A." The PM edits or approves; the notes auto-attach to the submittal's return stamp. The sub gets a single document with every issue listed and citable.
Bring one real submittal and the spec section it's against to a 15-minute call. We'll run the review on screen, walk the findings, and you keep the output with the recommended notes to sub.
Start free — 14 days, no card →