Change-order tracker — every PCO and CO with cost + schedule impact

AEC change-order tracking. Auto-classified COs and PCOs land here with signed cost + schedule impact; pipeline vs. executed totals roll up automatically.

Updated 2026-04-27

Change orders (and their pre-execution cousin, the Potential Change Order or PCO) are the highest-dollar artifacts on a construction project. /change-order-tracker is the third AEC daily-action surface alongside /rfi-tracker and /submittal-tracker — same architecture, different artifact.

**The flow:**

1. Owner or design team requests a change (or contractor identifies a field condition / impact). 2. Contractor packages a PCO with proposed cost + schedule impact. 3. Kodori's auto-classifier flags the doc as a change order (regex matches "change order", "PCO", "potential change order", "construction change directive", "CCD" — and excludes logs / registers / templates). 4. The extract-change-order Inngest function pulls structured fields via Haiku — CO number, subject, project ref, spec section, originator, approver, signed cost impact (additive vs deductive), schedule impact in days, reason category, dates, and signature status. 5. Row lands on /change-order-tracker for the project team. Once a fully-executed copy is uploaded, the status flips to executed and the cost moves from the pipeline aggregate to the executed aggregate.

**What you'll see on /change-order-tracker:**

- **Five status counters** — Pending, PCO, Overdue signature, Executed, Rejected. - **Cost impact aggregates** — executed total vs pipeline total, with red for additive (cost adds) and emerald for deductive (savings / credits). Real construction change orders include both additive and deductive line items; the projection table stores cents as a signed bigint and the UI uses signed +/− prefixes throughout. - **Schedule impact aggregates** — executed days vs pipeline days, same sign convention. - **Top reason categories** — owner request, design change, field condition, RFI response, code requirement, weather impact, schedule extension, value engineering, scope clarification, errors and omissions, or other. Project teams see at a glance whether the pipeline is dominated by owner scope changes vs. design errors — direct input to claim-prep and root-cause conversations. - **Per-bucket sections** — Pending → PCO → Extraction failed → Recently executed → Rejected. PCOs older than 14 days highlight as "overdue signature" so they can't quietly age past the contract notice window.

**Status lifecycle:**

- *pending* — extracted, no signed/executed signal yet, not classified as a PCO. - *pco* — extractor identified the doc as a Potential Change Order (pre-execution proposal). Older than 14 days flags as overdue. - *executed* — fully signed by the parties; cost + schedule impact lock in. - *rejected* — owner / GC declined; archived to the rejected bucket but kept for audit. - *extraction-failed* — Haiku couldn't pull a usable subject + CO number; surfaces for human fill-in.

**Why this matters.** Most firms maintain a "change order log" spreadsheet by hand — every PCO entered twice, drift between the log and the actual signed PDFs, no audit trail. /change-order-tracker is the spreadsheet replaced: every PCO and CO in the workspace surfaces here automatically, the pipeline vs executed totals tie back to the source documents, and the audit log records every status transition.

**Coming next:** linking executed CO documents back to their originating PCOs (so the page can show the round-trip pricing journey); RFI → CO causation (when a CO ties to an RFI response, surface the linkage on both pages).