Search submittals by what they cover, not by log number

A submittal exists to prove one product meets one part of the specification. That is the whole job. The submittal log most teams keep does not track that. It tracks numbers and dates: submittal 08 80 00-001 logged on the third, returned on the eleventh, approved-as-noted. Useful for an audit, useless when the superintendent is standing at the curtain wall asking whether the glass on the truck is the glass that got approved. The number tells you something happened. It does not tell you what the product is, which CSI MasterFormat section governs it, or whether a later addendum moved the requirement out from under an approval nobody re-checked.

That gap is not a paperwork nuisance. Construction loses roughly $1.85 trillion a year to bad data and the rework it causes, and a submittal approved against the wrong revision is exactly that kind of error: a small data mismatch that ends up as material on a truck or fastened to a wall.^[1] Brad reads the submittals and the spec sections they answer to, then lets your team search by what a submittal covers, see where the gaps are, and track the log without rebuilding it by hand every week.

Search by what it covers, not by what it was numbered

Forward Brad the submittals as they come in: product data, shop drawings, samples, manufacturer cut sheets, the lot. Brad reads each one and works out what it actually is, the way a project engineer would. Then you ask in plain language. “Did we submit the TPO roofing yet?” “What gauge is the approved metal stud?” “Which manufacturer got approved for the storefront?” You get the submittal itself back, with the page and the line the answer sits on, not a row in a spreadsheet that may or may not have the description column filled in.

Your PM, your superintendent, and the architect all read the same record. Nobody has to carry a log number in their head to find the thing. They search the way they would describe it standing in the field, which is the only way anybody actually thinks about a product. Searching for the right document is a large, unglamorous part of where the week goes on a job site, and a submittal search that answers in the language of the work, not the language of the log, is time the project keeps.^[2]

Each submittal tied to the spec section that governs it

Brad reads the specifications too, so it knows a waterproofing submittal answers to 07 13 00 and a glazing package answers to 08 80 00. Ask what a submittal is supposed to satisfy and Brad sets the governing CSI section next to the submitted product, both with their sources showing. The reviewer is comparing the right two things instead of holding the requirement in memory while flipping through a cut sheet.

That side by side is where the expensive gaps hide. A product that looks fine on its own data sheet but does not meet the section it was submitted against. A fire rating that is one line short. A fastener pattern that reads close enough until you set it beside the detail. Brad puts the two together so a mismatch gets caught at review, when the fix is a phone call, rather than after the material is on a truck, when the fix is a change order and a delay. The contract defines the formal submittal process, and Brad works inside it: the reviewer still owns the stamp, with the comparison already laid out.^[3]

Open, approved, revise-and-resubmit, tracked across the package

Brad tracks where each submittal stands and which spec it answers to, so “what is still open on the curtain wall?” is one question and not an afternoon cross-checking the log against the architect’s returns. Approved, rejected, revise-and-resubmit, approved-as-noted: Brad reads the status off the document that says so and shows you that source, rather than asking you to trust a status someone typed into a cell three weeks ago and may not have touched since.

When the superintendent is about to install, that is the question that actually decides things. Not whether something was submitted, but whether the approved version is the one showing up on the truck. Brad keeps the status and the governing section in one place so a superseded sample does not quietly get built into the wall, and so the answer the field gets back carries its source. There is no separate submittal dashboard to log into and no weekly status meeting spent assembling the list by hand. The log assembles itself while the work happens.

When a revision moves the governing spec, Brad flags it

Specs move. An addendum or a revised section can change a fastener pattern, a fire rating, or an approved manufacturer, and a submittal approved against Rev B may no longer match Rev C. Most teams never connect the two events, because the approval lives in the submittal log and the change lives in an addendum email, and nothing puts them on the same page. Brad reads the revisions and flags when the spec that governs an already-approved submittal has shifted under it.

It points you at what changed and which submittals it touches, both versions cited, and then it stops. You decide whether to re-review. Brad’s job is making sure you know a decision is sitting there waiting, instead of finding it at the inspection. This is the cheap-to-fix end of the curve: a flagged mismatch caught at review costs a re-submittal, while the same mismatch caught at install costs rework, and the ability to absorb a change for almost nothing drops fast as the work moves downstream.^[4]

Where Brad stops and your review process takes over

Brad is document intelligence pointed at construction submittals. It reads, connects, surfaces the gap, and answers with the source attached. What it is not: a code official, an approval authority, or a promise that a product meets a spec. The architect of record and your review process own that call, as they should. Brad puts the submittal, its status, and the governing spec section in front of the right person, with citations, so the decision gets made on the full picture instead of a half-remembered email from last month. A clean trail of which submittal answered which section, approved against which revision, is also what defends you later: the leading cause of construction disputes is a party failing to understand or comply with its contract obligations, and a sourced, dated submittal record is the difference between a defensible position and a room full of people guessing at dates.^[5]

Your project’s content belongs to you, and each workspace stays walled off from every other one. If you have specific requirements about how your submittal and spec data are handled or retained, ask us and we will walk you through exactly how it works.

You will not stop specs from moving or submittals from piling up. You can change whether the right product, the governing section, and the current status arrive together with their sources attached, or stay scattered across a log, an inbox, and someone’s memory until the inspection forces the question. A submittal is a small promise that a product meets a requirement. Brad is how you keep that promise findable, current, and provable.