14.4 Punch Lists, As-Builts, Config Management & End-User Training

A SAT that passed on Tuesday can still become an unmaintainable system on Monday if nobody owns the remaining defects, the drawings still show the schematic bubbles, the only copy of the rule set lives on a technician’s laptop, operators were shown a demo instead of their consoles, admin is still admin, and the spare reader on the shelf is a different firmware generation. Independent OpenExamPrep teaching for published PSP Domain 3 Task 3 knowledge treats punch lists, as-builts, configuration management, end-user training, password handoff, and spare-parts turnover as part of acceptance, not as courtesy paperwork after the banner comes down.

Punch lists: who owns them, and what close-out evidence is

A punch list (deficiency list, snag list) is the dated register of work that is not complete or not conforming, classified so life-safety items cannot hide among paint chips. Typical classes: A life-safety or security-critical (blocks acceptance—see 14.3), B functional but not immediately dangerous, C cosmetic or documentation. The list is generated from SAT fails, inspections, and owner comments inside the contract’s window—not from an infinite hallway of new wishes after the testers leave.

Who owns what matters on the exam. The owner (or the designated representative: program manager, security director, construction manager acting for the owner) owns the list as the acceptance record. That person decides, within the contract, what remains, what is waived in writing, and when the list is closed. The contractor owns performing the work and producing evidence that each item is closed. The designer (or commissioning authority) verifies that the closure matches the specification, not that a friendly email said “fixed.” The installing technician does not get to privately decide which items to ignore. Substantial completion does not make the list vanish.

Close-out evidence is specific: retest script initials for a functional fail, a photograph of a firestop with the listed system identifier, a serial number of a replaced reader, an updated map screenshot for a wrong device ID, a torque log if torque was the defect. “Done” in a chat thread is not evidence. Items that cannot be evidenced stay open. Recurring fails of the same typical should reopen the typical, not generate twenty one-off chats.

Worked clinic: forty punch items. Three are maglock release and a missing firestop (class A). Thirty are labels and a scratched housing (class C). Seven are map IDs (class B). Signing final acceptance because “only three are left” without saying those three are class A is how occupancy inherits a trap. Close A first. Record B closures with screenshots. Let C ride only if the contract allowed a retainage walk.

As-builts and configuration management

As-built drawings are the record of what was actually installed after RFIs, change orders, and field routing. Red-line markups on the issued set become record drawings: device IDs, homerun paths, panel locations, lock-power sources, and interfaces. If the SAT used Door 4 but the record drawing still shows a schematic bubble in the wrong alcove, the next technician will service the wrong opening. As-builts are a specification deliverable, not a favor.

Drawings are not enough. Configuration management is the electronic twin: the settings that make the hardware behave. Minimum turnover for an electronic security system usually includes:

• IP tables (and VLAN, gateway, DNS) for every networked camera, controller, encoder, workstation, and server, with MAC addresses and host names that match labels.
• Reader and panel firmware versions, and the rule that spares must match or be upgraded under change control.
• Rule sets: access levels, schedules, holidays, anti-passback, alarm priorities, camera call-up, video retention, and notification paths.
• Encryption keys, certificate thumbprints, and OSDP secure-channel status where used.
• Backup/restore procedure and the last successful backup location.

A GUI that “looks right” is not that package. If the only copy of the rule set is on the integrator’s laptop, the owner does not own the system. After acceptance, changes to rules, firmware, and addressing go through change control: who may edit, what is tested after an edit, and how the as-built package is updated. Uncontrolled “just this door for the VP” edits are how anti-passback dies in a week.

End-user training: operators, technicians, escorts

End-user training is role-specific. One lunch-and-learn for executives does not train the people who will live with the alarms.

SOC operators need the workflow commissioned in 14.2: recognize priority, find the map device, use camera call-up, acknowledge, dispatch, and know when an event is life-safety versus nuisance. They need the playbook on their console, not a slide deck they saw once. Include night-shift operators, not only day supervisors who will not be there at 02:10.

Maintaining technicians (in-house or contracted) need admin functions the operators should not have: backups, firmware policy, reader substitution, door schedule edits under change control, and how to restore a panel without wiping the database. They need the as-built package and the IP table. They do not need a sales tour of features the site did not buy.

Escorts, badging, and enrollment staff need credential lifecycle: encode, issue, revoke, visitor vs employee, construction vs production badges in a phased building, and what to do when a card fails at the reader. Escorts who “only walk people” still control tailgating and visitor credentials; if they are untrained, the ACS is a theater around an open lobby.

Record attendance, curriculum, and residual materials (short job aids, not a 400-page manual nobody will open). Specified training hours in the contract are a deliverable. If the specification required eight hours of operator training and the integrator provided a 20-minute demo, training is an open punch item—not a personality conflict.

Admin passwords and spare parts

Factory-default passwords on VMS, ACS, network switches, and camera web pages are a known-exploit path and a commissioning fail. Change them before final acceptance. Document the new credentials in a controlled handoff: sealed envelope to the owner’s security and IT custodians, password vault, split knowledge if the owner requires two people—not a sticky note on the SOC monitor, not a default left “so the next shift can guess,” and not a password emailed to a personal account. Service accounts used by the integrator should be revoked or time-bounded at turnover so former technicians do not keep god-mode after the contract ends.

Spare parts turnover is the specified extra materials: readers, strikes or maglock kits the spec named, power-supply modules, a camera of each typical, licenses if the spec required attic stock, and firmware-matched units. Leftover scrap in the van, a different generation of reader, or a camera without a license is not attic stock. Inventory the spares against the specification list, tag them, and store them where the owner’s technicians can find them—not in the integrator’s warehouse two states away “until you need them.”

Close-out is how the SOC still works when the people who installed it are on another job. If the owner cannot restore a panel, revoke a badge, or replace a reader without calling a cell phone that may not answer, you handed over equipment. You did not hand over a system.

Treat the diagram as a completeness check at the acceptance meeting. If any box is missing, the owner is still renting tribal knowledge from the installer. Punch evidence without as-builts fails the next outage. As-builts without IP tables fail the next camera swap. Training without password custody fails the first week a default login hits the internet. Spares that do not match firmware fail the first broken reader on a Friday night.