Change Event

Definition — what it is

A change event is the earliest internal record that a condition has arisen which may alter the contracted scope, cost, or schedule. It is a neutral container: it captures what happened, when it was discovered, and who is potentially responsible, before the change has been priced, characterized as owner-caused or self-inflicted, or resolved. A change event is not a claim, not a change order, and not an admission of entitlement — it is the front of the funnel through which every priced change and every eventual dispute must pass. Its purpose is to ensure that nothing that could carry money or time disappears before it is captured, because in construction the cheapest thing to lose is the record of when a problem was first known.

Also known as: Change Notice, Potential Change Notice, Change Log Entry, Issue

Why it matters — what it protects

The change event is where notice lives. Most contracts require written notice of a changed condition within a short window — often 7, 14, or 21 days of discovery — and failing to give that notice can bar recovery entirely regardless of merit. The change event is the mechanism that converts a superintendent's verbal observation into a dated, contemporaneous record that satisfies the notice clause, which is why the discipline of opening one immediately is worth far more than the effort it costs.

It protects margin by capturing cost before it is buried. Extra work performed without a corresponding change event surfaces later as an unexplained labor overrun or a material variance in the job cost report, at which point the leverage to negotiate it is gone and the money has already been spent. Opening a change event at the moment of discovery preserves the ability to price the work, seek authorization, and be paid for it.

It is the raw material of every downstream artifact. A change event that is validated becomes a potential change order, which is priced and becomes a change order request, which the owner executes as an owner change order or issues under a construction change directive. If it is denied but the contractor believes it has entitlement, it becomes a claim. The quality of the change event determines the quality of everything that follows.

The aging and disposition of the change event log is a leading indicator of project health and of relationship health with the owner. A growing backlog of open, unpriced change events signals both incomplete design and an administrative bottleneck, and a low conversion rate from change event to executed change order signals either weak entitlement analysis or an owner who is not honoring the contract.

Lifecycle — how it moves

1. Discovery

   Someone encounters a deviation — a differing site condition, an owner-directed scope addition, an RFI answer that changes the work, a design error, or an unforeseen coordination conflict. Discovery can happen in the field, in a submittal review, or in a coordination meeting.

2. Capture

   The event is logged with a date of discovery, a description, and an initial guess at cause and responsible party. The date matters more than the polish: it anchors the notice clock and establishes contemporaneity if the event is later disputed.

3. Notice

   If the contract requires written notice of changed conditions, it is issued now, referencing the change event. Teams routinely lose entitlement here by treating notice as optional or by assuming a conversation counts as notice when the contract requires writing.

4. Characterization

   The team assesses cause: is this owner-caused (added scope, design error, differing condition) and therefore compensable, or self-inflicted (means and methods, coordination failure) and therefore a cost to absorb or backcharge internally. This determination drives everything downstream.

5. Rough sizing

   A preliminary cost and schedule estimate is attached so the event can be triaged. Small, clearly self-inflicted events may be closed without pricing; owner-caused events proceed toward a PCO.

6. Conversion or closure

   Validated, compensable events convert to a potential change order for formal pricing. Events determined to be within the base scope, or not worth pursuing, are closed with a documented reason so the decision itself is on the record.

7. Linkage

   The event is linked to its source (RFI, ASI, meeting minute, daily report, differing condition photo) and to any downstream PCO, COR, or claim so that the causal chain is traceable end to end.

8. Retention

   Closed and converted events are retained as part of the project record. The complete change event log, with dates of discovery and notice, becomes primary evidence in any later delay or entitlement dispute.

Anatomy — the data it carries

Change event number

Sequential, project-unique identifier that follows the deviation through PCO, COR, and change order so the chain is never broken.

Title / description

A specific, factual statement of the deviation. Vague titles like 'field issue' make triage impossible and weaken the record if it is ever litigated.

Date of discovery

When the condition was first observed. This anchors the contractual notice clock and is the single most important date on the record.

Source / origin

What surfaced it — RFI answer, ASI, differing site condition, owner directive, coordination conflict. Determines characterization and entitlement.

Cause characterization

Owner-caused, design error, differing condition, or self-inflicted. Drives whether the event is compensable, absorbed, or backcharged.

Responsible party

Who is believed to bear the cost — owner, designer, another trade, or the contractor itself. Often revised as facts develop.

Affected scope / cost codes

The budget lines the change touches, so the eventual variance can be reconciled against the original estimate.

Preliminary cost estimate

A rough order-of-magnitude number for triage. Not a proposal, and explicitly marked as such to avoid it being read as a commitment.

Schedule impact flag

Whether the event is believed to affect critical-path activities. Preserves the time-extension argument even before it is quantified.

Notice status and date

Whether contractual notice has been issued and when. The field that most often decides entitlement in a dispute.

