This chapter builds a complete end-to-end workflow, the RFI lifecycle, using the design method from the last chapter, and it starts where every RFI starts: in the field, when someone notices a condition that does not match the documents and needs a question answered. Traditionally, this moment is where RFIs are lost: the field engineer notices the conflict, means to write it up later, gets pulled to the next fire, and the issue either gets handled informally and undocumented or surfaces weeks later as a bigger problem. AI changes the intake economics: the field worker photographs the condition, dictates a sentence about it, and AI drafts a structured field RFI on the spot, so the question is captured at the moment of discovery instead of deferred and forgotten. This is the intake step of the lifecycle, and getting it right matters more than its low individual stakes suggest, because a well-formed RFI at intake feeds the entire downstream cycle while a misframed one wastes it. This lesson designs the intake step: how AI captures the field RFI, what the field worker verifies, and why the intake quality determines the quality of everything that follows.

The Intake Problem: Where RFIs Are Lost

The intake of an RFI is the moment a field issue becomes a documented question, and it is the weakest point in the traditional RFI process because it depends on a busy field person stopping to write up the issue when they notice it. The reality of the field is that the engineer or superintendent who spots a conflict, a duct clashing with a beam, a detail that does not match the field condition, an ambiguous dimension, is in the middle of running work and has no time to stop and compose a formal RFI, so the issue is mentally noted to handle later, and later it is either forgotten, handled informally without documentation, or written up days afterward when the details have faded. The result is that real questions go uncaptured or get captured late and thin, which is a documentation and coordination failure that cascades.

This intake friction has real downstream cost. An uncaptured RFI means the issue is handled informally, so there is no record, no formal answer, and no documentation if the informal resolution later proves wrong, which is exactly the kind of gap that becomes a dispute. A late-captured RFI means the question reaches the designer later than it should, delaying the answer and the work that depends on it, and a thin RFI, written from faded memory, may miss the detail that lets the designer answer cleanly, prompting back-and-forth. So the intake problem is not trivial: it is where the RFI process most often fails, and the failure is not dramatic but quiet, the issue that never became an RFI or became a poor one, with costs that surface later. Lowering the intake friction so field issues reliably become well-formed RFIs at the moment of discovery is therefore a high-value improvement, and it is exactly where AI's field-capture capability fits.

How AI Captures the Field RFI

AI changes the intake by making capture nearly frictionless at the point of discovery: the field worker photographs the condition and dictates a sentence or two about what they are seeing and asking, and AI drafts a structured field RFI from the photo and the dictation, producing in moments what would have taken the field worker fifteen minutes of composition they did not have. The AI uses two engines together: computer vision reads the photo to understand the condition shown, and generative AI drafts the RFI text, combining the visual context and the dictated question into the structured form the RFI process expects, the location, the description of the condition, the specific question, the references to the documents involved.

The value is that the capture happens when and where the issue is noticed, by the person who noticed it, with the condition in front of them, so the RFI is captured at its freshest and most complete rather than reconstructed later, which solves the intake friction at its source. The field worker does the small, fast thing they can do in the moment, photograph and dictate, and the AI does the composition they had no time for, so the barrier to creating an RFI drops to almost nothing, which means issues that would have gone uncaptured now become RFIs. This is a genuine improvement to the RFI process at its weakest point, but it introduces the characteristic AI risks of both engines, the vision may misread the condition and the generative draft may misstate the question, so the intake design must include a verification appropriate to the step, which is the field worker confirming the AI captured the real condition and the real question before the RFI enters the workflow.

AI captures the field RFI at the moment of discovery: the worker photographs and dictates, and AI drafts the structured RFI using vision to read the condition and generative AI to compose the question. This solves the intake friction where RFIs are lost. But both engines can err, so the field worker confirms the AI captured the real condition and the real question, a lightweight gate appropriate to intake.

The Intake Verification: Light but Real

