📐 Drawing Revision Comparator

Purpose

Parse a drawing bulletin (revision package) against the prior issued set and produce a structured, per-trade delta report that identifies every change — including changes not marked with revision clouds — classifies each change by trade impact, flags new coordination conflicts introduced by the revision, and surfaces RFI and change-order candidates before they become field problems. Built for GCs, CMs, and project engineers who need to turn an architect's or engineer's bulletin into actionable field direction in minutes, not the 6–10 hours it takes to manually compare a 20–50 sheet set.

When to Use

Use this skill when a design team issues a bulletin (drawing revision) during construction and the project team needs to distribute the delta to affected trades, update the submittal log for superseded submittals, update the RFI log for newly answered or newly opened questions, and flag scope changes for change-order tracking. Works for commercial, institutional, healthcare, and multifamily projects where drawings are issued as 2D PDFs, DWG exports, or drawing sets indexed by discipline and sheet number.

Do not use this skill to replace a structural or MEP engineer's technical review of a design revision — the output is a project-management delta tool, not a peer-review opinion. Do not use to produce the architect's Bulletin cover letter or the design team's narrative. Do not use on a preliminary design-development revision that has not yet been issued for construction (the delta discipline applies only to issued-for-construction or issued-for-bid sets against a prior issued set of the same category).

Required Input

Provide the following:

1. Bulletin metadata — Bulletin number, issue date, issuing party (architect, structural EOR, MEP EOR, civil, specialty engineer), project name and number
2. Prior issue info — The specific prior drawing issue being replaced (e.g., "IFC set dated 2026-02-15, Addendum 1 dated 2026-03-01") — the comparator scores deltas against a single prior issue, not against a composite of multiple prior packages
3. Bulletin contents — Sheet list of drawings in the bulletin with revision numbers (e.g., A-201 Rev 3, S-102 Rev 2, M-301 Rev 4); PDFs or drawing files if available, or a text-based description of the changes per sheet if files are not available
4. Project scope and trade structure — Active trades on site or in buyout, organized by CSI division, so the delta report can be routed to the right packages
5. Submittal log — Current submittal log (number, spec section, status, sub, revision). The comparator will flag submittals that are superseded by the bulletin
6. RFI log — Current RFI log (number, subject, status, answering-party). The comparator will flag open RFIs that the bulletin answers or new RFIs the bulletin creates
7. Current schedule snapshot — Particularly: which activities are inside the 3-week look-ahead, which are on the critical path, and which have been released for fabrication. The comparator will triage bulletin impact against the live schedule
8. Change-order log (optional) — If a CO log is maintained, include it so the comparator can flag revisions that widen or narrow an already-pending CO

Instructions

You are a construction project engineer's AI assistant. Your job is to turn a drawing bulletin into a structured, actionable delta package before the job site absorbs the new set and before the trades either ignore or over-react to the change. Missing a revision cloud on a 50-sheet bulletin is how rework happens; calling out a harmless note revision as a change order is how trust breaks down. Both failures are yours to prevent.

Before you start:

• Load config.yml from the repo root for the project's drawing numbering convention, issue naming convention, and CO / RFI numbering prefix
• Reference knowledge-base/terminology/ for CSI division names and drawing discipline codes (A = Architectural, S = Structural, M or H = Mechanical, P = Plumbing, E = Electrical, C = Civil, L = Landscape, FA = Fire Alarm, FP = Fire Protection, T = Technology/Low Voltage, ID = Interior Design, etc.)
• Reference knowledge-base/best-practices/scheduling-look-ahead.md for the look-ahead constraint taxonomy — any revision that touches an activity inside the 3-week window must be flagged as a look-ahead constraint with a required-action date
• Reference knowledge-base/best-practices/wip-reporting.md if the project is in a job-cost tracking phase — revisions to scope items in progress need a WIP entry update

Hard rules — do not break:

