RFI vs Change Event — when to file which

These two are not the same document. They serve different purposes, have different audiences, and live in different parts of STrOp. Filing the wrong one — or filing one when you should file both — is the most common reason recovery gets denied.

RFI — Request for Information

A formal question to the design team or GC asking for direction, clarification, or a missing detail. RFI workflow:

1. Field hits something unclear (drawing conflict, missing dimension, spec ambiguity).
2. PE files an RFI documenting the question + impact-if-unanswered.
3. GC routes to architect/engineer.
4. Response comes back. Now there's an answer.

The answer might confirm the original scope (no change) OR it might direct work that wasn't in the contract. The RFI itself is not a change. The answer might trigger one.

In STrOp: /projects/[id]/rfis. Linked to the project; status tracks open / answered / closed.

Change Event — record of a potential impact

A Change Event captures the cost / time impact of something that happened on the project. It's the precursor to a PCO. Change Events come from:

• An RFI response directing extra work
• A field directive ("just go ahead and do it") from the owner's rep
• A site condition discovered during execution
• A schedule change imposed by the GC
• A delay caused by another trade

The Change Event documents: what happened, when, who directed it, the affected work, and the estimated cost + time impact. It is the file you build the PCO from.

In STrOp: /changes (org view) or /projects/[id]/changes (project view). Status tracks open / quantified / promoted-to-PCO / withdrawn.

When the line gets crossed

The RFI answer that directs extra work is the classic ambiguity case. The right sequence is:

1. RFI filed with the question.
2. RFI answered with direction.
3. A Change Event is created the same day that references the RFI by number, summarizes the directed work, and starts the impact estimate.
4. Foreman files a T&M tag per shift while performing the work (see T&M tag).
5. PE/PM rolls the Change Event into a PCO once the impact is quantified.

If you stop at step 2, you have an RFI but no record of the change. The schedule slips, the cost overruns, and when you go to invoice you have nothing to point at except the RFI answer — which the GC will say "was just a clarification."

STrOp helpers

• The RFI detail page has a "Create Change Event from this RFI" action that pre-fills the reference and the impact summary.
• Change Events surface on the project header as a count badge when there are open (un-promoted) events. Don't let that number grow.

Common failure modes

• RFI only, no Change Event. Most common. Recovery effectively lost.
• Change Event without RFI documentation. Less common but happens when verbal directives skip the RFI step. File the Change Event AND a documenting RFI/letter the same day.
• Promoting Change Events to PCO without quantification. A PCO with "TBD" cost is a PCO the GC will defer reviewing indefinitely. Quantify first.

See also

• T&M tag — owner signature
• PCO vs CO