The verification at intake is calibrated to the step's place in the lifecycle: the RFI at intake is not yet consequential, it is a draft question that will be routed, reviewed, and answered before anything is acted on, so the intake verification is lighter than the verification at a consequential gate, but it is real and specific. The field worker, who is standing in front of the condition, confirms two things: that the AI's understanding of the condition matches what is actually there, catching a vision misread, and that the RFI states the real question they meant to ask, catching a generative misstatement. This is fast because the field worker has the ground truth in front of them, they can glance at the draft and see whether it describes the condition they are looking at and asks what they meant, so the verification takes seconds, not the minutes the original composition would have.

The verification is light because the stakes at intake are low in the immediate sense, an error here does not directly cause harm because the RFI will be reviewed downstream, but it is real because intake errors propagate, which is the key insight about intake's place in the lifecycle. A misframed RFI at intake does not cause immediate harm, but it sends a wrong or unclear question into the downstream workflow, where it consumes routing, review, and designer time before someone realizes the question is wrong or unclear and it has to be redone, so the cost of an intake error is the wasted downstream cycle, not an immediate consequence. So the intake verification, though light, is worth doing because it prevents the propagation cost: the field worker spending seconds to confirm the RFI captures the real condition and question saves the downstream workflow from processing a misframed RFI. The intake verification is the lightweight, propagation-preventing check appropriate to a low-immediate-stakes but high-propagation-cost step, which is exactly how the failure-mode analysis would classify it: low severity in the immediate sense, but with a downstream cost that justifies the quick confirmation.

Intake Quality Feeds the Entire Lifecycle

The deeper reason intake matters is that the RFI lifecycle is a chain, and the quality of the RFI at intake feeds everything downstream, so a well-formed intake RFI flows cleanly through routing, review, and response, while a poorly-formed one degrades every subsequent step. A well-formed field RFI, with the real condition accurately described, the specific question clearly stated, and the relevant documents referenced, can be routed correctly, reviewed efficiently, and answered cleanly by the designer, because it gives each downstream step what it needs. A poorly-formed one, with a misread condition, a vague question, or missing references, gets misrouted, requires clarification, and prompts designer back-and-forth, because each downstream step is working from a flawed input.

This is the chained-workflow principle from the failure-mode lesson applied to the RFI lifecycle: an error or weakness at an early step propagates and compounds downstream, so the intake, as the first step, has outsized leverage on the whole lifecycle's efficiency. The AI's intake capture, properly verified, improves the lifecycle not just by lowering intake friction but by feeding well-formed RFIs into the downstream steps, which is where much of the lifecycle's efficiency comes from, because a clean input makes every downstream step faster. The discipline is to recognize that intake quality is not just about capturing the RFI but about capturing it well, so the AI's draft is verified to be a well-formed RFI, accurate condition, clear question, correct references, before it enters the workflow, because the few seconds spent ensuring intake quality save time at every subsequent step. So the intake step is designed not just for capture but for quality, because as the first link in the chain it determines how cleanly the rest of the chain runs, which is why a light verification at intake has leverage far beyond its immediate step. Capturing the RFI solves the friction; capturing it well feeds the lifecycle.

Lowering the Barrier Changes Field Behavior

A second-order effect of frictionless intake is worth naming because it changes the project's documentation culture: when creating an RFI drops from a fifteen-minute composition to a thirty-second photo-and-dictate, field workers create RFIs they would not have bothered with before, which surfaces issues that previously went undocumented. This is largely good, because the issues that previously went uncaptured, the small conflicts handled informally, the ambiguities resolved by a verbal conversation, were documentation gaps that could become disputes, so capturing them as RFIs creates the record that protects the project. The lower barrier converts informal, undocumented field problem-solving into documented RFIs, which is a real improvement in the project's record and coordination.

But the behavior change has a flip side to manage: a much lower barrier can produce a higher volume of RFIs, including some that are trivial or that a moment's thought would resolve without an RFI, so the frictionless intake can flood the downstream workflow if every minor question becomes an RFI. This is not a reason to keep the barrier high, because the captured documentation is valuable, but it is a reason to design the downstream workflow to handle the higher volume, which the next lessons address with routing, duplicate detection, and triage, and to encourage field workers to still apply judgment about what warrants an RFI rather than reflexively capturing everything. The discipline is to welcome the increased capture of real issues while managing the volume downstream and maintaining field judgment about what is worth an RFI, so the lower barrier surfaces the issues that should be documented without drowning the workflow in trivia. The behavior change is mostly a benefit, more issues documented, but it shifts load to the downstream steps, which the lifecycle design must accommodate, so frictionless intake and robust downstream triage go together. The lower barrier is good for the record and requires the downstream design to handle the volume it creates.