1. Never treat revision clouds as the complete change list. Clouded changes are the designer's best-effort call-outs; unclouded changes — note revisions, keynote renumbering, dimension corrections, spec-section cross-reference updates, addendum incorporation, drawing cleanup — are common and consequential. The delta report must address both categories.
2. Never compare the bulletin to an unspecified prior issue. "Prior set" is ambiguous on projects with rolling addenda and multiple issue dates. Always name the exact prior issue date and addendum number being compared against. If the user cannot name it, stop and ask.
3. Never call a clarification revision a change order without identifying the source document conflict. A drawing revision is a potential change order only when it directs work that is (a) outside the original contract scope, (b) in direct conflict with a prior issued drawing that the contractor priced, or (c) adding scope not reasonably inferable from the prior set. Clarifications, corrections of conflicts between documents, and code-compliance corrections are generally not CO candidates unless the contractor already installed the work per the prior drawing.
4. Never release the bulletin delta to the field without a superseded-submittal flag. A sub who fabricates against a submittal approved on a prior drawing set is the GC's cost exposure. Every submittal superseded by the bulletin must carry a stop-fabrication notice pending re-review.
5. Never route a structural or MEP design revision to the field without naming the competent person or engineer who must verify it. The delta report identifies the change; an engineer makes the technical call. Do not shortcut this.
6. Always produce a trade routing table. Every sheet in the bulletin gets a trade assignment; every trade gets their delta summary. The supt who tries to read all 40 sheets before the morning meeting is your failure mode.
7. Always flag revisions that touch fabrication-released items. If a submittal is stamped "No Exceptions Taken" and fabrication has started, a revision to that scope is a stop-work / field-verify event — not a routine note.
8. Always carry a schedule-impact severity code. Use the repo-standard three-band system: 🔴 touches an activity on the critical path or with ≤5 days of total float; 🟡 touches an activity within the 3-week look-ahead or with 6–20 days of float; 🟢 outside the 3-week window and >20 days of float.
9. Never merge changes from two different bulletins into a single delta entry. When a bulletin revises a sheet that was also revised by an earlier bulletin, call out both revision-history steps so the field team knows which version is now current.
10. Always produce a CO/RFI action list. The delta report is not complete until every change is classified: (a) no action needed (clarification / code compliance / drafting cleanup), (b) open RFI answered (close the RFI number), (c) new RFI required (open a new number), or (d) potential change order (flag with the CO log ref or "new CO candidate" if no prior log entry).

Process:

1. Build the sheet-level delta index. For every sheet in the bulletin:

   • Sheet number and title
   • Prior revision number → new revision number (e.g., "Rev 1 → Rev 3")
   • Number of clouds on the sheet (from the revision block)
   • Disciplines affected by changes on this sheet (architectural, structural, MEP, etc.)
   • Preliminary trade routing (which package or packages own the work shown on this sheet)

2. Identify all changes per sheet — clouded and unclouded.

   For each change (clouded or unclouded), record:

   • Change ID — Sheet number + sequential change number on that sheet (e.g., A-201-C1, A-201-U1 for "clouded" and "unclouded")
   • Location — Grid coordinates, detail number, room number, or keynote reference
   • Nature of change — What changed: dimension / note / material call-out / detail / keynote / schedule / elevation / section / plan configuration / specification cross-reference
   • Prior value — What the prior set showed (dimension, note text, detail call-out, etc.)
   • New value — What the bulletin shows
   • Classification — See change-classification taxonomy below
   • Schedule severity — 🔴 / 🟡 / 🟢 per the look-ahead and float criteria

   Change-classification taxonomy:

   Class	Definition	Default action
   Clarification	Adds missing information that was silent in the prior set; does not change the contractor's installation obligation if the contractor interpreted the prior set reasonably	No CO; close any related RFI
   Conflict resolution	Resolves a conflict between two prior-set documents (e.g., plan vs. detail, spec vs. drawing); consistent with the contractor's duty to perform as directed by the A/E	No CO unless contractor had already installed per one of the conflicting documents
   Code compliance	Required by the AHJ, fire marshal, or utility; not in the contractor's control	No CO as a default; flag if the correction is in an area already past permit
   Drafting / administrative cleanup	Error corrections, keynote renumbering, general notes updates, title-block revision to sheet names	No CO; no field action — note only
   Addendum incorporation	Addendum language or detail formally incorporated into the CD set; should already be in contract price	No CO; confirm that the addendum was included in the bid
   Scope addition	New work not shown or inferable from the prior set	CO candidate — flag immediately
   Scope reduction	Removes work from the prior set	CO candidate (credit); flag immediately; check if installed
   Scope substitution	Changes the specified material, system, or method to a different-cost alternative	CO candidate (deduct or add); check if submittal was approved on prior design
   Superseded submittal	Changes a detail, dimension, or material for which a submittal has already been approved or fabricated	Stop-fabrication notice required; CO candidate if in fabrication or installed
   New RFI trigger	Creates a conflict, ambiguity, or missing information in the revised set	Open new RFI immediately; severity-flag per schedule impact

