7.1 As-Built Documentation

Why as-builts matter

Design drawings show what the designer intended; as-built drawings show what the installer actually built. On any real ICT project the two diverge: pathways shift to avoid ductwork, outlets move at the owner's request, spare conduits are pulled to future-proof a run, and a cable that was specified at 85 m ends up at 92 m because of a detour. If those deviations are not captured, the next technician on the site — troubleshooting, expanding, or retrofitting — works from a fiction. The BICSI Technician is responsible for producing accurate as-builts, and the written exam tests the conventions, content, and workflow that make them trustworthy.

Design vs as-built: what changes

A design package typically contains floor plans with outlet locations, a pathway plan (conduit, tray, J-hooks), a patch-panel schedule, and a cable schedule listing each run with from/to, type, and estimated length. The as-built retains the same sheet format but records the installed reality:

Redlines

A redline is the field-marked working copy of the design drawing used during installation. The crew annotates changes in red (or another contrasting color) as they occur: a conduit moved 300 mm to clear a beam, an outlet added in a niche, a run abandoned because the pathway was inaccessible. Redlines are not the final deliverable — they are the input to the as-built. The Technician reviews the crew's redlines, resolves ambiguities, and transfers the verified information onto a clean as-built sheet (now usually CAD or BIM rather than Mylar).

Best practice for redlines:

• Mark changes daily, not from memory at the end of the job.
• Use consistent symbols and a legend that matches the project's drawing standard.
• Note the reason for each deviation in a remark, not just the geometry.
• Cross-reference each redline to an RFI, change order, or owner directive when one exists.
• Date and initial every change so the reviewer can trace accountability.

What to record post-install

A complete as-built package for an ICT cabling project should contain:

1. Outlet/faceplate schedule — every work-area outlet (WAO) with its unique identifier, location, serving telecommunications room (TR), and media type.
2. Cable schedule — each horizontal and backbone run with cable ID, type (e.g., Cat 6A UTP, OS2 singlemode), from-device, to-device, installed length, and test-pass reference.
3. Pathway record — conduit runs with size and fill, cable trays with loading, sleeved penetrations, and any firestopped penetrations (with firestop system design number).
4. Patch-panel and cross-connect schedules — port-level assignments tying each cable ID to a physical port.
5. Link maps — the cross-reference that lets a technician trace any user outlet to a specific switch port. A link map pairs the work-area cable ID (e.g., WAO-3F-012) with the patch-panel port (e.g., PP-1/Port-14) and the active equipment port. Without a link map, MAC work turns into tone-and-trace labor.
6. Bonding and grounding record — TMGB, TGB, and TBB locations, conductor sizes, and resistance measurements per TIA-607 and J-STD-607.
7. Certification test results — imported from the certifier (e.g., Fluke Versiv, WireXpert) in PDF and machine-readable format, linked by cable ID.
8. Deviations and change orders — a log of every deviation from the design, with the authorizing reference.
9. Photographs — pathway congestion, firestop details, bonding connections, and any unusual conditions; these are invaluable for future troubleshooting.

Labeling per TIA-606-C

Accurate labeling is what makes the as-built usable. TIA-606-C (Administration Standard for Telecommunications Infrastructure) defines the identifier scheme. Each cable, pathway, space, and grounding/bonding component gets a unique identifier, and that identifier appears at both ends of the cable and on the record. A horizontal cable label typically encodes the building, floor, telecommunications space, and sequence — for example, B3-F2-TR1-C-0147 for building 3, floor 2, TR 1, copper cable 0147. The patch-panel label, the work-area label, and the cable schedule entry all carry the same identifier, so a technician reading any one of them can find the others without guessing.

The Technician's responsibility

On a BICSI project the Technician is typically the person who signs off the as-built package before it goes to the owner and the design engineer of record. That sign-off means:

• The redlines have been reviewed and resolved.
• The cable schedule matches the certification records by cable ID.
• The link map has been verified against the patch panel and switch — not just transcribed from the design.
• The bonding/grounding record reflects the measured values, not the specified ones.
• Any deviation that affects warranty (e.g., a pathway change that increases cable length beyond 90 m for a permanent link) is flagged.

Common as-built defects

Exam questions often test defects that invalidate an as-built:

• Length not recorded per run — listing "≤90 m" for every cable hides the few that exceed the limit.
• Link map copied from design — never reconciled with the actual patch panel, so port assignments are wrong.
• Firestop penetrations not documented — the firestop design number is missing, so the AHJ cannot inspect.
• Bonding resistance not measured — the record says "grounded" but has no ohm value.
• Redlines not transferred — the as-built sheet still shows the design layout.

Why this is on the TECH exam

The 15% "Safety and Documentation" domain treats documentation as a craft skill, not paperwork. The hands-on exam may require the candidate to produce a link map for a small installation or to mark up an as-built from a given set of redlines. The written exam tests identifier conventions, the elements of a complete package, and the difference between a design record and an installed record. Expect one or two scenario questions where you must identify which as-built defect caused a troubleshooting failure.