How do field notes become a change request without becoming approved scope?
Format: Article.
A field note can start a change request. First, turn it into a clear question, link the source and name who will review it. A title or price does not approve extra work. A place on the project dashboard does not approve it either.
Start with two separate records: what the field team reported and what the authorized project team decided. Link them. Do not let a polished summary replace either one.
Procore says a change event helps teams plan for possible cost changes before those costs arise.[1] The office method below uses that idea. It does not decide what a contract allows or what notice a project needs.
Capture the observation before arguing the change
Keep the original note, its author, the job reference and the location. Record when the event was observed separately from when the note reached the office. If the author cannot confirm the observation date, mark it unknown.
Ask the person reporting the issue to describe what they saw or were asked to do. Put their proposed solution in a separate field. A sentence such as “We need more blocking here” mixes an observation with a technical choice. The office should not turn that sentence into a final work instruction.
Use a stable note ID. A revised summary can then point back to the same evidence without looking like a second event. If several notes concern one location, link them as related until the project manager confirms whether they concern the same change.
Copy this field-note-to-review packet
| Packet field | What to enter | What must stay separate |
|---|---|---|
| Origin | Note ID, author, observation date, received date | Date guesses |
| Place | Job, building, floor, room or agreed location label | Similar locations on another job |
| Evidence | Original note, photo IDs, referenced drawing and revision | AI interpretation of an image |
| Scope question | The exact point the project manager must resolve | A statement that extra work is approved |
| Baseline reference | Link to the scope record being compared | An unsourced description of the contract |
| Cost inputs | Supplier quote, labor input owner, units, date, missing items | A final customer commitment |
| Decision state | Unreviewed, clarification needed, proposed, decided | A blank approval treated as yes |
| Decision record | Authorized reviewer, dated decision, applicable revision | A message that only acknowledges receipt |
Use this template to prepare office records. Your project team must name who may approve a change. Have the right professionals set the contract and notice steps; this packet does not replace them.
Move the packet, not the scope boundary
The coordinator checks that the files open and belong to this job. The project manager checks the scope question. An estimator gathers costs when asked. The person with approval rights then records the decision through the company's process.
Those tasks need not happen in one order for every job. What matters is that each output has its own state. Cost collection may be complete while the scope question is still open. A reviewer may decide that more information is needed without approving the proposed work.
For each cost input, show whether it is supplied, checked or missing. Do not replace missing labor or material details with zero. Include any schedule concern as an attributed note for review, not a promise that a date can be met.
Hypothetical example: the extra opening
A foreman submits two photos from the west storage room. The note says, “Customer asked about another opening.” There is no marked drawing or recorded decision.
The coordinator creates packet FN-27. Its question is: “Does the requested opening change the current scope for this room?” The photos stay linked to the foreman's stated location. They do not prove that location or assess the design. The packet points to the current scope reference and names the project manager as the next owner.
A subcontractor sends a price. The coordinator attaches it under cost inputs. The packet remains “clarification needed” because a price does not answer the scope question. The manager asks the authorized project contact to clarify the request through the agreed process.
The record says “request under review,” not “approved change.” Staff do not guess a work instruction, customer promise or notice deadline. When a decision arrives, save who made it and when. Link it to the packet and keep the first note.
Check the handoff before release
Try three desk tests. Can a reviewer open the original evidence? Can someone identify the exact unresolved question without reading the whole message chain? Can the field brief show the last approved scope without pulling a proposed change into it?
If any answer is no, return the packet to its owner. Measure missing evidence and unresolved questions if useful, but do not call a packet count a measure of approved change value.
Core Agentic can discuss a custom design that prepares these packets from approved records. This is not a finished construction platform or an installed connection. Keep scope, technical work and commitments with authorized people.
Book a Demo to discuss a field-note review flow shaped around your project roles.
Sources
- Procore: Create Change Events - Procore.
These sources describe the named provider or framework. They do not establish a Core Agentic integration, customer result or certification.