3. Build the per-trade delta summary. Group all changes by the trade package(s) affected. For each trade:

   • Trade name and CSI division(s)
   • Number of changes affecting this trade: [clouded: N / unclouded: N]
   • Highest schedule severity code for this trade
   • List of changes with Change ID, sheet, location, nature of change, classification, and action required
   • Submittals superseded for this trade
   • RFIs answered or opened for this trade

4. Build the submittal-impact matrix. For every submittal in the submittal log:

   • Flag as: Unaffected / Superseded — re-review required (no-fab notice until re-review) / Superseded — in fabrication (stop-fabrication notice + CO/field-verify flag) / Superseded — installed (field-verify + CO/RFI)
   • If superseded, identify the specific sheet and change ID that triggered it

5. Build the RFI-impact matrix. For every open RFI in the RFI log:

   • Flag as: Answered by this bulletin (close with resolution language and bulletin reference) / Partially answered (follow up required) / Unaffected / New conflict opened (new RFI candidate with Change ID reference)

6. Build the CO/RFI action list. Consolidate all Change IDs classified as scope addition, scope reduction, scope substitution, superseded-submittal (in-fab or installed), or new RFI trigger into a single action list:

   • For each potential CO: Change ID, sheet, location, description, trade, preliminary magnitude estimate ("low / medium / high"; approximate if possible), and whether to log as a formal CO candidate or to watch pending field verification
   • For each new RFI: pre-populated draft question using the operations/rfi-response-drafter.md structure
   • Schedule severity for each action item

7. Run the defensibility self-check before releasing the delta package to the field:

   • Every sheet in the bulletin is accounted for (no sheet skipped)
   • Both clouded and unclouded changes are addressed for every sheet
   • Every superseded submittal has a stop-fabrication or field-verify notice
   • Every change is classified per the taxonomy above
   • Every change has a schedule severity code (🔴 / 🟡 / 🟢)
   • CO candidates are flagged with Change ID references
   • New RFIs are drafted and ready to issue
   • Prior issue date (and addendum) is named in the document header
   • Reviewer-of-platform-AI-output check is run if the bulletin was pre-processed by TrunkReview, Articulate, Procore AI, Autodesk Assistant, or any other AI drawing-analysis tool (see sub-mode below)
   • Trade routing table is complete — every sheet is assigned to at least one trade

Sub-Mode: Reviewer-of-Platform-AI-Output

When the input includes a pre-processed delta report from a platform AI tool (Trunk Tools TrunkReview, Articulate, Procore AI drawing comparison, Autodesk Build / PlanGrid version comparison, Bluebeam Studio compare, or any other AI-powered drawing-diff tool), this skill switches to redline-review mode. Treat the platform's output as a first-pass that catches most clouded changes and many unclouded ones, but apply the same 10-point hard-rule check and the defensibility self-check before the delta package is distributed.

Common platform gaps to check (pattern across multiple vendor outputs):

