The frictionless intake from the last lesson solves the problem of lost RFIs, but it creates a new one: volume. When every field issue becomes an RFI in thirty seconds, the RFI log fills with more entries, more duplicates, and more variety than a coordinator can triage by hand, and an untriaged log is its own failure, RFIs sitting unrouted, the same issue logged three times, the log so cluttered that the important RFI is lost in the noise. This is the routing, duplicate-detection, and log-hygiene step of the lifecycle, and it is the natural counterpart to frictionless intake: AI handles the high-volume triage that the high-volume capture demands. AI routes each RFI to the right reviewer, flags the duplicates, and keeps the log clean, which is exactly the kind of high-volume, pattern-based work it does well. But two of these moves carry a specific danger that deserves the most attention, because merging RFIs that look like duplicates can suppress a real, distinct question, and a suppressed question is a worse failure than a duplicate, so the verification here is shaped by an asymmetry. This lesson designs the triage step and the verification its specific failure modes require.

The Volume Problem That Intake Creates

Frictionless intake and high-volume triage are two halves of one design: lowering the intake barrier necessarily raises the volume, so the lifecycle must include a step that handles the volume, or the captured RFIs simply pile up unprocessed, which would waste the capture. The volume manifests in three ways the triage step must address. There is routing volume: every RFI must go to the right reviewer, the right discipline, the right person, and with more RFIs there is more routing to do, which done manually is a tedious bottleneck. There is duplicate volume: with low-friction capture, the same issue gets logged by multiple workers, or a new RFI duplicates an open one, so the log accumulates redundant entries that waste downstream effort if each is processed separately. And there is hygiene volume: the log accumulates inconsistent categorization, incomplete entries, and clutter that makes it harder to see the real state of the open RFIs.

Each of these, done manually, is a tedious triage burden that scales with the RFI volume, so as intake gets more frictionless, the manual triage gets more overwhelming, which is why the triage step is the necessary counterpart to frictionless intake. Without it, the lifecycle would capture well and process badly, the volume from intake overwhelming the manual triage and clogging the workflow, so the gain from frictionless intake would be lost in the triage bottleneck. The triage step resolves this by applying AI to the high-volume triage work, routing, deduplication, and hygiene, that the high-volume capture creates, so the lifecycle can capture broadly and still process cleanly. This is the chained-workflow design in action: the intake's high-capture approach is viable only because the triage step is designed to handle the volume it creates, so the two steps are co-designed, the intake capturing and the triage managing, which is why frictionless intake and AI triage go together.

What AI Does Well in Triage

The triage work is exactly the kind AI does well: high-volume, structured, pattern-based classification and matching, which the engines handle reliably. Routing is a classification task, the AI reads each RFI's content and classifies it by discipline and reviewer, directing it where it should go, which is reliable because routing is largely a pattern-matching of content to category. Duplicate detection is a matching task, the AI compares each RFI's location, condition, and references against the existing log and flags potential duplicates, which is reliable because the AI can compare across the whole log far faster and more thoroughly than a human scanning manually. Log hygiene is a consistency task, the AI normalizes categorization, flags incomplete entries, and surfaces the log's real state, which is reliable because it is rule-based cleaning of structured data.

This is genuine, high value because the triage work is both tedious and volume-scaling, so automating it relieves the coordinator of a growing burden and lets the lifecycle handle the intake volume, and the work is largely within AI's reliable zone, classification and matching of structured content, so the AI does it well. But within this generally-reliable work, the moves differ in their risk: routing errors are recoverable (a misrouted RFI is rerouted, costing some delay), hygiene errors are minor (a miscategorized entry is recategorized), but duplicate detection carries a specific, more dangerous failure mode, the false merge, which suppresses a real question, so the triage step's verification concentrates there. So the triage step is mostly a clear win, AI handling the volume well, with one move, duplicate merging, that requires careful verification because its failure mode is uniquely costly, which the next sections develop. The triage is where AI's high-volume strength meets the volume intake creates, with the verification focused on the one move whose failure is severe.

Triage, routing, duplicate detection, and log hygiene, is high-volume pattern-based work AI does well, and the necessary counterpart to frictionless intake's volume. Most of it is a clear win with recoverable errors, but duplicate merging carries a uniquely dangerous failure: a false merge suppresses a real, distinct question, which is worse than a missed duplicate, so the verification concentrates on the merges.