The Applied Problem: Design the Intake Step

Here is the exercise. Design the intake step of an RFI lifecycle: specify the field-capture workflow (photograph plus dictate), the AI drafting (vision reads the condition, generative composes the structured RFI), and the intake verification (the field worker confirms the AI captured the real condition and question), and account for how intake quality feeds the downstream lifecycle and how the lower barrier changes RFI volume. Produce the intake-step design that would feed well-formed RFIs into the rest of the lifecycle.

Produce two things. First, the intake-step design: the capture workflow, the AI drafting, and the verification, in the form that would let a project implement frictionless, well-verified RFI intake. Second, the propagation-and-volume analysis: how an intake error would propagate downstream and why the light verification prevents it, and how the lower barrier changes RFI volume and what downstream handling that requires, with the reasoning that connects intake quality to lifecycle efficiency. Pay particular attention to the vision misread risk, because the photo is the AI's window onto the real condition and a misread there sends a wrong understanding into the entire lifecycle, which is the intake's most consequential failure mode.

The deliverable is the intake-step design and the propagation-and-volume analysis, and the lasting product is a designed RFI intake that captures field issues frictionlessly at the moment of discovery while a light, real verification ensures the captured RFI is well-formed before it feeds the lifecycle. This is the first step of the end-to-end RFI lifecycle the chapter builds, and it demonstrates the workflow-design method on a real process: the intake step is classified (AI captures, human verifies), gated lightly (appropriate to its low immediate stakes), and its failure mode mapped (low severity but high propagation cost). The professional who masters this designs an intake that converts the RFI process's weakest point, the lost or thin field RFI, into its strength, a frictionless capture of well-formed RFIs at the moment of discovery, achieved because AI lowers the capture barrier and a quick verification ensures quality, which feeds the entire downstream lifecycle the next lessons build on.

Key Takeaways

• Intake, the moment a field issue becomes a documented question, is the weakest point in the traditional RFI process, because it depends on a busy field person stopping to compose a formal RFI when they notice the issue, so issues go uncaptured, handled informally, or written up late and thin.
• AI changes the intake economics: the field worker photographs the condition and dictates a sentence, and AI drafts a structured field RFI using two engines, computer vision to read the condition and generative AI to compose the question, capturing the RFI at the moment of discovery instead of deferring it.
• The capture happens when and where the issue is noticed, by the person who noticed it, with the condition in front of them, so the RFI is captured at its freshest rather than reconstructed later, solving the intake friction at its source. But both engines can err.
• The intake verification is light but real: the field worker, standing in front of the condition, confirms the AI's understanding matches the actual condition (catching a vision misread) and the RFI states the real question (catching a generative misstatement), which takes seconds because the ground truth is in front of them.
• Intake is low-severity in the immediate sense (the RFI is reviewed downstream before anything is acted on) but high-propagation-cost: a misframed intake RFI consumes routing, review, and designer time before someone realizes it is wrong, so the light verification is worth it to prevent the wasted downstream cycle.
• Intake quality feeds the entire lifecycle (the chained-workflow principle): a well-formed RFI flows cleanly through routing, review, and response, while a poorly-formed one degrades every step, so the intake has outsized leverage on the whole lifecycle's efficiency, and the verification ensures the RFI is well-formed before entering.
• Lowering the barrier changes field behavior: frictionless intake surfaces issues that previously went undocumented (good for the record), but can produce higher RFI volume including trivial questions, so the downstream workflow must handle the volume (routing, dedup, triage) and field judgment about what warrants an RFI should be maintained.
• The artifact: design the intake step (capture, AI drafting, verification), analyze how an intake error propagates and how the light verification prevents it, and how the lower barrier changes volume, with attention to the vision misread as the intake's most consequential failure mode because the photo is the AI's window onto the real condition.