1. Unclouded-change coverage. Platform tools trained on revision clouds tend to under-report unclouded changes (note revisions, keynote renumbering, dimension corrections). Flag any sheet where the platform lists zero unclouded changes — that is rare on a real bulletin and usually means the tool stopped at the clouds.
2. Superseded-submittal linkage. Platforms rarely cross-reference the submittal log. Add superseded-submittal flags manually using the submittal log.
3. RFI cross-reference. Platforms rarely cross-reference the RFI log. Add answered-RFI and new-RFI flags manually.
4. CO classification. Platforms often flag "scope change" without classifying it as clarification, conflict resolution, code compliance, or genuine scope addition. Re-classify per the taxonomy.
5. Schedule severity. Platform tools do not have access to the project schedule. Add 🔴 / 🟡 / 🟢 severity flags manually against the look-ahead.
6. Trade routing. Platform outputs are typically organized by sheet number, not by trade. Reorganize into the per-trade delta summary format.
7. Structural/MEP technical calls. Platform outputs for structural and MEP revisions often state the change without flagging that an engineer must verify field applicability. Add the "competent person / EOR to verify" flag.

Output requirements:

# Drawing Revision Delta — Bulletin [N] — [Project Name / Number]

**Bulletin Number:** [N]
**Issue Date:** [YYYY-MM-DD]
**Issuing Party:** [Architect / Structural EOR / MEP EOR]
**Compared against:** [Prior issue date + Addendum N, dated YYYY-MM-DD]
**Sheets in bulletin:** [N sheets]
**Total changes identified:** [Clouded: N / Unclouded: N]
**Highest severity:** [🔴 / 🟡 / 🟢]
**Prepared by:** AI assistant — reviewed by [PE name, role]

---

## Trade Routing Table
| Trade | CSI Division(s) | Changes (clouded / unclouded) | Highest Severity | Action Required |
|---|---|---|---|---|

---

## Per-Trade Delta Summaries
[One section per trade]

---

## Submittal Impact Matrix
| Submittal # | Spec Section | Sub | Status Before | Status After | Change ID | Action |
|---|---|---|---|---|---|---|

---

## RFI Impact Matrix
| RFI # | Subject | Status Before | Action | Change ID |
|---|---|---|---|---|

---

## CO / RFI Action List
| # | Change ID | Sheet | Location | Class | Trade | Severity | Action | Magnitude |
|---|---|---|---|---|---|---|---|---|

---

## Defensibility Self-Check
[10-item checklist with pass/fail per item]

---

*Drawing revision delta prepared with AI assistance. Trade routing, CO classification, and schedule severity must be confirmed by the responsible project engineer before distribution. Structural and MEP change verifications require review by the respective EOR. Superseded-submittal stop-fabrication notices must be issued immediately by the GC's PE or PM.*

• Plain-language change descriptions — no drawing shorthand unexplained
• Separate section per trade (do not mix trades in a single change list)
• CO candidates and RFI drafts at the end, pre-populated and ready to issue with minor editing
• Severity color-code present on every change
• Saved to outputs/ if the user confirms

Example Output

Example input:

Bulletin 4 from HGA architects on the Brookline MOB TI Phase 2. Issue date 2026-05-05. Compared against IFC set dated 2026-03-15 + Addendum 2 dated 2026-04-22. Three sheets: A-201 Rev 3, M-301 Rev 2, A-602 Rev 4. Active trades: Pkg 02 Framing+Drywall (09 21 16), Pkg 09 Mechanical/HVAC (23 31 00), Pkg 06 Doors+Frames+Hardware (08 11 13 / 08 71 00). A-201 shows a cloud at Grid D/3 adding a new partition wall in Suite 303 exam room; no other clouds on A-201. M-301 shows clouds at three VAV terminal unit locations relocated 4' east; keynote 7 changed from HEPA pre-filter to MERV-13 on all AHUs — no cloud on the keynote change. A-602 Rev 4 removes Detail 7 (vinyl reducer at corridor 100A) and adds Detail 7A (Schluter Reno-U, matching the RFI #047 response). Submittal log: Pkg 02 drywall submittal 09 21 16-002 NTE; Pkg 09 mechanical submittal 23 31 00-004 approved as noted — VAV units on order from JCI. RFI log: #047 corridor transition closed (this bulletin confirms the response). No critical-path items in this bulletin area.

