The AI-Assisted RFI: How We're Using Language Models

A bad RFI is a tax on the whole project. The EOR gets a vague question, spends 20 minutes trying to understand what's actually being asked, writes a hedged answer that doesn't resolve anything, and the detailer is back to square one — except now two weeks have passed. RFI quality is not a small thing. On a complex project, the difference between an RFI that gets a clean, actionable response in three days and one that bounces back and forth for two weeks is often the difference between holding schedule and missing it. We've been experimenting with using language models — specifically, using them as drafting and editing tools in the RFI writing process — and the results are specific enough to be worth reporting honestly. LLMs are good at structure and completeness. They're bad at technical accuracy. The workflow that works is: detailer identifies the issue and provides the technical content, LLM formats and stress-tests the clarity, detailer reviews and corrects before sending.

Why RFI Quality Matters in Steel Detailing

An RFI is a formal communication loop with real schedule consequences. When you fire off a vague question to the EOR, you're not just buying yourself a round-trip delay — you're burning their attention on interpretation work they shouldn't have to do. A structural engineer reviewing submittals and fielding RFIs simultaneously doesn't have time to read between the lines. If your RFI doesn't immediately communicate what's ambiguous, why it matters, and what resolution you're looking for, the response you get back will reflect that.

On structural steel projects, the cost compounds fast. A detailer waiting on connection clarification at a beam-to-column moment connection can't release that node to IFC. The fabricator can't cut or drill. The erection sequence backs up. One poorly written RFI on a critical-path connection can hold a shop drawing package for weeks.

The correlation is direct: precise questions get precise answers, and that's the problem the AI-assisted workflow addresses.

The Anatomy of a Bad RFI

You know this one when you see it. It reads something like:

> "The connection at gridline D/3 doesn't seem to work. Please advise."

What's wrong? Everything. The EOR now needs to pull the drawing, figure out which connection at D/3 you mean (the W18x55 to the W14x90 column, or the HSS6x6x3/8 brace connection below?), determine what "doesn't work" means, and decide whether you're asking for a revised design, a code interpretation, or permission to proceed. They'll probably write back asking for clarification, which starts the clock over.

The hallmarks of a bad RFI:

- Vague problem description. "Doesn't seem to work," "appears to conflict," "unclear per drawings." What specifically is the issue?

- Missing reference documents. No sheet number, detail reference, spec section, or drawing revision.

- No stated impact. The EOR doesn't know whether this is blocking fabrication today or is a future concern.

- No specific question. "Please advise" is not a question. It forces the respondent to guess what resolution you're looking for.

Bad RFIs aren't usually written by careless detailers. They're often written by competent people under time pressure who know what they mean internally and assume the recipient has the same context. They don't.

The Anatomy of a Good RFI

A well-structured RFI has four parts: a problem statement, document references, a specific question, and a requested resolution.

Problem statement: What is the actual condition? Describe the physical situation precisely. "The W24x68 beam at gridline D/3, per S-204 Rev 2, Detail 5B, frames into the web of the W14x90 column. The top flange of the beam conflicts with the bottom flange of the transfer beam above, leaving insufficient clearance to install the specified moment end plate."

Document references: Sheet number, detail reference, spec section, drawing revision. If there's a relevant AISC or AWS provision in play, cite it. Give the EOR exactly what they need to locate the condition without hunting.

Specific question: Not "please advise" — "Is the beam elevation shown on S-204 the governing dimension, or can the beam be dropped 1.5" to clear the transfer flange? If the elevation is fixed, what revised connection configuration do you recommend?"

Requested resolution: What format do you need the answer in, and what's your deadline? "We need direction by [date] to maintain the IFC submittal schedule for this package."

That's an RFI that gets answered. The EOR can read it, understand the condition, and respond with a decision.

How We're Using LLMs in the AI RFI Drafting Process

The workflow is not "describe your problem to the AI and send what it writes." That would be a mistake, and we'll get to why.

The actual workflow: the detailer identifies the issue, pulls the relevant drawing references, and writes a rough internal note — essentially a brain dump of the technical condition and what they need to know. That note goes into the language model with a structured prompt: "Rewrite this as a formal RFI. The audience is a licensed structural engineer. The RFI should include a clear problem statement, all document references provided, a single specific question, and a requested resolution date. Flag any gaps in the information I've provided."

The model outputs a structured draft. More importantly, it flags what's missing. "You haven't specified the drawing revision." "The specific question isn't clear — are you asking whether the elevation is fixed or whether an alternative connection is acceptable?" That gap-checking function is genuinely useful. Detailers writing under deadline pressure skip things they know but forget to include. The model catches the omissions.

We also use LLMs to calibrate tone. An RFI drafted in frustration at 4:30 PM on a Friday reads differently than one written with professional detachment. The model smooths that out without losing the technical content.

What LLMs Do Well in Better RFI Writing

- Structure. LLMs are excellent at taking an unordered brain dump and producing a logically sequenced document. Problem → references → question → resolution is a simple template, but under deadline pressure people skip steps.

- Completeness checking. The gap-flagging function is the most practically valuable part of this workflow. "You haven't specified which revision of the drawing this refers to" is a simple catch that prevents a pointless round-trip.

- Clarity and concision. Models will cut redundant language and tighten sentences. An RFI that takes 400 words to say something that needs 150 words loses the EOR's attention.

- Tone calibration. Professional, neutral, and specific — the model holds that register consistently.

What LLMs Do Poorly in Steel Fabrication RFIs

This is the part that matters most for anyone thinking about implementing this workflow.

LLMs will confidently generate code citations, AISC provision references, and connection geometry details that are wrong. Not slightly imprecise — factually incorrect in ways that would corrupt the RFI and potentially lead to a bad EOR response built on a false premise.

If you let the model add technical content you didn't provide, you will get errors. The model doesn't know your project. It doesn't know whether the connection in question is in a seismic SDC D zone or a wind-governed lateral system. It doesn't know whether your fabricator uses RCSC-spec bolting or what the EOR's standard detail library looks like.

The rule we follow: the model formats and edits. It does not generate technical content. Every code reference, every dimension, every member designation in the final RFI was either written by the detailer or verified against the drawings before the model touched it.

The Human Review Step

AI-drafted does not mean AI-sent. Every RFI that goes through this workflow gets a full technical review by the detailer before it leaves the office. The review checklist is simple: Are all document references accurate and current? Is the described condition correct? Is the specific question actually asking what we need answered? Are the dimensions, member sizes, and connection details correct?

This step is not optional. The LLM's value is in structure and clarity, not accuracy. Skipping the human review would undermine the entire purpose — you'd be trading poorly written RFIs for polished but technically unreliable ones, which is worse.

Results We've Observed

Response quality from EORs has improved measurably on projects where we've implemented this workflow. The most direct indicator: fewer RFIs returned for clarification before the EOR responds. On recent commercial projects, we've seen a significant reduction in the "can you clarify what you're asking" loop that used to eat a week per incident.

Response time has also tightened. When an EOR receives an RFI they can answer immediately — clear condition, clear question, clear stakes — they answer it immediately. That's not an AI finding; that's just how busy engineers allocate their attention. We've made it easier to say yes quickly.

The underlying workflow isn't complicated. Detailers were already doing the hard part: identifying the issue and knowing what resolution they needed. The LLM just stops the communication quality from getting in the way of the technical content.

If you're evaluating detailing partners for your next project, contact NRSteel for a scope review. We work exclusively with fabricators on structural commercial and institutional projects across the Southeast and nationwide — same timezone, direct engineer access, no handoff chains.