# Submittal vs RFI: When to Stop Guessing and Ask

The two formal channels between an integrator and the design team, what each is for, and the judgment call of when a question beats an interpretation.

Two formal channels connect you to the design team. The submittal says: *here is what we intend to supply, please confirm it meets your design.* The RFI (Request for Information) says: *your documents are unclear or conflicting on this point, please tell us what you meant.* They're both numbered, logged, and tracked to a written response, and they are not interchangeable. Most of the pain in this area comes from pushing a question through the wrong channel, or worse, not asking it at all.

## What each channel is for

**A submittal carries a proposal.** The spec is clear, you've selected equipment that meets it, and you're presenting the evidence for review. The response is a stamp: approved, approved as noted, revise and resubmit. What each stamp obligates you to do is its own topic: [what Approved as Noted actually requires](/learn/approved-as-noted).

**An RFI carries a question.** Something in the contract documents doesn't resolve: the one-line diagram disagrees with the schedule, the spec demands a feature the named product line doesn't offer, the referenced section isn't in the book. You state the conflict, cite both documents, propose an answer if you have one, and ask. The written answer becomes part of the contract record, and if it changes scope, it's the paper that supports the change order.

## The failure mode: guessing by submittal

Here's the pattern that costs real money. The spec is ambiguous. Instead of asking, you pick the interpretation that suits you, build the submittal around it, and send it in, figuring the review will settle it. Sometimes it does. But you've made a bet with bad odds:

- **If the reviewer catches the discrepancy**, the package comes back revise-and-resubmit, and you've spent a two-to-four-week review cycle discovering what one RFI would have told you before the package was ever assembled.
- **If the reviewer doesn't catch it**, you now hold an approval built on an interpretation nobody actually confirmed. Review stamps almost universally state that approval doesn't relieve you of responsibility for contract compliance. When the mismatch surfaces at startup, "but you approved it" is a much weaker position than a written RFI answer would have been.

An approval answers "does this equipment appear to meet the documents." It does not answer "which of two conflicting documents governs." Only an RFI answers that.

## When to send which

Ask yourself one question: **am I proposing, or am I interpreting?**

Proposing, with clear requirements behind you: submittal. Interpreting, because the requirements conflict or don't cover the case: RFI first, then the submittal built on the answer.

Concrete cases from the integrator's world:

| Situation | Channel |
|---|---|
| Selected a PLC that meets every stated requirement | Submittal |
| Spec names a product line that can't do what Part 2 demands | RFI |
| Panel spec says NEMA 12, installation detail shows it outdoors | RFI |
| Want to supply an equivalent from a manufacturer not listed | Substitution request per Division 01 (not a plain submittal, and not an RFI) |
| Spec's demanded submittal item doesn't exist for your scope | RFI, then note the answer in the package |
| Reviewer's comment on Rev 1 conflicts with the spec | RFI, before building Rev 2 on the comment |

That last one is underused. A review comment that contradicts the spec puts you between two authorities, and resolving it by silently obeying the comment leaves the contradiction alive in the record.

## Asking well

RFIs have a reputation problem on some jobs, where volume is used as a lever rather than a genuine question channel. Don't be that log. A good RFI is specific, cites its documents by section and paragraph, states the impact if it goes unanswered ("panel fabrication holds pending this answer"), and proposes an answer when you have a defensible one, since a proposed answer is the easiest thing for a busy engineer to confirm. One question per RFI; bundles get partial answers.

Timing matters more than polish. The cheapest RFI is the one asked at bid review or during the [spec-section read](/learn/read-a-spec-section-for-submittals), before the interpretation gets welded into a package, a purchase order, or a panel. Every week the question waits, the answer gets more expensive to apply. Both logs, submittal and RFI, deserve the same record-keeping discipline: numbered, dated, tracked to a written response, kept forever. On the RFI side, the answers are contract clarifications, and finding "what did the engineer actually direct" three years later matters exactly as much as finding the approved submittal.

*Disclosure: I build [Submittal Kit](/), which keeps the RFI register and the submittal log side by side on the same project, both permanent. The judgment call of when to ask is yours; the record of what was asked should never be.*

---
Submittal Kit · Learn · Updated 2026-08-17
Canonical: https://submittalkit.com/learn/submittal-vs-rfi