Recording the actual installed condition

What Should Be Included in As-Built Documentation?

As-built documentation should describe the system that was actually installed—not simply preserve the original design. It includes final locations, equipment, pathways, configuration, field changes, testing, photos, revisions, and handoff information.

The short answer

What belongs in the documentation?

Complete as-built documentation should include final device and equipment locations, installed model and identifier information, cable and pathway routes, labels, panels and racks, final network information where applicable, approved field changes and substitutions, system configuration, testing results, completion photos, unresolved deficiencies, revision history, customer acceptance, and records needed for future service.

As-builts are broader than drawings. A floor plan can show device locations and routes, but it usually cannot hold every serial number, switch port, panel point, configuration backup, test result, photo, deficiency, or handoff record. A useful as-built package combines drawings with schedules, inventories, worksheets, reports, and supporting files.

02

How as-builts differ from original design documents

Design documents show the intended system before installation. As-builts show the accepted installed condition after coordination, substitutions, field changes, programming, and testing. Copying the bid drawings into a closeout folder does not make them as-builts.

Every change that affects location, quantity, identity, route, termination, configuration, or operation should be reflected in the appropriate final record.

  • Added, removed, relocated, reused, and owner-furnished equipment
  • Final identifiers, addresses, port assignments, panel points, and software names
  • Actual cable and pathway routes, intermediate points, and concealed conditions
  • Approved substitutions, alternate models, and changed installation methods
  • Final configuration, sequence, test results, and accepted exceptions
Simple distinction

A design may show a camera at the northwest corner. The as-built record should show that it moved six feet east, identify the installed model and label, connect it to the cable and switch port, and preserve the approved final view.

03

Final device locations and equipment information

Device schedules and inventories should match what can be found in the field. Use stable identifiers and precise locations that correspond to drawings, labels, software, test records, and photos.

The appropriate details depend on the system: cameras and recorder assignments for CCTV, controlled openings and panel points for access control, outlet and patch-panel ports for cabling, or device addresses and circuits for fire alarm.

  • Device ID, installed label, description, building, floor, room, elevation, or opening
  • Manufacturer, model, serial number, firmware, license, warranty, and installation date
  • Panel, controller, recorder, rack, switch, port, power supply, circuit, or loop association
  • Operating purpose, coverage, schedule, programmed function, and approved exception
  • Installed, reused, relocated, replaced, spare, removed, or deferred status
04

Cable routes, pathways, labels, and identifiers

As-built cable information should trace each important connection from origin to destination and identify the pathway used. Record hidden routes while they remain visible and tie photos to pathway, sleeve, penetration, or cable IDs.

  • Cable ID, type, rating, color, conductor or strand count, and approximate length
  • Origin, destination, panel, port, outlet, device, splice, and intermediate point
  • Tray, conduit, sleeve, riser, underground, exterior, aerial, or concealed route
  • Termination, patching, pair or strand assignment, test record, and spare capacity
  • Labels at both ends and any spare, abandoned, repaired, or rerouted status
  • Penetration, firestopping, pull-box, junction, and access information where applicable
05

Network, panel, rack, and cabinet records

Network and enclosure records explain system relationships that a floor plan may not show. Capture the final state after temporary addressing, construction switches, test equipment, and unfinished point assignments have been removed.

  • Hostname, IP address, subnet, gateway, DNS, VLAN, MAC address, and address method
  • Switch, switch port, PoE source, server, recorder, controller, and cloud relationship
  • Panel or rack ID, location, elevation, module arrangement, terminal, input, and output mapping
  • Patch panels, fiber enclosures, power supplies, batteries, grounding, and spare capacity
  • Software, firmware, database, license, backup, certificate, and support ownership
06

Field changes, substitutions, and revision history

A change record should explain what changed, why it changed, who approved it, when it was installed, and which final records were updated. This history protects the accuracy of the installed-condition package.

Substitutions should identify both the originally approved item and the installed replacement, including any effect on mounting, power, capacity, programming, testing, or warranty.

  • Change number, RFI, change order, deficiency, field directive, or approval reference
  • Original condition, installed condition, reason, date, preparer, and approving party
  • Added, moved, deleted, rerouted, readdressed, relabeled, or reprogrammed item
  • Substituted manufacturer, model, capacity, compatibility, and configuration impact
  • Affected drawing, schedule, inventory, test, photo, software, and closeout record
Revision example

Revision 3 should say what changed—such as “relocated cameras C-214 and C-215 due to duct conflict and updated cable routes”—rather than using a revision cloud with no description.

07

Final configuration, testing, and commissioning results

The as-built package should connect the installed system to its final tested condition. Preserve configuration versions, backups, test reports, accepted operating values, witnesses, deficiencies, and retests.

Do not overwrite failed results after a correction. The failure, corrective action, and final passing result together provide the useful service history.

  • Software, firmware, database, configuration, sequence, and backup version
  • Device, cable, network, power, battery, functional, and integrated-system results
  • Tester or instrument, calibration status, technician, date, witness, and procedure reference
  • Expected result, actual result, exception, deficiency, correction, and retest
  • Customer-accepted settings such as camera view, retention, schedules, timing, or operating sequence
08

Completion photos and unresolved deficiencies

Photos make as-builts stronger when they document concealed pathways, device labels, terminations, cabinet interiors, completed installations, and corrected deficiencies. A photo index should explain what each image shows and connect it to the relevant record.

Unresolved deficiencies should remain visible in the turnover package with ownership, impact, target date, and any conditional acceptance. Removing them from the final record does not make them complete.

  • Device overview, close-up label, mount, connection, power, and environmental protection
  • Above-ceiling route, sleeve, penetration, firestopping, junction, and concealed condition
  • Panel, rack, cabinet, patch panel, terminal, battery, grounding, and cable management
  • Before, deficiency, correction, and final completion image tied to a record ID
  • Open issue, responsible party, operational impact, temporary measure, and target resolution
09

Customer acceptance, handoff, and future service records

As-builts become operational records when the customer can find, understand, and maintain them. Identify the final revision, file formats, delivery location, secure credential process, training, manuals, warranties, spares, and responsible service contacts.

Preserve native drawings, original-resolution photos, configuration backups, and electronic test files where possible. PDF copies are useful for access, but source files may be necessary for future revisions or deeper analysis.

  • Customer, technician, project-manager, and required witness acceptance or sign-off
  • Training topics, attendees, manuals, warranties, licenses, keys, and spare materials
  • Native drawings, PDF exports, inventories, schedules, photos, test files, and backups
  • Secure location of credentials, recovery information, and restricted system details
  • Warranty and service contacts, known limitations, expansion capacity, and revision process

Quality-control review

Common omissions and mistakes

  • Renaming original design drawings as as-builts without updating the installed condition
  • Treating as-builts as drawings only and omitting inventories, configurations, tests, and photos
  • Using device labels that do not match software names, cable IDs, panel points, or reports
  • Failing to document field substitutions and their effect on power, mounting, capacity, or programming
  • Delivering screenshots or flattened PDFs without keeping useful native source and result files
  • Leaving temporary addresses, draft revisions, unresolved redlines, and duplicate files in the final set
  • Omitting unresolved deficiencies or accepted exceptions from the customer handoff

Make the process repeatable

Use a consistent documentation system.

A reusable as-built process prompts field teams to capture changes while they are visible, keeps identifiers aligned across records, and makes final review more consistent. Templates should support drawings, schedules, inventories, tests, photos, and handoff information rather than reducing as-builts to a single marked-up plan.

View As-Built Documentation Pack