9.3 Record Drawing Updates After Changes

9.3 Record Drawing Updates After Changes

Quick Answer: Whenever the installed or programmed system no longer matches the site record set, update the records. That includes device adds/moves/removals, pathway or circuit changes, and zone/matrix programming changes. Use red-lines in the field, revision clouds and revision blocks on formal drawings, and software backups with version IDs for configuration. Level II technicians own accurate markups and honest communication—not silent “it works now” changes.

Section 5.2 covered as-builts at original acceptance. Domain 2.2.3 returns to drawings because maintenance years are when records decay: renovations, tenant fits, NAC boosters, detector replacements with different addresses, and “quick” program edits. A system can still alarm while its drawings lie.

Why Post-Acceptance Drawing Control Matters

Record drawings drive:

• Periodic testing routes and device inventories
• Impairment scope (“which devices are on this circuit?”)
• Emergency responder understanding of FACU zones and building layout relationships
• Future design work and AHJ reviews for modifications
• Battery and voltage-drop validity when loads move or grow

Scenario: A tenant build-out adds eight notification appliances on NAC-2 and relocates four smokes. Nobody updates drawings or battery calcs. Two years later annual testing misses two new appliances hidden above a new cloud ceiling, and a battery replacement undersizes secondary power because the calc still shows the old load.

When As-Builts / Record Drawings Must Be Updated

Use this trigger table. If the field or program changed in a way that affects location, circuiting, or operational understanding, mark it.

Device adds, moves, and removals

Any physical device change that would mislead a tester using the old plan requires a mark. Relocations of a few feet still matter when ceiling clouds, hard lids, or room numbers change search patterns. Removals without drawing updates create “ghost devices” that inflate test scope and hide unauthorized deletions of required coverage.

Pathway changes

Cable reroutes, added T-taps (where permitted by design/class), isolator additions, conduit pathway moves for survivability, and EOL relocations belong on risers and critical plan notes. Survivability-level pathways are especially sensitive: a “temporary” sleeve through a nonrated path that becomes permanent is both a code and documentation problem.

Programming and zone changes

Not every soft edit needs a new architectural floor plan, but operational records must track:

• Zone/partition renumbering
• Label changes that AHJs and responding firefighters rely on
• Cause-and-effect matrix changes (which inputs drive which outputs)
• Network node maps on networked systems

If the annunciator LED formerly labeled “Floor 3 West” now means a different geographic area after a remodel, the zone map is wrong even if no smoke moved.

Exam trap: Believing “as-built updates only apply at original CO.” Maintenance-era changes create the same need for truth in drawings and configuration records.

Red-Line Practices

Red-lines are immediate field markups on a controlled print or electronic markup layer. Discipline:

1. Mark as you go, not at demobilization from memory.
2. Use consistent symbols: add, delete (X with cloud), relocate (arrow from old to new), note circuit IDs.
3. Initial and date each significant markup set.
4. Keep red-lines in a known place (job folder / site cabinet “working set”) until formal revision.
5. Never have three conflicting red-line sets with no “current” designation.

Red-lines are temporary control, not a permanent excuse to avoid issuing a revised record set. For small service work, a clearly revised single-line plan and updated schedule in the site cabinet may be enough under the contract; for larger mods, formal shop revision and AHJ re-submittal may be required. Level II technicians follow the project’s document-control process and escalate when scope exceeds markup-only authority.

Revision Clouds and Revision Blocks

When drawings are formally revised:

• Revision clouds (and deltas) highlight what changed so reviewers do not re-read the entire sheet blindly.
• Revision blocks record revision number/letter, date, description (“Add 6 speakers Area B; update NAC-2”), and approver as required by the firm’s CAD standards.
• Superseded sheets are marked obsolete so the site cabinet does not contain two “current” Floor 2 plans.

Scenario: Contractor issues Rev C with clouds around new devices but leaves Rev B unmarked in the FACU cabinet. An ITM tech uses Rev B and fails to test new appliances. Document control failed even though Rev C existed in email.

Site set rules of thumb:

1. One current record set at the approved location.
2. Obsolete prints removed or boldly stamped SUPERSEDED.
3. Electronic folders use clear names (Record_FireAlarm_Floor2_RevC_2026-08-05.pdf).
4. Owner receives the current set, not only the installing salesperson.

Software Configuration Backups & Version Control

Modern systems are software-defined. Drawing updates without program control still leave a hole.

What to capture after programming changes

Level II version-control habits

1. Before editing, save a pre-change backup labeled with date and reason.
2. After editing, save a post-change backup; confirm the panel shows the new revision identity.
3. Retest affected cause-and-effect rows (and document the retest—Section 9.2).
4. Update sequence-of-operation sheets when matrix behavior changed.
5. Store backups with the owner package and company file—not solely on one laptop.
6. Do not “borrow” passwords in ways that leave the system without an authorized access path for the responsible party.

Trap: Restoring an old backup to clear a trouble and accidentally rolling back a year of legitimate zone changes—without comparing revision IDs first.

Trap: Changing elevator recall groups in software while floor plans and firefighter instructions still show the old primary floor narrative.

Level II Role Boundaries

Ethics alignment: falsified as-builts are as serious as falsified test reports. Both mislead emergency response and future maintenance.

Practical Closeout Checklist After a Change Order / Service Modification

1. Complete physical and programming work; clear unintended troubles.
2. Functionally retest affected devices and interfaces; record results.
3. Red-line plans/risers/schedules the same day.
4. Export software backup; record revision ID on the job ticket and site log.
5. Revise battery/VD calcs if loads or cable lengths changed materially.
6. Issue formal drawing revision per company/AHJ process; replace site set.
7. Brief owner on new zone labels, bypasses, or operational differences.
8. File ITM/modification report with cross-references to the new revision.

Exam Focus

Choose answers that update drawings and software records whenever the field or matrix changes, use red-lines then controlled revisions, and treat versioned backups as mandatory after programming edits. Reject “maintenance never touches as-builts,” “panel labels alone replace drawings,” and “old backup is fine without revision identity.” Silent changes are documentation failures even when the horn still sounds.