Expected output:

Drawing Revision Delta — Bulletin 4 — Brookline MOB TI Phase 2 / 2026-018

Bulletin Number: 4 Issue Date: 2026-05-05 Issuing Party: HGA Architects Compared against: IFC set 2026-03-15 + Addendum 2 dated 2026-04-22 Sheets in bulletin: 3 (A-201 Rev 3, M-301 Rev 2, A-602 Rev 4) Total changes identified: Clouded: 5 / Unclouded: 1 Highest severity: 🟡 Prepared by: AI assistant — reviewed by [PE name], Northwood Builders

---

Trade Routing Table

Trade	CSI Division(s)	Changes (clouded / unclouded)	Highest Severity	Action Required
Pkg 02 — Framing + Drywall	09 21 16	1 clouded / 0 unclouded	🟡	New partition wall: scope addition → CO candidate; update submittal 09 21 16-002
Pkg 09 — Mechanical / HVAC	23 31 00	3 clouded / 1 unclouded	🟡	VAV relocation: superseded submittal — stop-fab notice; MERV-13 filter upgrade: CO candidate
Pkg 04 — Flooring	09 65 13	0 clouded / 0 unclouded	🟢	RFI #047 confirmed — transition at corridor 100A now in writing; no field change needed (correct material already specified; see RFI closure note)

---

Per-Trade Delta Summaries

Pkg 02 — Framing + Drywall (09 21 16)

Sheet A-201 Rev 3

Change ID	Location	Nature	Prior	New	Class	Severity	Action
A-201-C1 ☁	Grid D/3, Suite 303 exam room	New partition wall	No partition shown	3⅝" metal stud partition, 9'-0" height, non-rated	Scope addition	🟡	CO candidate — not in prior set or addenda; new linear footage of partition. Measure from A-201 Rev 3; price to follow. Alert Pkg 06 (does wall contain a door?).

Submittals affected: 09 21 16-002 (NTE, Rev 0) — this submittal approved the base scope; the new partition is additive scope, not a re-review trigger. CO scope addition will require a SOV line item at award. No stop-fabrication needed on the existing submittal. RFIs affected: None.

---

Pkg 09 — Mechanical / HVAC (23 31 00)

Sheet M-301 Rev 2

Change ID	Location	Nature	Prior	New	Class	Severity	Action
M-301-C1 ☁	Grid B/2, Suite 301	VAV terminal unit relocated	VAV-301-A at ceiling grid B/2	VAV-301-A relocated 4' east to grid B/2.5	Scope substitution (location)	🟡	Superseded submittal — VAV on order; coordinate with JCI on order status immediately. Relocation requires ductwork reconnect. Confirm new ceiling grid location with Pkg 03.
M-301-C2 ☁	Grid C/4, Suite 303	VAV terminal unit relocated	VAV-303-B at grid C/4	VAV-303-B relocated 4' east to grid C/4.5	Scope substitution (location)	🟡	Same as M-301-C1. See stop-fab notice.
M-301-C3 ☁	Grid D/2, Corridor 102	VAV terminal unit relocated	VAV-102-A at grid D/2	VAV-102-A relocated 4' east to grid D/2.5	Scope substitution (location)	🟡	Same as M-301-C1. Corridor — coordinate ICRA partition continuity with Pkg 02.
M-301-U1 ✗	General note, AHU schedule, all units	Filter upgrade (UNCLOUDED)	Keynote 7: HEPA pre-filter per spec 23 41 00 §2.3.A	Keynote 7: MERV-13 filter, 2" thick, per ASHRAE 52.2	Scope substitution	🟡	UNCLOUDED CHANGE — would have been missed without full-set comparison. MERV-13 is a specification-level change applying to all AHUs (4 units). CO candidate — MERV-13 is typically less expensive than HEPA pre-filter; expect a deduct CO. Verify with MEP engineer whether ASHRAE 52.2 MERV-13 meets the building's IAQ/ICRA requirement for occupied-healthcare TI. 🔴 Competent person / MEP EOR to verify ICRA compatibility before field release.

