AI that answers construction RFIs from the documents you already have

An RFI is a question with a clock on it. The field hits a conflict, writes it up, and the answer is usually sitting in a spec section or a detail that nobody can lay hands on fast enough. So the question parks in a reviewer’s inbox, the ball-in-court count ticks up, and a crew burns float on the critical path while it waits. The average RFI takes about eight days to answer in the US, and more than a fifth never get answered at all.^[1] That is a long time to wait for an answer the project already had.

The volume is the part that surprises people. A single PlanGrid analysis put it near 800 RFIs on a typical project, roughly ten for every million dollars of contract value.^[1] A broader study across 1,362 projects counted something like 1.08 million RFIs in total.^[2] Plenty of those are real conflicts that need a designer’s call. Plenty more are the field asking about something the drawings and specs already cover, because writing an RFI is faster than digging through six PDFs to find the answer yourself. Brad’s job is to make digging faster than asking.

Brad reads the RFI and pulls the documents that answer it

An RFI lands however it lands: forwarded by email, texted up from the field, or stuck to a photo of the conflict. Brad reads it the way a construction administrator would and works out what is actually being asked. A dimension that does not close. A finish where the plans and the spec disagree. A detail that is simply missing at a condition the field has already framed up to.

Then it goes and gets the answer. Brad pulls the governing CSI MasterFormat spec section, the relevant detail at its current revision, the latest plan, and any earlier RFI or ASI that already grazed the same question, and lays them next to the RFI. The reviewer sees the question and its source material side by side, instead of reopening six PDFs to rebuild context they had two weeks ago. Waiting on an answer the project already holds is non-value-adding work in the lean sense, and it is exactly the kind of waiting Brad is built to remove.^[3]

A drafted answer, with the governing spec or detail attached

Brad surfaces a draft response and shows its receipts. Spec 09 91 23, 2.2.B. Detail 5/A-502, Rev C. The citation sits in the margin, so the reviewer is checking a sourced answer rather than starting from a blank box at the end of a long day. When the documents genuinely disagree, Brad does not paper over it with a confident guess. It flags the conflict and points at both sources, because a discrepancy between the drawings and the spec is a human’s call to make.

A superintendent or architect stays on every reply. Brad handles the retrieval and the first draft; the answer that goes back to the field is signed off by someone who owns it, now backed by the exact citation and ready to stand behind the next time the question comes around. It tends to come around. The contract defines the formal RFI process, and Brad works inside it rather than around it.^[4]

Every open RFI, and who it’s waiting on

RFIs fall through the cracks because nobody sees the whole stack at once. Brad keeps a live ball-in-court log: which RFIs are open, which are answered, which are aging past their response window, and the part that actually moves dirt, who each one is waiting on. An RFI parked on the architect’s desk is a different animal from one waiting on a field measurement, and the difference decides what you chase today.

Ask in plain language. “What RFIs are holding up the framing inspection?” “What’s still open on the curtain wall?” You get the list back with status and a source for each, over the same email and text threads your team already uses. There is no new dashboard to log into, and no Monday status meeting spent assembling the list by hand. Given that crews already lose hours every week looking for project data, an RFI log that assembles itself is time the schedule gets back.^[5]

Each RFI linked to the spec it questions and the change it triggers

An RFI rarely ends at the answer. The question points backward at a spec or a detail, and the answer sometimes points forward at a change order. Brad keeps both threads tied: the RFI to the spec section or drawing it questions, and, when the answer moves scope, to the change order or CCD that falls out of it.

That thread is what saves you six months later, once memory has gone soft and the paperwork is all you have. Someone asks why a detail got built the way it did, or whether the added cost was ever authorized, and the RFI, its cited answer, and the change it triggered are already sitting together. No archaeology through old inboxes. The record assembles itself while the work happens, instead of getting reconstructed under deadline at closeout. It also matters when things turn adversarial: the most common cause of construction disputes is a party failing to understand or comply with its contract obligations, and a sourced, dated RFI trail is the difference between a defensible timeline and a room full of people saying they think it was around April.^[6]

Where Brad stops and the licensed reviewer starts

Brad is document intelligence pointed at construction RFIs. It reads, connects, and drafts from your project’s documents and messages, and it answers with the source attached. What it is not: a stand-in for a licensed reviewer’s judgment, your contract’s formal RFI process, or the design authority that owns the answer of record. A person approves everything that goes back to the field. Your project’s content stays yours, and each workspace is walled off from every other one. If you have specific requirements about how RFI data gets handled or retained, ask us and we will walk you through exactly how it works.

You will not stop the field from asking. You can change how fast the project answers, and whether the answer arrives with its source attached or as one more guess waiting on someone’s memory. An RFI is a question with a clock on it. Brad is how the clock stops working against you.