Linked records

RFIs, ASIs, daily reports, photos, meeting minutes, and downstream PCOs and CORs that establish the causal chain.

Status and disposition

Open, under review, converted to PCO, closed as no-change, or escalated to claim — plus the documented reason for closure.

Failure modes — how it breaks

Discovered but never logged

A superintendent knows about a differing condition for three weeks and mentions it in passing, but no change event is opened. When it finally becomes a formal claim, the notice clock has long expired and the entitlement is dead on procedure, not merit.

Work performed before the event is opened

The crew executes the extra work to keep the schedule moving, and only afterward does anyone try to reconstruct what was done. Pricing after the fact is weaker, disputed harder, and often discounted because the owner never had the chance to direct it differently.

MiScharacterized cause

A coordination failure that is genuinely the contractor's own is logged as owner-caused, or vice versa. The wrong characterization sends the event down the wrong path — pursuing compensation that will never come, or absorbing a cost that should have been recovered.

Preliminary estimate treated as a proposal

A rough triage number written on the change event gets quoted back by the owner as if it were the contractor's price. Without a clear 'rough order of magnitude, not a proposal' label, the early guess caps the eventual recovery.

Orphaned events with no downstream link

The event is opened and priced but never linked to the PCO or COR it became, so the log shows a change that appears unresolved while the money moves through a separate, disconnected record. Reconciliation at closeout becomes archaeology.

Stale open events

Events sit open for months because nobody owns the decision to convert or close them. The backlog obscures real exposure, and the owner reasonably argues that a change never pursued for six months was never a real change.

Metrics — how it is measured

Change event volume

Count and dollar exposure of events opened per period. A rising trend signals design incompleteness or scope instability before it shows up in cost.

Notice compliance rate

Share of events for which contractual written notice was issued within the required window. The metric that most directly protects entitlement.

Conversion rate to PCO

Percentage of events that advance to formal pricing. Low conversion may mean weak entitlement analysis or an owner rejecting legitimate changes.

Cycle time to characterization

Days from discovery to a documented cause determination. Long cycle times mean events sit unpriced while leverage erodes.

Open event aging

Distribution of days that events remain open and unresolved, bucketed by age. The old-and-open bucket is where recoverable cost quietly dies.

Self-inflicted share

Portion of events characterized as the contractor's own cost. A rising share points to coordination or means-and-methods problems, not owner behavior.

Exposure at risk

Total priced value of open events not yet authorized. The number a project executive needs to size unfunded work being performed on faith.

The AI shift — what actually changes

Conversational

The change event log becomes something you question rather than scroll. You ask which open events have not had notice issued and are approaching the contractual deadline, which are owner-caused but still unpriced, and which touch critical-path activities — and get answers with the source records cited, so nothing recoverable is quietly aging out.

Generative

From a field observation, a photo, and the relevant RFI or ASI, a model drafts the change event with a specific factual description, a proposed cause characterization with its reasoning, the affected cost codes, and — where required — draft contractual notice language referencing the correct clause, which the project manager reviews rather than composes from scratch.

Orchestrated

The event stops being an isolated log line. On creation it is matched to its source RFI, ASI, daily report, or differing-condition photo; the notice clock is started and tracked against the contract; the affected cost codes are validated against the budget; and when characterization confirms it is compensable, a linked potential change order is opened so cost is never separated from cause.

Autonomous

The routine motion runs unattended inside guardrails: RFI answers and ASIs that change scope automatically open draft change events, notice deadlines are monitored and escalated on the contractual clock, and events sitting open past a threshold are surfaced for decision. Humans always own characterization of cause, the issuance of notice, and any conversion that commits money or asserts entitlement.

Prompts — put it to work

Tool-agnostic and copy-ready. Adapt the specifics — thresholds, contract windows, cost codes — to your own project before you run them.

Conversational — You inherited a project mid-stream and need to know what change exposure is quietly aging.

Review our change event log. Identify every event that is (a) open longer than 30 days without conversion or closure, (b) missing contractual notice where the contract requires written notice within 14 days of discovery, or (c) characterized as owner-caused but not yet priced. For each, give me the event number, description, date of discovery, days open, notice status, characterized cause, and rough exposure. Rank by the risk of losing entitlement, and tell me which notice deadlines expire in the next 7 days.

What good output looks like: A ranked list of at-risk events with notice deadlines made explicit, separating events that are merely old from events where entitlement is about to expire — not just a table sorted by date.

Follow-ups:

• Which of these share the same root cause and could be bundled into one change order?
• Draft the notice letters for the ones whose deadline expires this week.
• What is our total unpriced owner-caused exposure right now?

Generative — An RFI answer just changed the work and you need the change event opened correctly the first time.