The Merge Asymmetry: Suppression Is Worse Than Redundancy

Duplicate detection has two failure directions with very different costs, and understanding the asymmetry is the key to verifying it correctly. A missed duplicate is a false negative: the AI fails to flag that two RFIs concern the same issue, so both are processed separately, which wastes some downstream effort, the designer answers essentially the same question twice, but no information is lost, both questions are answered. A false merge is a false positive: the AI flags two RFIs as duplicates when they actually ask different questions, and if they are merged, one question is suppressed, only one is answered, and the distinct question the other RFI raised is lost, never answered, because it was absorbed into a merge with a different question.

The asymmetry is that suppression is worse than redundancy: a missed duplicate costs some wasted effort but loses nothing, while a false merge loses a real question, which can have serious consequences if the suppressed question concerned a real issue that now goes unaddressed because everyone believes it was answered when actually a different question was answered. This is the same shape as the false-negative asymmetry from clash detection, where filtering out a real clash as noise was worse than keeping a false clash, applied to RFI merging: suppressing a real question by false merge is worse than the wasted effort of a missed duplicate. The asymmetry shapes the verification: because the false merge is the costly error, the verification concentrates on confirming the merges, checking that RFIs flagged as duplicates truly ask the same question before they are merged, while missed duplicates, being low-cost, warrant less concern, since they will be caught later or simply cost a little redundant effort. So the triage verification is asymmetric by design: verify the merges carefully because a false merge suppresses a real question, and treat missed duplicates as the lower-cost error they are, which is the correct allocation of verification attention given the asymmetry in the failure costs.

The Verification: Confirm the Merges, Spot-Check the Routing

The triage verification follows from the failure-mode analysis: confirm the duplicate merges carefully because they carry the severe false-merge risk, spot-check the routing because its errors are recoverable, and lightly review the hygiene because its errors are minor. The merge verification is the heart of it: before two RFIs flagged as duplicates are merged, the coordinator confirms they truly concern the same question, not merely similar conditions or locations, because the AI's similarity-based matching can flag RFIs that are near each other or describe similar conditions but ask truly different questions, and merging those would suppress one. The coordinator's check is to read the flagged pair and confirm the questions are the same, which is fast for each pair and concentrated only on the merges, so it is a targeted verification of the one move whose failure is costly.

The routing verification is lighter because a routing error is recoverable: a misrouted RFI is noticed by the wrong recipient and rerouted, costing some delay but not losing the RFI, so the coordinator spot-checks the routing rather than confirming every route, accepting that the occasional misroute will be caught and corrected at low cost. The hygiene review is lightest because hygiene errors, a miscategorized or incompletely-normalized entry, are cosmetic and easily fixed, so they warrant only a light pass. This proportioning, careful on merges, spot-check on routing, light on hygiene, is the failure-mode-driven verification design applied to the triage step, concentrating the verification effort on the merge where the failure is severe and economizing on the routing and hygiene where failures are recoverable or minor. The discipline is that the coordinator does not verify the triage uniformly but proportionately, spending their attention on the merges because that is where an unverified error suppresses a real question, which is the failure the triage step most needs to prevent. The verification is shaped by the asymmetry: the merge gets the scrutiny because the false merge is the costly error.

The RFI Log as a Shared Project Asset

There is a reason log hygiene matters beyond tidiness: the RFI log is a shared project asset that many parties rely on to understand the project's open questions and their status, so a clean, accurate log serves the whole project, while a cluttered one misleads everyone who reads it. The PM uses the log to track open issues, the designer to see their queue, the owner to gauge the project's question load, the scheduler to anticipate answer-dependent work, so the log's accuracy and clarity affect many decisions, and a log cluttered with duplicates, miscategorized entries, and noise gives all these parties a distorted picture of the project's real state. AI's hygiene work, keeping the log clean, deduplicated, and consistently categorized, therefore serves the whole project by maintaining the shared asset that coordinates the parties' understanding of the open questions.