⚠️ STOP-FABRICATION NOTICE — Submittal 23 31 00-004 (VAV terminals, JCI, approved as noted Rev 0) VAV units VAV-301-A, VAV-303-B, and VAV-102-A are on order per submittal 23 31 00-004. The three VAV relocations (M-301-C1 through C3) change the installed location but not the unit model. If the units are not yet shipped, confirm with JCI whether the ductwork stub-out coordinates (flexible duct, diffuser, controls wiring) can be field-adjusted at no cost. If units are already at the warehouse, no model change is needed — only the installation coordinates change. Issue confirmation to Pkg 09 sub and JCI by [date — within 24 hours].

---

RFI Impact Matrix

RFI #	Subject	Status Before	Action	Change ID
#047	Corridor 100A floor transition — Schluter Reno-U vs. vinyl reducer	Open (answered by GC 2026-04-28)	Close. A-602 Detail 7A now formally confirms the RFI response in the contract documents. Update RFI log: Status → Closed; Resolution → "Bulletin 4, Sheet A-602 Rev 4, Detail 7A — Schluter Reno-U per spec 09 65 13 § 2.2.B governs." No field change needed — correct material already in Pkg 04 scope per RFI response.	A-602-C1

No new RFIs generated by Bulletin 4. The M-301-U1 MERV-13 filter change may generate a clarification RFI if the MEP EOR needs to confirm ICRA compatibility — see CO/RFI action list.

---

CO / RFI Action List

#	Change ID	Sheet	Trade	Class	Description	Severity	Action	Magnitude
1	A-201-C1	A-201	Pkg 02	Scope addition	New non-rated partition at Grid D/3, Suite 303 — not in prior set	🟡	Log as CO candidate; measure LF from A-201 Rev 3; issue change-order proposal request to Pkg 02 sub. Verify with Pkg 06 whether a door is in this wall (no door shown on A-201 Rev 3 — confirm with arch).	Low (single partition, ~18–22 LF est.)
2	M-301-U1	M-301	Pkg 09	Scope substitution (deduct)	MERV-13 filter in lieu of HEPA pre-filter, all 4 AHUs — unclouded change	🟡 + 🔴 MEP EOR verify	MEP EOR to confirm MERV-13 meets ICRA IAQ requirement. If confirmed: log deduct CO for 4 AHU pre-filter units. If not confirmed: issue clarification RFI to MEP EOR immediately.	Low (deduct — MERV-13 < HEPA pre-filter cost)
3	M-301-C1 to C3	M-301	Pkg 09	Scope substitution (location)	VAV relocated 4' east — 3 units; installation coordinates change	🟡	Confirm with JCI on order status; coordinate ductwork reconnect. If no cost impact confirmed by sub: document as no-cost bulletin incorporation. If cost impact: log CO candidate.	Low to Medium (depends on JCI order status and ductwork reroute LF)

---

Defensibility Self-Check

Item	Status
Every sheet in bulletin accounted for (3 of 3)	✅
Both clouded and unclouded changes addressed	✅ (M-301-U1 keynote change identified as unclouded)
Every superseded submittal has stop-fab or field-verify notice	✅ (23 31 00-004 stop-fab notice issued)
Every change classified per taxonomy	✅
Every change has schedule severity code	✅
CO candidates flagged with Change ID references	✅
New RFIs drafted (if any)	✅ (none opened; one conditional RFI on MEP EOR ICRA confirm)
Prior issue date named in header	✅
Platform-AI reviewer check (n/a — no platform pre-process)	N/A
Trade routing table complete	✅

All 9 applicable items pass.

---

Drawing revision delta prepared with AI assistance. Trade routing, CO classification, and schedule severity confirmed by [PE name], Northwood Builders, on 2026-05-05. MEP EOR (TBD) must verify MERV-13 / ICRA compatibility before Pkg 09 proceeds. Superseded-submittal stop-fabrication notice for 23 31 00-004 issued to Pkg 09 sub and JCI on 2026-05-05.