Draft a change event from the following facts. RFI 88 was answered directing us to use a heavier gauge stud at the level-4 demising walls than the contract documents showed; the answer arrived today. Context: this is added material and labor across roughly 2,400 linear feet, the drawings clearly showed the lighter gauge, and framing on level 4 starts in 6 working days. Write the event with a specific factual description, a proposed cause characterization with your reasoning for why this is owner or design caused, the affected cost codes for metal framing labor and material, a schedule impact flag, and draft written notice language referencing a 14-day notice requirement. Mark any cost figure as rough order of magnitude, not a proposal.

What good output looks like: A complete, dated change event with a defensible cause characterization, correct cost codes, and ready-to-issue notice language — not a generic template with blanks.

Follow-ups:

• Rewrite the notice so it preserves our time-extension rights as well as cost.
• List the source documents I should attach to make this event bulletproof.
• If the owner claims this was always our scope, what is our strongest counterargument from these facts?

Orchestrated — A batch of RFI answers and ASIs came in this week and you need to know which ones created changes.

Review every RFI answer, ASI, and coordination-meeting decision issued in the last 7 days. For each, determine whether it changes scope, cost, or schedule relative to the contract documents. Where it does, open a draft change event linked to the source record, propose a cause characterization with supporting reasoning, identify the affected cost codes, and flag whether contractual notice is required and by when. Where it does not change the work, say so and cite why. Return a single reconciliation showing every source document and its disposition, and flag anything you are uncertain about rather than guessing.

What good output looks like: A cross-referenced reconciliation of every scope-affecting document with linked draft change events, correct notice deadlines, and explicit uncertainty flags — nothing recoverable left uncaptured.

Follow-ups:

• For the compensable ones, open linked PCOs and draft the cost narratives.
• Which of these need notice issued before the weekend?
• Are any of these contradicted by an earlier RFI answer or ASI?

Autonomous — Standing policy for how the change event front-of-funnel should run itself.

Operate our change event intake continuously under these rules. On any RFI answer, ASI, or coordination decision that appears to change scope, cost, or schedule, open a draft change event linked to the source, propose a cause characterization with reasoning, identify affected cost codes, and calculate the contractual notice deadline. While open: monitor notice deadlines and escalate to the project manager at 3 days before expiry and to the project executive at 1 day; surface any event open past 30 days without disposition. Never issue contractual notice, never finalize a cause characterization, and never convert an event to a PCO or assert entitlement without my approval — route every one of those to me with your reasoning and the supporting records. Present me a short exception queue, not the whole log.

What good output looks like: A running intake process with a full audit trail where notice deadlines are never missed, but every characterization, notice, and money-committing conversion still requires a human decision.

Follow-ups:

• Show me everything you opened and everything you escalated this week.
• Which characterizations did I override, and what should you adjust?
• What is the total exposure sitting in drafts awaiting my decision?

Get the full Construction AI Prompt Catalog — every prompt in the library in one document.

Maturity — locate yourself honestly

0. Level 0 — Untracked

   Changes are discussed verbally and remembered inconsistently. There is no log, notice is routinely missed, and exposure only surfaces as unexplained cost variances months later.

1. Level 1 — Logged

   A change event register exists with dates of discovery and descriptions. Notice is issued manually and sometimes late. Characterization and pricing happen ad hoc.

2. Level 2 — Linked

   Events are connected to their source records and to downstream PCOs and CORs. Notice deadlines are tracked, cost codes are validated, and the causal chain is traceable.

3. Level 3 — Assisted

   Scope-affecting RFI answers and ASIs generate draft events automatically, cause characterizations and notice language are drafted for review, and notice deadlines are surfaced before they expire.

4. Level 4 — Operated

   Intake, linkage, notice-deadline monitoring, and triage run unattended inside guardrails, while humans own cause characterization, the issuance of notice, and any conversion that commits money or asserts entitlement.

Common questions

What is the difference between a change event and a change order?

A change event is an internal record that something may have changed; a change order is an executed contract amendment that changes the price or time. The event is neutral and unpriced, the change order is bilateral and binding. Every change order should trace back to a change event, but many change events never become change orders because they are closed as within-scope or not worth pursuing.

Why open a change event if we are not sure we will get paid?

Because the record and the notice are worth far more than the effort. Opening the event dates the discovery, satisfies most contractual notice requirements, and preserves the option to pursue compensation. If you wait until you are sure, the notice window has usually closed and the entitlement is lost on procedure regardless of how meritorious the change is.

Should self-inflicted changes get a change event too?

Yes. Capturing self-inflicted changes is how you understand true project cost, quantify the impact of your own coordination or means-and-methods decisions, and — where another trade caused it — support a backcharge. Only logging owner-caused changes gives you a distorted, one-sided view of what is actually driving cost.