This is where the program stops talking about AI and starts doing the work. You have the scaffold, you have few-shot, you have detection; now you point all three at the single most common document a project engineer produces, the RFI, and you do it on a real drawing conflict from origin to logged-and-verified. By the end of this lesson you will have a repeatable workflow that turns a clash you spotted on two sheets into a spec-cited, contract-aware RFI in a fraction of the time it used to take, with every fact verified and the right notice clause confirmed. This is the lesson where the hours start coming back, and where the discipline from Level 1 stops being theory and becomes the thing that keeps your faster RFI from becoming a faster mistake.

Why the RFI Is the Perfect First Target

The RFI is the ideal place to start applying AI for hands-on work, and it is worth understanding why, because the reasons generalize to every other document. First, it is high-volume: a project engineer writes dozens of them, so any per-RFI time saving compounds fast. Second, it is largely language work wrapped around a few hard facts, the sheet numbers, the spec sections, the conflict description, which is exactly the shape AI handles well with a verification gate on the facts. Third, it lives inside the contract, with notice and claim implications that make the verification truly matter, so it exercises the full discipline rather than letting you get lazy. The RFI is high-reward and high-stakes at once, which makes it the perfect proving ground for the workflow you will reuse everywhere.

You can run this with a general chat AI or with an in-platform assistant like Procore Assist, and the choice mostly affects convenience and data handling rather than the workflow itself. The in-platform assistant has the advantage of living where your RFI log already is and respecting your project's data boundary, which matters per the confidentiality lesson. Whichever tool you use, the workflow is the same five moves, and the tool is just where you run them. The skill is the workflow, not the tool, which is why this lesson teaches the moves rather than a specific product's buttons.

The Five-Move RFI Workflow

Here is the workflow end to end, built from everything the prior lessons gave you. Move one is capture the conflict precisely. You spotted that sheet S-201 shows a structural beam at an elevation where sheet M-401 routes a main duct, a hard conflict. You write down the facts you actually know: the two sheet numbers, their revisions, the specific location, and the nature of the clash. These are the hard facts the AI must not invent, so you gather them first and feed them in, rather than hoping the model knows them.