This reframes the hygiene work from cosmetic tidiness to a coordination function: the clean log is what lets the parties coordinate around the project's open questions accurately, so maintaining it well is maintaining the project's shared situational awareness, which is valuable beyond the individual RFI. The AI is well-suited to this maintenance because it is the high-volume, consistency-keeping work that humans neglect under load, exactly when the log most needs it, so AI maintaining the log keeps the shared asset accurate even as the volume grows, which a human coordinator under load would let degrade. But the duplicate-merge caution applies to the hygiene too: the AI keeping the log clean by merging duplicates must not suppress real questions in the name of tidiness, so the hygiene's deduplication is subject to the same merge verification, because a clean log that has suppressed a real question is cleaner but wrong. So the log hygiene serves the project's shared coordination, AI maintains it well at volume, and the merge verification protects against the cleaning suppressing real questions, which keeps the shared asset both clean and complete, accurately reflecting the project's real open questions to all the parties who rely on it. The log is a shared asset, and its hygiene is a coordination service the AI provides under the merge-verification discipline.

The Applied Problem: Design the Triage Step

Here is the exercise. Design the routing, duplicate-detection, and log-hygiene step of the RFI lifecycle: specify the AI's routing (classification to reviewer), duplicate detection (matching against the log), and hygiene (normalization and cleaning), and design the verification proportionate to each move's failure mode, careful confirmation of merges, spot-check of routing, light review of hygiene. Produce the triage-step design that handles the intake volume while protecting against the false merge.

Produce two things. First, the triage-step design: the AI's three triage functions and the proportionate verification for each, in the form that would let a project handle high RFI volume cleanly. Second, the merge-asymmetry analysis: the two failure directions of duplicate detection, why the false merge (suppressing a real question) is worse than the missed duplicate (redundant effort), and how the verification concentrates on the merges as a result, with the reasoning connecting the asymmetry to the verification design. Pay particular attention to the case of two RFIs that are similar in location or condition but ask truly different questions, because that is exactly where the AI's similarity matching would propose a false merge and where the coordinator's confirmation prevents the suppression of a real question.

The deliverable is the triage-step design and the merge-asymmetry analysis, and the lasting product is a designed triage step that handles the volume frictionless intake creates while concentrating verification on the false merge, the one triage failure that suppresses a real question. This is the second step of the RFI lifecycle, the necessary counterpart to the intake's high-capture design, and it demonstrates the failure-mode-driven verification from chapter one: the triage's moves are classified by failure cost, and the verification is concentrated on the merge where the failure is severe and economized on the routing and hygiene where failures are recoverable. The professional who masters this designs a triage that lets the lifecycle capture broadly and process cleanly, handling the volume with AI while the merge verification ensures no real question is suppressed in the deduplication, which is the balance the high-volume lifecycle requires, achieved by matching the verification to the asymmetric failure costs of the triage's moves.

Key Takeaways

• Frictionless intake creates volume, so the lifecycle must include a triage step to handle it, or the captured RFIs pile up unprocessed and the capture gain is lost. Routing, duplicate, and hygiene volume each scale with intake, making manual triage a growing bottleneck.
• Triage is high-volume, pattern-based work AI does well: routing is content-to-reviewer classification, duplicate detection is location-condition-reference matching against the log, and hygiene is rule-based normalization of structured data, all within AI's reliable zone.
• Triage is mostly a clear win with recoverable errors (a misroute is rerouted, a miscategorization is fixed), but duplicate merging carries a uniquely dangerous failure, the false merge, so the verification concentrates there.
• The merge asymmetry: a missed duplicate (false negative) wastes some effort but loses no information (both questions answered), while a false merge (false positive) suppresses a real, distinct question (only one answered, the other lost), so suppression is worse than redundancy.
• This is the same false-negative asymmetry as clash detection: suppressing a real question by false merge is worse than the wasted effort of a missed duplicate, and it shapes the verification to concentrate on confirming the merges before they are made.
• The verification is proportionate: confirm the duplicate merges carefully (read the flagged pair, confirm the questions are truly the same, not merely similar conditions), spot-check the routing (errors recoverable), and lightly review the hygiene (errors minor), concentrating attention where the failure is severe.
• The RFI log is a shared project asset many parties rely on (PM, designer, owner, scheduler), so a clean log serves the whole project's coordination and a cluttered one misleads everyone, making hygiene a coordination function, not cosmetic tidiness, that AI maintains well at volume under the merge-verification discipline.
• The artifact: design the triage step (routing, dedup, hygiene) with proportionate verification, and analyze the merge asymmetry, with attention to two RFIs similar in location or condition but asking different questions, exactly where the AI would propose a false merge and the coordinator's confirmation prevents suppressing a real question.