Before a single product data sheet gets reviewed, somebody has to figure out what the project owes. On most jobs that means a project engineer sitting with a spec book several hundred pages long, reading every section for the word "submit" and its many disguises, and building the submittal log by hand—a tabulation of every shop drawing, product data sheet, sample, mock-up, and closeout submittal the contract requires, who owes it, and when. It is among the least automated processes in commercial construction, and it's worth examining why, because the reasons are about to stop holding.
What building a submittal log involves
The project manual organizes requirements by specification section, following the CSI MasterFormat numbering that the whole industry keys on. Within each section, the submittal requirements sit in Part 1, alongside quality assurance and delivery provisions, written however that particular spec writer chose to write them. One section says "Submit manufacturer's product data for each type of unit." Another buries a sample requirement in an execution paragraph. A third requires a mock-up only if the architect rejects the first sample, which is a conditional the log has to represent somehow.
Extracting all of that means reading every section completely, exercising judgment about what counts as a distinct deliverable, assigning each item to the responsible subcontractor, and recording the review path and turnaround. On a mid-sized commercial job the finished log easily runs to several hundred entries. Project engineers describe the work in the same terms they describe punch list data entry: days of concentration-intensive reading that produces a spreadsheet, followed by low-grade dread that something was missed—because a missed submittal surfaces months later as unapproved material showing up on site.
The log is only the beginning
Once built, the log becomes a correspondence instrument. Each entry has a lifecycle: requested from the sub, received, checked for completeness, forwarded to the architect or engineer of record, returned with an action, resubmitted if revised, closed. Somebody tracks ball-in-court for every open item, notices when a sub's shop drawings are three weeks late against a procurement deadline, and sends the reminder. The lifecycle work is clerical, continuous, and consequential, since late submittals turn into late material, and late material turns into schedule compression that everyone pays for.
The log also quietly doubles as the project's procurement early-warning system. Long-lead equipment can't be ordered until its submittal is approved, so the dates in the log are upstream of the dates in the schedule. A log that's incomplete or unchased doesn't just create paperwork risk; it hides the moment when an air handler's approval slipped past the point where the delivery date could still be saved.
Construction management platforms handle the record-keeping part of this respectably—a log in Procore is better than a log in Excel. What no mainstream tool has handled is the two ends of the process: producing the log from the spec book, and doing the chasing.
Why it stayed manual
The log-building step resisted automation for a defensible reason: it's a reading comprehension task, not a data extraction task. Spec books are long, inconsistent, and written in prose; the requirements are sometimes explicit, sometimes implied, and occasionally contradictory between Division 01 and the technical section. Software built on keyword matching produced logs that were worse than useless, because a log you can't trust still has to be rebuilt by hand, only now with an argument about it.
The judgment problem is real, but it's no longer disqualifying. Reading a 500-page document and reliably tabulating the obligations inside it is squarely the kind of work large language models have become good at—the same shift that made it possible to extract a consultant's observation report into structured records or read a certificate of insurance against a custom rubric. We've written about why this generation of AI succeeds where template-based automation failed; the spec book is close to the ideal case for it. The correct architecture is equally settled: the AI proposes the log, and a person who knows the job reviews and approves it before it becomes the project record, the same human-in-the-loop gate every Bex module enforces. An AI-drafted log that a project engineer verifies in an afternoon is a different economic object from a log that took the same engineer a week to write.
The chasing half needs no new science at all. Requesting documents from subs, evaluating what comes back, sending specific reminders to the silent, and escalating what needs judgment is the loop Bex Core already runs over email for insurance packets and punch assignments today.
On our roadmap, with your input
Bex does not have a submittals module today; this piece is a statement of intent, not a product page. Submittals sit on our roadmap because the two hard parts—comprehending messy documents at expert level and running patient correspondence loops with outside parties—are the two things our engine already does for a living. What moves an item up that roadmap is customers describing a concrete, costly version of the problem: how your logs get built now, how many entries, where the delays actually accumulate, what your architects require. If submittal management is the chore your team would pay to lose, tell us so, in whatever detail you can stand to type—and if your firm's need is immediate, custom development is a possibility worth discussing. The email address is below.