Move two is the scaffolded, few-shot prompt. You give the model the role (a PE drafting a formal RFI), the context (the conflict with the real sheet numbers and revisions you captured), the standard (your project's RFI template plus the instruction to cite only references you provided), the format (your RFI structure), and the verification instruction (invent no sheet numbers, dimensions, or spec sections; mark anything missing as a bracketed placeholder). You include two or three of your firm's past RFIs as few-shot examples so it matches your house style and citation format. Move three is generate and read for defects. The model produces a draft; you run the reference pass, checking every sheet number and any spec section against the actual documents, and you confirm the draft addresses this specific conflict rather than drifting generic.

Move four is the contract verification, which is the move that separates a professional RFI from a generated one, and it gets its own section below. Move five is log it with a cycle-day timer. You enter the verified RFI into your RFI log and start the clock, because an RFI's value depends on tracking how long it sits open, and the cycle-day metric is what surfaces the ones aging toward a problem. The AI accelerated moves one through three; moves four and five are where your professional ownership lives, and the workflow makes both fast and non-skippable.

The AI accelerates capture, drafting, and the first read. The contract verification and the logging are where your professional ownership lives. The workflow makes the fast part fast and the ownership part non-skippable.

The Contract Verification: Getting the Notice Clause Right

An RFI is not just a question; it can carry notice and timing implications, and this is exactly where AI gets the contract wrong, so move four is the one you never delegate. From the Level 1 A201 lesson you know the specific trap: the model conflates the three clauses that govern different timing rules. It will attach a deadline to the RFI obligation that does not exist, or cite the wrong section for the timing that applies. So when your RFI touches notice, you verify the contract references yourself against your executed agreement, not the model's memory.

Concretely, you keep the distinctions straight that the model blurs. A201 Section 3.2.4 concerns the Contractor's duty to review the contract documents and report discovered errors, where the RFI obligation broadly sits, and it carries no fixed-day window. A201 Section 15.1.3.1 is the actual twenty-one-day Notice of Claims provision. A201 Section 3.7.4 governs concealed or unknown conditions with a fourteen-day notice in the 2017 edition. If your clash is a design conflict surfaced by an RFI, the relevant obligation and any downstream claim notice are governed by the real clauses in your contract, which may modify these A201 defaults, so you confirm which clause actually applies and what its real deadline is against your executed agreement. The discipline from the contract lesson is decide-then-draft: you make the contractual determination of what notice, if any, this RFI implicates, and the AI only renders the language; it never decides the clause or the deadline. The RFI that goes out cites real sheets, governs under the right clause, and respects the real window, because you verified all three, and that verified RFI both moves the work and protects the position.

The Cycle-Day Discipline and Why Speed Changes the Game

The fifth move, logging with a cycle-day timer, deserves attention because AI changes the economics of RFI management in a way that is easy to miss. When RFIs were slow to write, the bottleneck was authoring; now that the authoring is fast, the bottleneck moves to tracking and closing, the cycle days, the duplicates, the ones aging past their notice window. So the professional who masters AI-assisted RFIs does not just write them faster; they shift their attention to the part that now matters more, which is managing the log, and we devote later lessons to the full RFI lifecycle and the cycle-day, RFI-to-change-order, and duplicate-detection metrics.

For now, the discipline is simple and important: every RFI you generate gets logged immediately with its open date, so the cycle-day clock is running from the start. This matters because a fast-written RFI that sits unlogged is worse than a slow one that was tracked, since the value of an RFI is not just in asking the question but in getting it answered before it blocks the work or breaches a window, and you cannot manage what you do not track. AI lets you produce the RFI in minutes; the cycle-day log is what ensures those minutes saved translate into a question actually answered on time rather than a faster way to generate paper that ages in a backlog. Speed on the front end only pays off if the back end, tracking and closing, keeps up, which is why the workflow ends at the log and not at the draft.

What Makes a Good RFI Question, and Why AI Can Hurt Here

There is a craft to the RFI question itself that deserves attention, because AI can quietly degrade it in a way that costs you. A good RFI asks one clear, answerable question and proposes a resolution, so the designer can respond with a simple confirmation or correction rather than having to untangle what you are even asking. A vague RFI, "please advise on the conflict at gridline C," forces the designer to do interpretive work, slows the response, and often produces an answer that does not actually resolve the build. The best RFIs do the design team's thinking for them: here is the conflict, here is what I propose, please confirm or direct otherwise.

AI can hurt here because, left to its defaults, it tends toward thorough, hedged, comprehensive language, the opposite of the crisp single question that gets a fast answer. A model asked to draft an RFI will happily produce three paragraphs that restate the whole situation and ask several questions at once, which reads impressively and performs poorly, because it gives the designer more to wade through and more ways to answer incompletely. So part of your prompt, and part of your detection read, is enforcing the discipline of the good RFI: one clear question, a proposed resolution, the minimum context needed to answer. You instruct the model toward that shape and you check that it delivered it, trimming the hedged comprehensiveness back to the sharp question. The AI gives you the draft fast; you supply the editorial judgment that makes it a good RFI rather than a long one, and that judgment is a real part of the value you add that the model cannot.

The Duplicate Check Before You Send

One more move belongs in the workflow as it matures, and it is worth introducing now because AI makes it both more necessary and easier: checking whether the RFI you are about to send was already asked and answered. When authoring is fast and a team is generating RFIs quickly, the risk of duplicates rises, the same slab-edge question asked by two engineers, or a conflict the designer already resolved in a different RFI thread that nobody cross-linked. A duplicate RFI wastes the design team's time, clutters the log, and makes your team look disorganized, and the irony is that the speed AI gives you can increase duplicates if you do not add the check.

The check is simple: before logging a new RFI, scan the open and closed RFI log for the same question, which AI can actually help with by comparing your draft against the log entries and flagging likely matches for you to confirm. This is pattern detection, the kind of work AI is truly good at, surfacing candidates for a human to verify, and it pairs naturally with the cycle-day log because both live in the RFI log. We develop the full duplicate-detection and log-hygiene workflow in a later lifecycle lesson, but the habit starts here: a fast RFI workflow includes a fast duplicate check, so the speed produces answered questions rather than a growing pile of redundant ones. The discipline is that you never send an RFI without a glance at whether it was already asked, and AI makes that glance fast enough that there is no excuse to skip it.

The Applied Problem: Run a Real Clash End to End

Here is the exercise that makes the workflow yours. Take a real or representative clash from your project, a genuine structural-MEP conflict with actual sheet numbers, and run the full five-move workflow on it. Capture the facts, build the scaffolded few-shot prompt with your template and examples, generate the draft, run the reference pass, verify the contract references against your prime contract and the correct A201 section, and log it with a cycle-day timer. Produce the actual RFI in your project's actual template, not a generic one.

As you go, document two things that prove the workflow worked. First, the verification record: which facts you checked and against what, the sheet numbers against the drawings, the spec section against the spec, the notice clause against the contract, so you have evidence the gate was passed. Second, the time comparison: roughly how long this took versus how long the same RFI would have taken you to write from scratch, because that delta is the recovered hours made concrete, and seeing it is what converts the workflow from an exercise into a habit. Be honest about both, because an RFI that was fast but unverified is not a win, and a verified RFI that took longer than hand-writing is a workflow you need to streamline.

The deliverable is one real, verified, logged RFI plus the verification record and the time comparison, and the lasting product is a workflow you can run on every RFI from now on, with the prompt and examples saved so the next one is faster still. This is the first hands-on skill of the level, and it is the template for all the others: capture the facts, brief the model with scaffold and examples, generate, detect, verify the high-stakes specifics against the source, and log. Every document lesson that follows is a variation on these five moves, which is why getting them solid on the RFI, the document you write most, is the foundation of becoming truly AI-assisted rather than merely AI-curious. Run it ten times on real RFIs and the five moves stop being a checklist you consult and become the way you simply work, which is the point at which the recovered hours become permanent and the verification becomes automatic rather than effortful. The first few runs feel slower than just typing the RFI because the workflow is new, and then a switch flips, the capture and the prompt become muscle memory, the reference pass takes seconds, and you are producing better RFIs in less time than you ever did by hand, with a verification record that hand-writing never gave you.

Key Takeaways

• The RFI is the perfect first hands-on target: high-volume so savings compound, mostly language wrapped around a few hard facts AI handles well with a gate, and contract-bound so it exercises the full verification discipline rather than letting you get lazy.
• The workflow is five moves: capture the conflict precisely, build a scaffolded few-shot prompt with your template and examples, generate and read for defects, verify the contract references, and log with a cycle-day timer. The tool (chat AI or Procore Assist) is just where you run them.
• The AI accelerates capture, drafting, and the first read; the contract verification and the logging are where your professional ownership lives, and the workflow makes the fast part fast and the ownership part non-skippable.
• Move four, the contract verification, is never delegated. The model conflates A201 3.2.4 (RFI/review duty, no fixed window), 15.1.3.1 (21-day Notice of Claims), and 3.7.4 (concealed conditions, 14-day notice in 2017). You decide which clause applies and what its real deadline is against your executed agreement, decide-then-draft.
• AI shifts the bottleneck from authoring to tracking, so the cycle-day log matters more than ever. A fast-written RFI that sits unlogged is worse than a slow one that was tracked, because the value is in getting answered on time, and you cannot manage what you do not track.
• The artifact: run a real clash end to end, produce the RFI in your actual template, and document the verification record (what you checked against what) and the time comparison (versus hand-writing), so the recovered hours and the passed gate are both concrete.
• These five moves are the template for every document lesson that follows: capture, brief, generate, detect, verify the high-stakes specifics, and log. Getting them solid on the RFI is the foundation of becoming truly AI-assisted.