AV Documentation & System Design Basics
Introduction
A system nobody can read is a system nobody can build, fix or trust. Every AV system that outlives the person who built it does so because somebody drew it, labelled it, listed it and kept the drawings honest.
This book is about that paper. Not paper for its own sake — paper as the tool the work is actually done with. A drawing set is how a system is designed before it costs money, how it is built by people who were not at the design meeting, how it is found again at two in the morning when something has failed, and how it is handed to a client as an asset rather than a mystery.
What this book covers
- Why AV documentation exists, and who each document is written for.
- Signal-flow diagrams: reading them, drawing them, and choosing the level of detail.
- How a drawing is put together — title block, revisions, symbols, sheets, plans and elevations.
- Rack elevations and the rack design decisions they record: weight, heat, access and power.
- Cable schedules, cable numbering and labelling the physical system to match the paper.
- Equipment lists, network documentation, control descriptions and configuration records.
- The design process from a stated need through devices to connections.
- Needs analysis, the design phases, and designing within real constraints.
- Coordinating with the other trades, and the submittals, RFIs and change orders around a drawing.
- Redlines, as-builts, commissioning, the punch list and handover.
Who this is for
Technicians who are handed drawings and want to read them fluently, installers who are asked to redline what they changed, and anybody moving towards design, project work or the CTS. It assumes AV Fundamentals 101 and the signal-path thinking taught in Signal Flow & System Architecture.
How to Use This Book
Read it once through, then keep it beside a real drawing set. The chapters follow a system's life: why the documents exist, what each one says, how the system is designed, how it is built and corrected, and how it is checked and handed over.
Draw as you read
Every chapter about a document is worth ten minutes with a pencil. Draw the signal flow of the system in front of you — a meeting room, a rehearsal rig, the rack under your own desk. Drawing a small system badly teaches more than reading a large one well.
Keep a notebook
Documentation is a habit before it is a deliverable, and the habit starts in a notebook you carry. Write down what you actually found: the circuit that turned out to feed two racks, the cable that was pulled a different way from the drawing, the device that shipped with a different firmware from the one in the schedule.
Those notes are the raw material of a redline, and a redline is the raw material of an as-built. A correction you remember on the drive home is a correction that does not get made, and the next person inherits a drawing that quietly lies to them.
A note on the words
The trade's vocabulary is not consistent. A block diagram, a signal-flow diagram and a one-line may mean the same drawing in three companies, and a schematic means something narrower to an electrician than it does to an AV integrator. This book uses the words most widely understood, and names the alternatives where they matter.
A note on safety
Documentation touches safety in two places. First, rack weight, mounting, power and rigging loads are engineering decisions that belong to qualified people, and a drawing does not make an unsafe design safe. Second, signing off a check you did not perform, or drawing a circuit you did not verify, puts the next person at risk. Nothing here qualifies you to design electrical distribution or to certify structural loads.
Where this book sits
This book assumes you can trace a signal through a system in your head, as Signal Flow & System Architecture teaches, and that you know what the devices in a rack do. It does not assume you have ever read a drawing set.
What pairs with this
- Signal Flow & System Architecture — the system thinking every drawing in this book records
- Networking Basics — the half of a modern system that lives in an IP schedule
Where it leads
These are not steps in an order. Take whichever one fits.
- Project Management for AV — the phases and paperwork around a drawing set, from the office side
- AV Installation Fundamentals — building to a drawing set, on site
- Commissioning & Quality Assurance — proving and recording that the system meets the brief
Why Documentation Matters
A drawing set is not an administrative chore that follows the real work. It is the real work, written down early enough to be argued with. Everything that is cheap to change on paper becomes expensive the moment it is racked, and impossible the moment the client has moved in.
A system you can't read is a system no one can build, fix, or trust.
Documentation is the system's blueprint
AV documentation is the set of drawings and records that describe how a system is designed and connected — its blueprint. Just as a building has architectural plans, an AV system has documentation showing every device and how the signals flow between them. This documentation is what lets a team build the system correctly to one shared plan, lets anyone troubleshoot it by tracing the drawings, and lets others service or operate it later without having designed it. A system with good documentation is buildable, maintainable, and transferable; one without is a mystery only its builder understands.
This matters across AV but especially in integration and installed systems, where a permanent system must be built precisely, maintained for years, and handed to a client. The documentation is a deliverable in its own right. But even on live events, documentation — a signal-flow diagram of the show's audio, a patch list — is what keeps a complex system organised and fixable. Documentation is the discipline that turns a system from one person's knowledge into a shared, durable asset.
Put it in money and hours and the argument ends. A missing connection found on a drawing costs a minute. The same missing connection found during the build costs a trip to the supplier. Found at commissioning it costs a re-test and an apology, and found by the client after handover it costs the next job.
Documentation is also the only way a system survives the people who built it. Staff leave, integrators are replaced, and the room is still there in ten years. What remains is the drawings and records — or nothing.
The core documents
A few documents do most of the work. A signal-flow diagram shows how signals travel between devices — the map of the system's connections you met in AV Fundamentals. A rack elevation shows what equipment is mounted where in each rack, top to bottom. An as-built is the documentation updated to reflect the system exactly as actually installed (which often differs from the original plan once real-world adjustments are made). Together with supporting records (cable schedules, equipment lists, configuration settings), these capture how a system is designed, built, and set up.
Each document answers a different question: the signal-flow diagram answers how does the signal get from here to there; the rack elevation answers where is that device physically; the as-built answers how was it actually built. Knowing which document to create and read for which purpose is foundational. This book begins with the two most universal — signal-flow diagrams and rack elevations — and returns throughout to the discipline of keeping accurate as-builts.
What documentation is worth, in hours
A serviceable AV system is one where a competent stranger can find the fault without phoning the designer. That is the working definition to judge every document against: would a stranger, holding this, get there?
- During the build, the drawings replace a hundred questions with one shared plan.
- During a fault, a signal-flow diagram turns a mystery into four places to measure.
- During service, an as-built stops the technician taking the wrong panel off.
- At upgrade, an equipment list and a cable schedule decide whether a change is an afternoon or a rebuild.
- At handover, the document set is what the client is actually buying alongside the hardware.
What happens without it
Undocumented systems have a recognisable smell. Nobody knows what is in the third rack. Two cables are labelled the same. The touch panel has a button nobody dares press. The only person who understands the matrix left the company, and the client has been told not to change anything.
That system is not cheap; the cost was moved. It was moved out of the design phase and into every future hour anybody spends in front of it.
What each core document answers
Pick the document by the question you are trying to answer.
| Document | The question it answers |
|---|---|
| Signal-flow diagram | How does the signal get from here to there |
| Rack elevation | Where is that device, physically |
| Cable schedule | What is this cable, and where does its other end land |
| Equipment list | What is in this system, and what exactly was bought |
| Functional description | What is this button supposed to do |
| Configuration record | What was this device set to, and why |
| As-built | How was it actually built, not how was it planned |
| Test and commissioning record | Who checked it, when, and what did it read |
- One document rarely answers another's question. A rack elevation that tries to show signal flow usually shows neither well.
On the job
A projector in a boardroom has no image. The technician who arrives has never seen the room. With a signal-flow diagram they check four points in ten minutes and find a dead extender. Without one they spend two hours pulling ceiling tiles, and the client watches them do it.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| Nobody can say what is in a rack without opening it | No rack elevation was produced, or it was never updated after the install | Photograph the rack front and rear, then draw the elevation from the photographs and the equipment list |
| Two technicians give the client contradictory answers about the system | Each is working from personal knowledge rather than a shared document | Write down what is actually true, issue it, and make the document the single answer |
| A change takes a week because nobody knows what it affects | No signal-flow diagram, so the consequences of the change cannot be traced | Draw the existing system first; the drawing is the estimate |
Practice it
Look at a system you work on regularly.
- A stranger could trace a signal through it on paper.
- A stranger could find any device physically.
- Every cable the drawings show exists and carries the label they show.
- Somebody other than the builder holds a copy.
Who the Drawings Are For
A drawing is written for somebody. The installer, the programmer, the service technician, the client and the other trades all open the same set and look for different things, and a document that forgets who is reading it ends up being read by nobody.
Five readers, five questions
The installer wants to know what goes where and what plugs into what, at the level of a cable and a rack unit. The programmer wants the control topology, the addresses and the functional description. The service technician, arriving in three years, wants the as-built and the configuration records.
The client wants to know what they own and how it is operated. The other trades — electrical, structural, IT and the builder — want only the parts that touch their work: conduit, backboxes, weight, power and network ports.
Who reads each document
It is worth being explicit about this, because it settles most arguments about how much detail a drawing needs. Detail that no reader needs is cost, and detail a reader needs and cannot find is failure.
When you cannot decide whether something belongs on a sheet, name the reader who would look for it there. If you cannot name one, it belongs somewhere else.
Who makes the documents
On a large project a consultant designs and issues a drawing set that goes out to tender; an integrator builds from it and issues shop drawings and as-builts; a contractor coordinates the trades; and the client's own in-house team inherits everything at the end.
On a small job one person does all of it. The phases still exist; they just happen in an afternoon. Knowing which hat you are wearing tells you which document you are supposed to be producing.
Who reads what, and what they need from it
Every document has a primary reader. Write it for them.
| Reader | Reads | Needs |
|---|---|---|
| Installer | Signal flow, elevations, cable schedule | What connects to what, and where it mounts |
| Programmer | Control topology, functional description, IP schedule | Addresses, devices and intended behaviour |
| Service technician | As-built, configuration records, test results | The truth about what is there now |
| Client | O&M manual, equipment list, warranty | What they own and how to operate it |
| Electrical contractor | Power requirements, single-line, device locations | Circuits, loads and where they land |
| IT department | Network diagram, IP schedule, port map | What is joining their network and how |
| Estimator | Equipment list, cable schedule | Quantities, without hunting for them |
- If two readers need contradictory levels of detail, that is two documents, not one crowded one.
On the job
An integrator issues a single beautiful drawing that shows signal flow, rack layout and conduit routes together. The electrician cannot find the circuits, the installer cannot read the connections behind the conduit runs, and the client is sent a sheet they cannot interpret. Three readers, one document, nobody served.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| The electrician asks for information that is on the drawings | It is buried in an AV sheet they were never issued or expected to read | Produce a power and location sheet aimed at them, and issue it to them directly |
| The client files the drawing set and never opens it | Nothing in the set was written for a non-technical reader | Add an O&M section in plain language: what the system does, how to operate it, who to call |
| The programmer keeps asking what a button should do | There is no functional description, only a wiring drawing | Write the intended behaviour down before programming starts, and have the client agree to it |
Practice it
Take one drawing you have been given.
- You can name its reader in one word.
- Everything on it serves that reader.
- The thing that reader will look for first is easy to find.
- It has been sent to them, not just filed.
Signal-Flow Diagrams
If you only ever learn to produce one AV document, produce this one. A signal-flow diagram is the drawing people actually open — at the design meeting, on the install, at two in the morning with a meter in one hand.
The most important AV drawing: the map of how everything connects.
Reading a signal-flow diagram
A signal-flow diagram maps how signals travel through a system: boxes are devices, lines are connections, and the layout shows how everything links from sources through processing to destinations. You read it the way you trace a signal — find the sources, follow the lines through the processing, arrive at the destinations — which is exactly the signal-flow skill from AV Fundamentals applied to a drawing. A good diagram lets anyone understand and troubleshoot a system they did not build, because it shows the whole signal path at a glance.
Reading these fluently is a core professional skill. When you can look at a signal-flow diagram and narrate the system — this source goes here, through this device, out to these destinations — you can build it, operate it, and fix it. Much of working from documentation is reading signal-flow diagrams to understand how a system is meant to connect and behave.
Read every diagram the same way, out loud if it helps. Find the sources on one side. Follow each line through whatever processes it. Arrive at the destinations. Name what happens in between: converted, switched, amplified, distributed, delayed.
Then read it the other way, from a destination backwards. Faults are found backwards far more often than forwards, because you start at the thing that is wrong.
Creating a signal-flow diagram
Creating a signal-flow diagram means representing a system's connections clearly: every device as a labelled box, every connection as a line (often labelled with the signal type or connector), arranged logically so the flow is easy to follow (typically sources to one side, destinations to the other). Good diagrams are clear, consistent, and complete — someone else can build or troubleshoot from them without asking questions. Clarity and consistency matter more than artistry: the goal is an unambiguous map anyone in the trade can read.
The discipline is to capture the real system accurately and keep the diagram updated as the system changes. A signal-flow diagram that no longer matches the actual system is worse than none, because people trust and act on it. Learning to create clear, accurate signal-flow diagrams — and to keep them current — is a foundational documentation skill that serves every part of AV, from designing an install to organising a live show's signal path.
Draw sources to the left, destinations to the right, and processing in between; keep the flow going one way across the sheet. Give every box the same shape treatment, put the device name and model in it, and label every line with what it carries and on what connector.
Draw the system that exists, not the system you meant to build. The diagram's only value is that it is true, and a diagram that is wrong is more dangerous than no diagram at all, because people act on it.
Block diagrams, one-lines and the level of detail
The same system gets drawn at several depths. A block diagram shows the shape of the system — sources, a matrix, destinations — with the detail deliberately left out, and is what you show a client. A one-line collapses multi-conductor connections to a single line and is how large systems stay readable.
A detailed signal-flow drawing shows every connection, connector type and cable number, and is what somebody builds from. Choose the depth by the reader: the client's sheet and the installer's sheet are not the same drawing, and trying to make them one produces a sheet neither can use.
Naming things consistently
Devices get a name and a number, and that name appears on the diagram, in the equipment list, on the rack elevation, on the cable schedule and on the physical label. One name for one thing, everywhere. The commonest documentation failure in the trade is three names for one device.
Keep names short and mechanical: DSP-1, SW-2, PJ-Main, MIC-04. Names carrying room numbers or rack numbers help on large sites, and names carrying somebody's initials help nobody.
What makes a diagram unreadable
- Lines that cross more than they need to, with no jumps to say which passes over.
- Signal that flows right to left on some parts of the sheet and left to right on others.
- Boxes labelled with the model number only, so nobody knows what the box is for.
- Unlabelled lines, which force the reader to guess the signal type.
- A legend that does not include every symbol used.
- A sheet with no title block, so nobody knows whether it is current.
What a line on a diagram should tell you
A line carries four facts. Leave one out and somebody will phone you.
| Fact | Example | Why it matters |
|---|---|---|
| What it carries | Balanced analogue audio | Decides the cable and the connector |
| On what connector | XLR-3 | Stops the wrong tail being made up |
| Its direction | Arrow towards the amplifier | Prevents an input being wired to an input |
| Its identifier | A-014 | Ties the line to the cable schedule and the label |
- On a one-line drawing the identifier may stand for a whole bundle. Say so on the sheet.
How to do it
- Photograph the front and rear of every rack before you touch anything.
- List every device, top to bottom, rack by rack, with model and location.
- Start at a destination — a speaker, a display — and trace one path backwards, writing each hop.
- Repeat for every destination until no device is unvisited.
- Draw it roughly on paper, sources left, destinations right, before opening any software.
- Walk the room with the rough drawing and correct it against reality.
- Draw it properly, label every line, and put a revision and a date on the sheet.
- Have somebody who knows the system read it back to you from the sheet alone.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| Two people build the same rack differently from one diagram | The diagram shows connections but not which physical port, so each made a reasonable choice | Number the ports on the drawing, or add a detail sheet for the ambiguous device |
| A fault is traced to a cable that the diagram says does not exist | The drawing was never updated after a site change | Redline it there and then, and reissue; an untrue diagram costs more than none |
| The client signs off a diagram, then asks where the microphones went | An installer-level drawing was used as a client-facing one | Produce a block diagram for the conversation and keep the detailed sheet for the build |
Practice it
Take the nearest system with more than four devices in it.
- Signal reads one way across the sheet.
- Every box names a device, not only a model.
- Every line says what it carries and on what connector.
- Every symbol used appears in the legend.
- The title block carries the project, the sheet, the revision and the date.
- Somebody else read it back without asking a question.
How a Drawing Is Built
Everything that makes a drawing a controlled document rather than a picture lives around the edges of the sheet: the title block, the revision, the sheet number, the legend and the scale. Newcomers ignore the border. The border is what makes the middle trustworthy.
The title block
Every sheet carries a title block, usually bottom right. It names the project, the client, the sheet title and number, who drew it, who checked it, the scale, the date and the revision. Without it a sheet is an anonymous picture that may be three versions old.
Read the title block first, every time somebody hands you a drawing. The question is never "what does this show" until you have answered "is this the current issue, and of what".
Revisions and issue
A drawing changes, and each change gets a revision letter or number, a date and a one-line description in the revision history. The changed area is often marked with a cloud so the reader can find what moved. The current revision supersedes everything before it.
Issue is separate from revision: it records who was sent the drawing and when, for what purpose — for comment, for construction, for record. A drawing marked for construction is one somebody is allowed to build from.
Sheet numbering and the drawing set
Drawings travel in sets, not alone. The set has a cover sheet and a drawing index, then sheets grouped by type: plans, elevations, details, schematics, schedules. Each sheet has a number that sorts it into that order, and cross-references point between sheets.
If a detail is drawn on another sheet, the drawing says so with a reference bubble naming that sheet. Follow the bubbles rather than assuming the information is missing.
Symbols, legends and line conventions
Drawings are read by strangers, so the symbols have to be conventional and the legend has to be complete. Different line weights and styles carry meaning — solid for what is being installed, dashed for existing or hidden, dotted for future — and the legend says which is which.
Invent as little as you can. If you must invent a symbol, put it in the legend and use it the same way on every sheet of the set.
Plans, elevations, sections and details
A plan looks down at a floor: where devices sit in the room, where cable routes run, where racks stand. A reflected ceiling plan looks up, for projectors, speakers, cameras and mounts. An elevation looks at a vertical face — a wall, or a rack. A section cuts through the room to show heights and clearances.
A detail is a close-up of one arrangement drawn large: a mounting bracket, a floor box, a plate. Between them they describe a three dimensional room on flat sheets, and every reader needs to know which direction they are looking from.
Scale, dimensions and what is not to scale
Plans and elevations are drawn to a stated scale, and dimensions are written on the drawing rather than measured off it. A drawing marked NTS — not to scale — is diagrammatic, and scaling from it is how brackets end up in the wrong place.
Signal-flow diagrams are never to scale. They are topological: they show what connects to what, and nothing about distance. That is why a cable schedule exists.
Layers, files and version control
In CAD, information sits on layers — architecture, ceiling, AV devices, cable routes, power, notes — so that each reader can be shown what they need. A layer standard is how two drafters produce compatible files.
Outside the file, the discipline is version control: one agreed location for the current set, file names carrying project, sheet and revision, and superseded issues moved to an archive folder rather than deleted. Two people building from two versions of the same sheet is a classic site failure, and it is always avoidable.
The tools the trade draws in
AV is drawn in general CAD packages, in AV-specific design and estimating tools that generate schedules from the drawing, in diagramming software for block-level work, and marked up in PDF review tools where redlines and comments are shared.
The tool matters far less than the conventions. A clear drawing made in simple software beats a confused one made in expensive software, and the output everybody can open is PDF.
What the border of a sheet must carry
Missing any of these makes the sheet uncontrolled.
| Item | Answers |
|---|---|
| Project and client | Which job this belongs to |
| Sheet title and number | What this sheet is, and where it sits in the set |
| Revision and date | Whether this is the current version |
| Drawn by and checked by | Who to ask, and who took responsibility |
| Scale | Whether dimensions may be taken off the sheet |
| Issue status | Whether anybody may build from it |
| Legend | What every symbol on the sheet means |
- On a small job the title block may be three lines in a corner. It still has to exist.
On the job
Two installers work a Saturday from drawings printed on different days. One has revision C, the other revision E, and the difference is the position of a floor box. The concrete is cut in the wrong place, and the only defence anybody had was a revision letter nobody checked.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| Nobody can tell which printout is current | Sheets without a revision and date, or printed from a personal copy | Reissue the set with revisions, destroy the loose prints, and print only from the agreed location |
| A bracket is installed 200 mm out | Somebody scaled a dimension off a drawing marked NTS | Dimension what matters on the drawing, and mark diagrammatic sheets clearly |
| The electrician's sheets and the AV sheets disagree about a device position | Two disciplines drew the same room without coordinating layers or issue dates | Coordinate on one background, and reissue both sets after any move |
Practice it
Find any construction or AV drawing, on paper or PDF.
- The title block is complete, including revision and date.
- The issue status says what the sheet may be used for.
- Every symbol is in the legend.
- Cross-references point to sheets that exist in the set.
- The file is named to the project's convention and saved in the agreed place.
- The superseded revision has been moved to the archive.
Rack Elevations & Other Documents
A rack is a building. It has a load, a heat problem, an access problem and a power supply, and the elevation is its floor plan. Drawing one is easy; drawing a good one means making a dozen decisions that only show up years later, when somebody has to get the third amplifier out with the system live.
Where the gear physically lives, and the records that complete the picture.
Rack elevations
A rack elevation is a drawing of a rack showing what equipment is mounted where, listed top to bottom, as if looking at the front of the rack. It is the physical map of the gear, complementing the signal-flow diagram's logical map: the diagram says the console connects to the processor, the elevation says the console panel is here and the processor is two slots down. Rack elevations let you (and anyone servicing the system) find the exact physical location of any device, plan how gear is mounted for good airflow, weight, and cable access, and document the build.
Reading and creating rack elevations is straightforward but valuable: a clear elevation makes building, wiring, and servicing a rack far faster and reduces errors. Good rack design — documented in the elevation — also considers practical factors like keeping heavy gear low, leaving room for ventilation and cabling, and grouping related equipment. The elevation captures all of this so the rack is built right and can be maintained.
A rack elevation is drawn in rack units — one U is 44.45 mm, and every piece of rack-mount gear is a whole number of them. The elevation lists the rack top to bottom by U position, so a device can be found by counting rather than by hunting.
Draw the front and the rear as two elevations. The front shows what is seen and operated; the rear shows the connections, the power strips and the cable management, which is where the work actually happens. A rack drawn front-only hides everything that matters at service time.
As-builts and supporting documents
The as-built is the documentation updated to reflect the system exactly as it was actually installed. Real installations always differ somewhat from the original design — a device substituted, a cable routed differently, a setting adjusted — and the as-built captures these real-world changes so the documentation matches reality. Accurate as-builts are essential because they are what future servicing, troubleshooting, and upgrades rely on; documentation that reflects the original plan rather than the real build sends the next person down the wrong path. Keeping documentation as-built — updating it to match what was actually done — is a discipline that pays off every time the system is touched later.
Other supporting documents complete the picture: equipment lists (what gear is in the system), cable schedules (every cable, its endpoints, and label), and configuration records (key settings, addresses, passwords). Together with the diagrams and elevations, these let a system be fully understood, maintained, and handed off. The overarching principle is that good documentation, kept accurate and as-built, is what makes a system a durable, transferable asset rather than a fragile dependency on the person who built it.
The as-built is not a document written at the end; it is the original drawing corrected as the work happens. Every real install differs from the design — a substituted device, a cable routed another way, a port swapped at commissioning — and each of those is a mark on the drawing that day.
What makes as-builts fail is always the same: everyone intends to do it from memory on Friday. By Friday the memory is gone and the drawing becomes fiction that people will act on for a decade.
Weight, and where it goes
Heavy things go low. Amplifiers, power conditioners and uninterruptible supplies belong at the bottom, both because the rack is stable that way and because lifting a 30 kg amplifier to head height is how backs are hurt. A fully loaded rack can weigh several hundred kilograms, and that weight has to be supported by whatever it stands on.
Record the weight on the drawing when it matters — on a mezzanine, on a raised floor, on castors that will be rolled onto a truck. Structural capacity is somebody else's calculation, and they cannot make it without your number.
Heat and airflow
Racks move air front to back. Intakes are usually at the front, exhaust at the rear, and the rack's job is to stop hot exhaust air being drawn back into an intake. Blanking panels over empty U space are not tidiness — they stop that short circuit of air.
Leave space above the hottest devices, know whether the rack is vented, fan-assisted or sealed, and remember that a cupboard with a closed door is a thermal system too. A room's air conditioning has to remove the heat the rack produces, and that number belongs in the coordination information you give the mechanical trade.
Service access and cable management
Ask of every rack: how does the next person get this device out? If it requires removing three others and unplugging a loom, the layout is wrong. Group related devices, leave a U of space where cables need to pass, and give patch panels room for their tails to turn.
Cables are dressed down the sides on tie bars, with enough service loop that a device can slide out on its rails without unplugging. Every cable carries its label at both ends, and the labels face where a person will read them.
Power in the rack
A rack has a power design: how many circuits feed it, what each one carries, whether anything is on an uninterruptible supply, and in what order things switch on. Amplifiers switching on before their sources are quiet is how speakers are destroyed, so sequencing is drawn, not assumed.
Record the total load, the circuits and the protection on a single-line power drawing for the rack. The electrician needs it, the client's facilities team needs it, and the next person adding a device needs to know what headroom is left.
Rack layout decisions, and the reason behind each
Layout is engineering, not tidiness.
| Decision | Rule of thumb | Why |
|---|---|---|
| Heavy gear position | Low in the rack | Stability, and safe lifting |
| Empty U space | Fit blanking panels | Stops hot air recirculating to intakes |
| Patch panels | Near the devices they serve | Shorter tails, less congestion |
| Operated devices | At a comfortable working height | People use what they can reach |
| Hot devices | Space above, clear exhaust path | Heat is the main cause of early failure |
| Service loops | Enough to slide a device out | Service without unplugging the rack |
| Power strips | Rear, with circuits identified | Load is traceable and safe to work on |
- Rack weight, mounting and any rigged or suspended rack are engineering questions for a qualified person.
How to do it
- List every device that must be racked, with its U height and weight.
- Put the heaviest devices at the bottom and the operated devices at working height.
- Group devices by signal relationship so patching stays short.
- Add patch panels, power distribution and cable management as real U space, not afterthoughts.
- Leave deliberate spare U for the next change, and say on the drawing that it is spare.
- Fit blanking panels to every remaining gap.
- Draw the rear elevation with connections, power and cable routes.
- Total the weight and the current draw, and put both on the sheet.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| A device fails repeatedly and nothing is wrong with it | It is sitting in the exhaust of the device below, or empty U space is recirculating hot air | Fit blanking panels, add space or ventilation, and re-draw the elevation with the thermal layout in mind |
| Servicing the matrix means taking out three other devices | The rack was filled in purchase order rather than by access and grouping | Re-plan the elevation around service access, and rebuild it during a planned outage |
| A rack trips a breaker when everything is switched on together | No load calculation and no sequencing on the drawing | Calculate the load, split across circuits, and draw the sequence the rack powers up in |
| The client's facilities team cannot find a device the drawing shows | The elevation was never updated when devices moved during the install | Redline on the day, reissue as-built, and put a printed elevation inside the rack door |
Practice it
Stand in front of a real rack with a tape measure and a notebook.
- Front and rear are both drawn.
- Every U is accounted for, including blanks and spares.
- Heavy devices are low and operated devices are reachable.
- The airflow path is unobstructed and stated.
- Total weight and total load appear on the sheet.
- The sequence of power-up is recorded.
- A copy lives inside the rack as well as in the drawing set.
Cables, Labels and Schedules
A cable schedule is the least glamorous document in the set and the one the build actually runs on. It is a list of every cable: its number, what it is, where each end lands, how long it is, and where it runs. Get it right and the install is assembly. Get it wrong and the install is archaeology.
What a cable schedule holds
One row per cable. The row carries the cable's identifier, its type, the device and port at each end, the connector at each end, the route or containment it runs in, its length, and a column for the test result. Nothing on that list is optional on a job of any size.
The schedule is generated from the signal-flow drawing rather than invented separately, which is why the identifier on the drawing and the identifier on the schedule must be the same string.
Cable numbering that survives contact with a site
A good numbering scheme is short, unique and carries a hint of meaning: a letter for the signal type, a number for the run, and on large sites a prefix for the room or rack. A-014 says audio, run fourteen. Schemes that encode both ends in the number become unreadable as soon as something moves.
Number cables, not journeys. When a cable is replaced, it keeps its number. When a new cable is added, it takes the next free number rather than a decimal of an existing one, and the schedule records it.
Labelling the physical system
Every cable gets a label at both ends, close enough to the connector to be read in a rack, printed rather than handwritten, and made to survive heat, handling and time. Devices, panels and ports carry labels too, matching the names on the drawings.
This is the moment the paper and the physical system become one thing. A signal-flow diagram is a theory until the cable in your hand carries the number the drawing gives it — and then the whole set becomes usable by anybody, in the dark, under pressure.
What labels have to withstand
- Heat, in a rack that runs warm for years.
- Being pulled through containment, so labels go on after the pull where possible.
- Hands, cleaning and time, so print rather than marker pen.
- Being read upside down at the back of a rack, so orientation is consistent.
- Being cut off and remade, so the schedule is the master, not the label.
Containment, routes and lengths
Cable routes are somebody else's work — conduit, tray, basket, floor boxes and poke-throughs are installed by the electrical or building contractor long before AV arrives. The schedule's route column is what tells them what capacity to provide and what tells you where a cable actually is.
Lengths on the schedule are measured routes plus service loops, not straight-line distances, and they drive both what is ordered and whether a signal type will work at that distance. A run too long for its format is a design fault the schedule can catch before anything is bought.
Columns a cable schedule needs
Anything missing here becomes a phone call during the install.
| Column | Example |
|---|---|
| Cable ID | A-014 |
| Type | Balanced audio, shielded twisted pair |
| From device and port | MIX-1 OUT 3 |
| From connector | XLR-3 male |
| To device and port | DSP-1 IN 7 |
| To connector | Euroblock |
| Route | Tray C, riser 2 |
| Length | 18 m including loops |
| Tested | Date and initials |
- On a live-event rig the same information appears as a patch list; the columns change name, not purpose.
On the job
Three weeks after handover a lectern input dies. The technician reads the label on the cable at the lectern, finds that number on the schedule, reads that it lands on input seven of the processor in rack two, and has the fault isolated before taking a cover off. The whole visit takes twenty minutes because somebody spent a morning labelling.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| Two cables carry the same number | Numbers were assigned by two people, or a replacement cable reused a live number | Renumber from the schedule, relabel both ends, and give one person the schedule |
| Labels are unreadable within a year | Handwritten labels, or the wrong label stock in a hot rack | Print labels on rated stock and relabel as part of the next service visit |
| A cable is pulled and turns out to be 4 m too short | Length taken as a straight line rather than as the real route with service loops | Measure the route, add the loops at both ends, and record the measured length |
| The drawing and the schedule call the same cable different things | The schedule was typed separately instead of generated from the drawing | Make the drawing the source and rebuild the schedule from it |
Practice it
Take one cable you can physically reach.
- Every cable has a unique identifier used on drawing, schedule and label.
- Both ends carry a printed label.
- Device, port and connector are recorded for both ends.
- Route and measured length are recorded.
- The test result and the tester's initials are on the row.
- The schedule matches what is physically installed today.
Lists, Networks and Settings
Half of a modern AV system is not a cable at all. It is an address, a setting, a firmware version and a line of behaviour somebody agreed to in a meeting. None of that can be seen by looking at the rack, which is exactly why it has to be written down.
Equipment lists and bills of material
The equipment list says what is in the system: manufacturer, model, quantity, location and the name the drawings give it. The bill of material is its commercial cousin, carrying part numbers, accessories, mounts, spares and everything that has to be bought for the system to exist.
What is drawn, what is ordered and what is delivered have to be the same list. Most site surprises — a missing mount, a card that was never in the chassis, two of something and none of another — are a disagreement between those three lists that nobody reconciled.
Network documentation
An AV system on a network needs its own record: the devices, their addresses, whether each is static or reserved, the subnets and VLANs, the switches and the port each device lands on, and what the AV system needs from the network in the way of bandwidth, multicast handling and quality of service.
This document has two readers. The service technician uses it to find a device that has stopped answering. The client's IT department uses it to decide whether to let your system onto their network at all, and a well-written IP schedule has opened more doors with IT than any amount of persuasion.
Control systems and the functional description
A control system's wiring tells you nothing about what it does. The functional description — sometimes called the control narrative — is a plain-language document saying what happens when each button is pressed, what the system does at power-up and shutdown, what happens on a source change, and what the automatic behaviours are.
It is written before programming and agreed with the client, because it is far cheaper to argue about a sentence than about code. It is also the document that lets a different programmer take the system over later, and the one the user interface layout is drawn from.
Configuration records
Every configurable device holds settings that took somebody hours to arrive at: DSP files, matrix presets, camera presets, network settings, gain structure, EQ, delays, thresholds, firmware versions and credentials. The record says what they are, where the backup file lives, and when it was taken.
Credentials are part of the record, but they belong in the client's secure store rather than in a drawing. What the document set says is where the credentials live and who holds them. A system whose passwords left with an employee is a system the client no longer owns.
Backups, and where they live
A configuration record without the file is a description of something you cannot restore. Take the backup at commissioning, take it again after every change, name it with the date and the revision, and store it in at least two places, one of which is not the rack.
Handover should include these files. A client who owns the drawings, the settings and the backups owns a serviceable system; one who owns only the hardware owns a dependency.
The records that are not drawings
These four documents carry everything a photograph of the rack cannot show.
| Record | Holds | Read by |
|---|---|---|
| Equipment list / BOM | Every device, model, quantity, location | Estimator, installer, client |
| IP schedule | Addresses, VLANs, switch ports, services | Service technician, IT department |
| Functional description | What the system does, in plain language | Programmer, client, trainer |
| Configuration record | Settings, firmware, presets, where backups live | Service technician |
- Passwords are referenced by location, never printed in an issued drawing set.
How to do it
- List every device that holds a configuration.
- Take a backup from each, using the manufacturer's own export.
- Name each file with system, device name, date and revision.
- Record the firmware version running on each device.
- Write the IP schedule from the devices themselves, not from the design intent.
- Store the files in the client's location and in yours.
- Note in the O&M manual where the files are and how to restore them.
- Repeat the whole process after any change, however small.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| A device is replaced and nothing sounds the same again | No configuration backup existed, so the settings were rebuilt from memory | Back up every configurable device at commissioning and after each change |
| IT refuses to allow the AV system onto the network | No network documentation, so nobody can tell them what it will do | Produce an IP schedule and a statement of network requirements before the conversation |
| The client cannot get into their own system | Credentials were held personally rather than handed over | Record where credentials live, transfer them at handover, and change any that left with staff |
| A new programmer takes three days to learn what the system does | No functional description; the behaviour exists only in the code | Write the description from the working system and keep it with the drawings |
Practice it
Pick one networked device in a system you support.
- Every device appears on the equipment list with the name the drawings use.
- Every networked device has an address, a VLAN and a port recorded.
- The functional description matches what the system actually does.
- A dated configuration backup exists for every configurable device.
- The client knows where the backups and credentials are.
System Design Basics
Documentation records a design, so it is impossible to document well without understanding how systems are designed. The logic is always the same three steps — need, devices, connections — and the discipline is doing them in that order rather than starting with the gear somebody already likes.
Documentation captures a design — so you need to understand designing a system too.
The design process
Documentation records a design, so understanding basic system design completes the picture. AV system design starts from the need: what must this system do (what are the goals, the room, the users, the budget)? From the need, you determine the devices — what gear meets the requirements (the sources, processing, and destinations to do the job). Then you work out the connections — how all the devices link together into a working signal flow. Need, devices, connections: define what it must do, choose the gear to do it, and connect it into a system. This is the logic behind every AV system, from a meeting room to a touring rig.
This design process is exactly backwards from documentation's perspective: you design the system (need to devices to connections), and you document the result (signal-flow diagram, rack elevation). Designing well means meeting the real need within constraints, choosing appropriate gear, and creating a sound signal flow — and then capturing it clearly in documentation. Even if you do not design large systems yet, understanding the design logic makes you far better at reading documentation and building systems correctly.
Starting from the need means starting with what people will do in the room, how many of them there are, where they sit, what they bring with them, what they expect to happen when they press one button, and what the budget and the programme allow.
Only then do devices get chosen, and only then do the connections between them settle. A design that starts at a product and works backwards produces a system that is impressive and slightly wrong.
Designing on paper first
A core professional principle is to design and document a system on paper (or screen) before building it. Working out the devices, connections, signal flow, and rack layout in documentation first catches problems while they are cheap to fix — a missing device, an incompatible connection, a signal-flow error — rather than discovering them mid-build with gear already racked. The documentation is the design tool: you design by creating the diagrams, refine them, and then build to them. This is far more reliable than improvising a system device by device and hoping it comes together.
Designing on paper also forces clarity: you must think through the whole system — every source to every destination, every connection, every rack slot — which surfaces issues and ensures completeness. Then the documentation you created to design the system becomes the plan to build it and the record to maintain it. This connect-it-on-paper-first discipline, captured in clear documentation, is what separates professional system work from ad-hoc assembly, and it is the practical heart of this book.
The drawing is the design tool, not a record made afterwards. You find the missing extender, the input that was needed twice, the run that is too long for its format and the rack that will not hold what you put in it by drawing them, and each discovery is free at that moment.
This is why experienced designers draw the ugly version first: a pencil block diagram whose only job is to be wrong quickly, where being wrong costs nothing.
Sources, processing and destinations
Every system, however large, resolves into three groups. Sources are what produces signal — microphones, cameras, laptops, players, computers. Processing is what happens between — mixing, switching, scaling, amplification, delay, conversion, distribution. Destinations are where signal lands: speakers, displays, projectors, recorders, streams.
Counting them is the first design act. Ten sources and four destinations with a requirement that any source can reach any destination is a matrix of a known size, and that number decides half the equipment list.
Counting inputs, outputs and the ones you forgot
The commonest design error in AV is an off-by-a-few count. The laptop input at the lectern, the second wireless microphone, the assistive listening feed, the recording output, the overflow room, the confidence monitor: each is one line on a drawing and a whole conversation on site if it was missed.
Design with deliberate spare capacity — spare inputs, spare outputs, spare rack units, spare conduit, spare network ports — and say on the drawing that it is spare. Systems grow, and the cheapest growth is the growth that was drawn in.
Where signals change form
Most design faults hide at the boundaries: analogue to digital, one video format to another, balanced to unbalanced, copper to fiber, baseband to network. Every conversion is a device, a cost, a delay and a place to fail, and every one should appear on the drawing as a box rather than as a hopeful line.
Ask of each conversion whether it is needed at all. A design with fewer conversions is cheaper, quieter, lower in latency and easier to fix.
Need, devices, connections -- what each step asks
Work top to bottom. Jumping to the second column is the classic mistake.
| Step | Questions | Produces |
|---|---|---|
| Need | Who, doing what, in what room, for what money | A written brief |
| Devices | What sources, processing and destinations satisfy that | An equipment list |
| Connections | What joins to what, in what format, over what distance | A signal-flow drawing |
| Physical | Where does it mount, how is it powered, how is it serviced | Plans and rack elevations |
| Behaviour | What happens when somebody presses the button | A functional description |
- The steps iterate. A connection that will not work at that distance sends you back to devices, and a device out of budget sends you back to the need.
On the job
A client asks for "a screen and a camera" in a meeting room. The designer asks who sits furthest from the screen, what the far end sees, who starts the meeting and what they bring. The answers turn a two-device request into a system with a specific display size, a microphone layout, a one-button start and an equipment list nobody has to guess at.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| The system works but nobody uses it | It was designed from products rather than from what people actually do | Go back to the need, in the room, with the people who use it |
| A device is added on site because an input was missed | Inputs and outputs were counted once and never checked against the brief | Count sources and destinations against the written brief before ordering |
| A video run does not work at its installed length | The distance was never checked against the format chosen | Check every run length against its format at design time; convert or change format on the drawing |
Practice it
Design a small system on one sheet of paper: a training room for twenty people.
- The need is written down and somebody has agreed to it.
- Every source and destination is counted and named.
- Every connection has a format that works over its real distance.
- Spare capacity is deliberate and marked.
- Power, mounting and service access have been thought about, not assumed.
Asking the Right Questions
A design is only as good as its brief, and a brief is a document like any other. This chapter is about the front of the job: how the need is discovered, what the phases of a design are called, what gets delivered at the end of each, and how a display size stops being an opinion and becomes arithmetic.
Needs analysis
Needs analysis is the structured conversation that turns "we want a new system" into something that can be drawn. It asks who uses the room and how often, what they do in it, what fails about the current arrangement, who supports it, what must not change, what the budget is and when it must be finished.
It is done with the people who actually use the room, not only with the person paying. The result is written up and agreed, because everything afterwards is measured against it, including whether the finished system is considered a success.
The programme report and the brief
The written output has various names — programme report, design brief, statement of requirements — and one purpose: to be the thing everybody points at when memories differ. It records the requirements, the constraints, the assumptions and what is deliberately excluded.
Write the exclusions down as carefully as the requirements. "This system does not record" and "this room does not support a second display" are the sentences that prevent the argument six months later.
The design phases
Larger projects run through named phases, and each ends with a deliverable somebody signs. Programme and concept establish what is needed and roughly how it will be met. Schematic design produces block diagrams, budgets and room layouts. Design development settles devices and the physical design. Construction documents produce the drawings and specifications people build and tender from.
Then the work happens: procurement, installation, commissioning and closeout, the last of which is where as-builts and O&M documentation are delivered. On a small job all of this happens in a week, but the sequence does not change, and knowing which phase you are in tells you how much detail your drawing is supposed to have.
Designing within constraints
Every real design is a negotiation between what is wanted, what the room allows, what the budget covers and when it must be ready. Structure, sightlines, ceiling height, daylight, acoustics, existing infrastructure and the client's IT policy all constrain the answer before any product is chosen.
The drawing records the outcome of that negotiation, and the brief records why. A drawing that shows an odd decision without a note attracts well-meant changes from people who do not know the reason.
Sizing a display from the viewing distance
How big a screen should be is not a matter of taste. The trade sizes displays from the distance of the furthest viewer and the kind of content: detailed content that must be read closely needs a larger image for the same room than content that is simply watched.
The method sets a relationship between image height and the furthest viewing distance, then checks that the nearest viewer is not too close and that the image is high enough off the floor to be seen over the people in front. A display chosen this way can be defended on a drawing; one chosen because it was on offer cannot.
Where the numbers on a drawing come from
A good drawing is full of numbers that each came from a calculation: display size from viewing distance, speaker positions from coverage, cable lengths from routes, loads from device draw, heat from load, rack weight from the equipment list.
Keep those calculations. When somebody challenges a number in two years — and they will — the calculation is the answer, and without it the number is only a memory.
Phases and what each one delivers
Same sequence on a hundred-room campus and on one meeting room.
| Phase | Question | Deliverable |
|---|---|---|
| Programme / needs analysis | What is needed, by whom | Written brief |
| Concept | Roughly how will it be met | Concept sketch and budget |
| Schematic design | What shape does the system take | Block diagrams, room layouts |
| Design development | Which devices, mounted where | Equipment list, plans, elevations |
| Construction documents | Exactly how is it built | Full drawing set and specification |
| Installation | Build it | Redlines as work proceeds |
| Commissioning | Does it meet the brief | Test records and punch list |
| Closeout | Hand it over | As-builts, O&M manual, training, backups |
- Phase names differ between countries and firms. The sequence and the deliverables do not.
How to do it
- Meet in the room, not in an office.
- Ask what happens in it now and what fails about that.
- Count the people, and find where the furthest one sits.
- Ask what they bring with them and what they expect to be automatic.
- Find out who will support the room afterwards, and what they can support.
- Ask for the budget, the deadline and the immovable constraints.
- Write it up, including what is excluded, and have somebody agree to it.
- Only then draw anything.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| The finished room is rejected although it does what was specified | The brief captured the buyer's requirements and not the users' | Include actual users in the needs analysis and record their tasks |
| Scope grows steadily and nobody can say when it started | No written brief, so every conversation adds requirements | Agree a brief, and handle additions as recorded changes against it |
| People at the back cannot read the screen | Display size chosen by budget or habit rather than by viewing distance | Size from the furthest viewer and the content type, and put the calculation on the drawing |
Practice it
Take a room you know well.
- The brief is written and agreed, including exclusions.
- The people who will use the room have been asked.
- The budget and the programme are known.
- The room's constraints have been measured, not assumed.
- Who supports it afterwards is known.
Working with the Other Trades
AV arrives late and depends on everybody. The conduit was installed months ago, the ceiling was closed last week, the power was drawn by an electrical engineer who never saw your equipment list, and the network belongs to a department that does not report to your client. Documentation is how you reach all of them in time.
What other trades need from you, and when
Containment, backboxes, floor boxes, structural support, power circuits, cooling and network ports are all installed by other people, long before the AV gear is delivered. Each of them needs information from the AV design at a point when the AV design is not finished.
That is the job: give them what they need early, in their own language, and mark it as provisional if it is. A late change to a conduit route is an email; a late discovery that there is no conduit is a wall.
The coordination drawing
Coordination happens on a shared background — the architect's plan — with each trade's work on its own layer. It is where you find that a projector mount lands on a structural beam, a speaker sits where a sprinkler must go, or a floor box falls in a walkway.
Every one of those clashes is cheap to solve on the drawing and expensive to solve on site. Attend the coordination meetings, take your own sheets, and mark up what moves.
Power, cooling and structure
Give the electrical contractor circuits, loads, positions and any requirement for clean or uninterruptible supply. Give the mechanical contractor the heat your racks produce. Give the structural engineer the weight and position of anything mounted, flown or stood on a raised floor.
None of those are AV calculations to sign off; they are AV numbers other professionals need. Supply the numbers, state your assumptions, and let the qualified person do the engineering.
Working with the IT department
On most modern projects the network is the hardest coordination of all, because it belongs to a department with its own rules and its own timeline. They will ask what devices you are adding, what addresses they need, what traffic they generate, whether multicast is involved, what ports must be open and who supports the devices.
Every one of those questions is answered by documents this book has already described. Arriving with an IP schedule and a written statement of network requirements turns a month of negotiation into a meeting.
Submittals, RFIs and change orders
On contracted work, three pieces of paper surround the drawing set. A submittal is what you propose to install, sent for approval before it is bought. An RFI — request for information — is a formal question when the documents are unclear or contradict each other. A change order records an agreed change to scope, cost or time.
They exist so that decisions are recorded rather than remembered. An instruction given verbally on site is worth nothing when the invoice is questioned; the same instruction confirmed in writing is worth exactly what it says.
What each trade needs from AV, and when
All of it is needed earlier than feels comfortable.
| Trade | Needs | By when |
|---|---|---|
| Electrical | Circuits, loads, positions, clean power needs | Before first fix |
| Builder / fit-out | Backboxes, floor boxes, wall reinforcement | Before walls close |
| Structural | Weights and fixing positions | Before mounts are ordered |
| Mechanical / HVAC | Heat load from racks and equipment rooms | During services design |
| IT | Device count, addresses, traffic, ports, support model | Before commissioning, ideally at design |
| Ceiling / joinery | Cut-outs, mounts, access panels | Before manufacture |
- If a figure is provisional, say so on the sheet and reissue when it firms up.
On the job
An AV team is issued a room where the projector position lands 80 mm from a sprinkler head. It was on the coordination drawing for three months and nobody from AV attended the meetings. The fix costs a re-designed mount, a change order and two weeks, and the drawing had been telling them since spring.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| There is no conduit to where a device must go | The containment requirement was never issued to the electrical contractor, or was issued late | Issue provisional routes early, reissue as they firm up, and check first fix on site |
| A wall will not hold a display | No reinforcement was requested because the weight was never communicated | Send weights and positions before walls close, and mark them on the coordination drawing |
| A site instruction is disputed at invoicing | The change was made on a verbal instruction with no change order | Confirm every instruction in writing, and price changes before doing them |
| Devices cannot be commissioned because the network is not ready | IT was engaged at installation instead of at design | Bring IT into the design phase with an IP schedule and a written requirements statement |
Practice it
Take a project you have worked on.
- Every trade that depends on AV has been given what it needs, in writing.
- Provisional information is marked as provisional and has a reissue date.
- Somebody from AV attends coordination meetings.
- Clashes found on the drawing are recorded and resolved before site.
- Every change carries a written instruction.
Building from the Drawings
No system is ever built exactly as drawn. A device is superseded, a route is blocked, a port is swapped at commissioning because the first one was faulty. The difference between a professional install and a mess is not whether those changes happen — it is whether they end up on the paper the same day.
Working from a drawing set on site
Start by checking you have the current revision of every sheet you need, and that the set is complete. Read the whole set before starting, including the sheets you think do not concern you: the detail you need is often on somebody else's sheet.
When a drawing is wrong, ambiguous or impossible, that is a question, not a decision. Ask it — informally on a small job, as an RFI on a contracted one — and record the answer. Installers who silently improve a design create systems nobody can service.
Redlines: marking up as you go
Keep one printed set on site as the redline set, and mark every deviation on it in red as it happens: the substituted device, the different route, the extra cable, the port that moved, the outlet that ended up on another circuit. Date each mark and initial it.
One set, one person responsible for it, kept in one place. Redlines spread across three people's phones are not redlines; they are three partial memories that will contradict each other in a month.
Turning redlines into as-builts
At the end of the work the redline set is transferred into the drawings, and the result is issued as the as-built revision. The equipment list, the cable schedule, the IP schedule and the configuration records are corrected at the same time, because a corrected drawing with a stale schedule is still wrong.
As-built is a status, not a document type. It means: this is the system as it stands today. Which is why the status has to be maintained after handover as well, every time anybody changes anything.
Changes after handover
Systems are modified for years after the installer leaves: a device added, a room re-purposed, a switch replaced, a firmware upgrade applied. Each of those is a documentation event, and each is skipped far more often than it is recorded.
The discipline that works is simple and unglamorous: nothing is considered finished until the drawing matches it. Half an hour on the day beats a day of tracing in two years, and everybody knows this and still needs the rule.
Version control in practice
One agreed location holds the current set, and everybody knows where it is. File names carry the project, the sheet and the revision. Superseded revisions move to an archive folder rather than being deleted, so that the history of a decision can be reconstructed.
Printed drawings are dangerous in exactly one way: they do not update. Print sparingly, mark the print with its revision, and throw prints away when a new revision is issued.
What gets redlined during an install
If any of these happen and nothing is marked, the as-built is already fiction.
| Event | Mark it on |
|---|---|
| A device is substituted | Signal flow, equipment list, rack elevation |
| A cable takes a different route | Cable schedule, plan |
| A cable is added or removed | Signal flow, cable schedule |
| A port or input changes | Signal flow, cable schedule, configuration record |
| A rack position changes | Rack elevation, plan |
| A circuit changes | Power drawing, rack elevation |
| An address changes | IP schedule |
| Behaviour is changed at commissioning | Functional description |
- Mark it the day it happens. Everything else is a plan to forget.
How to do it
- Print one set, mark it REDLINE, and keep it in one known place.
- Name one person responsible for it.
- Mark every deviation in red, dated and initialled, on the day.
- Photograph racks and cable routes before anything is closed up.
- Photograph the redline sheets at the end of each week so they cannot be lost.
- At completion, transfer every mark into the drawings and the schedules.
- Issue the corrected set as the as-built revision.
- Hand a copy to the client and keep one yourself.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| The as-built is produced from memory a month after completion | No redline set was kept during the work | Keep the redline set from day one; it is the only way an as-built is ever accurate |
| Two people made contradictory changes to the same drawing | The file was copied rather than controlled, so two currents existed | One location, one current revision, one person issuing |
| A service visit finds the system nothing like the documentation | Years of undocumented changes after handover | Re-survey the system, reissue an as-built, and make documentation part of every change |
| An installer 'improved' a design and nobody knows why the system behaves oddly | A field decision taken instead of a question asked | Raise ambiguities as questions, record the answers, and mark what was agreed |
Practice it
Take a system that has been modified since it was installed.
- Every deviation was marked on the day it happened.
- Drawings, equipment list, cable schedule and IP schedule were all corrected.
- It carries an as-built revision, a date and a name.
- The client holds a copy.
- Changes made since have been added to it.
Checking, Commissioning and Handover
A system is not finished when it works once in front of the person who built it. It is finished when it has been checked against what was asked for, the results are written down, the remaining faults are listed and cleared, and somebody else has been taught to run it.
Verification and commissioning
Verification is checking that what was installed matches what was specified: the right devices, mounted and connected as drawn, labelled, and performing to the stated requirements. Commissioning is bringing the system into service: configured, tuned, tested end to end and proved against the brief.
Both produce paper. A verification record says what was checked, by whom, on what date, with what result, and it is part of the document set exactly as much as the drawings are. "It worked when I left" is not a record.
What gets checked
- Every input reaches every intended output, in every mode the system offers.
- Levels, gain structure and any measured performance figure the brief stated.
- Every control function behaves as the functional description says.
- Labels match the drawings, on cables, panels and devices.
- Network devices are addressable and on the right VLAN.
- Power-up, shutdown and recovery after a power failure.
- Physical work: mounts secure, cables dressed, blanking panels fitted, racks safe.
The punch list
Whatever is not right at commissioning goes on a punch list — sometimes called a snag list: a numbered list of outstanding items, each with an owner and a date. It is a working document, reviewed until it is empty.
A punch list is a sign of a controlled job, not a failing one. What is dangerous is the item that is never written down, because it is the one that becomes the client's first impression of the system.
Handover and the operation manual
The operation and maintenance manual is what the client receives: what the system is and does, how to operate it in plain language, the drawing set as-built, equipment list with serial numbers, configuration records and where the backups live, warranty terms and dates, the maintenance the system needs, and who to call.
It is assembled during the job, not written the night before handover. Every document this book has described is a piece of it, and a client who holds a complete O&M manual owns a serviceable asset.
Training the people who will use it
Handover includes teaching: a session for users on what the room does, and a session for the client's technical staff on how it is built, how it is supported and what to do when something fails. Record who was trained and on what, because staff change.
Training that is delivered from the documentation also proves the documentation. If you cannot teach the system from the O&M manual, the manual is not finished.
Warranty, support and the life after
The documents say when the warranty starts and ends, what it covers, what response times were agreed, and what routine maintenance the system needs — filters, lamps or light sources, firmware, battery replacement, recalibration.
This is where documentation stops being a project deliverable and becomes an operations tool. It is also where a well-documented system quietly earns the next contract, because supporting it is cheap and pleasant.
The closeout package
What the client should hold on the day the job is signed off.
| Item | Purpose |
|---|---|
| As-built drawing set | How the system is actually built |
| Equipment list with serial numbers | What they own, for insurance and warranty |
| Cable schedule with test results | Proof and traceability of the wiring |
| Configuration records and backup files | Restoring the system after a failure |
| IP schedule | Supporting the system on the network |
| Functional description | What the system is supposed to do |
| Test and commissioning records | Evidence it met the brief |
| Punch list, closed | Nothing outstanding |
| O&M manual and training record | Operating and supporting it |
| Warranty and support terms | Who to call, and until when |
- A job with hardware finished and this package missing is not finished.
How to do it
- Get the current drawing set and the written brief in front of you.
- Check the installed system against the drawings, device by device.
- Verify labels against the cable schedule and correct both where they differ.
- Test every signal path in every mode, recording each result.
- Test every control function against the functional description.
- Power the system down fully and bring it back, and watch what it does.
- Record measured figures where the brief stated one.
- Raise everything outstanding on a numbered punch list with owners and dates.
- Take configuration backups and store them in two places.
- Sign, date and issue the records as part of the set.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| A fault appears a week after handover that was known during the install | It was never written on a punch list, so it was never assigned or cleared | Write down every known defect, however small, and close the list before handover |
| The client cannot operate the room and calls for every meeting | Training was a demonstration rather than a session with the people who use it | Train the users, leave a short plain-language guide in the room, and record who was trained |
| A device fails inside warranty and nobody can claim | No serial numbers or purchase dates were recorded at handover | Capture serial numbers during installation, not afterwards |
| The system cannot be restored after a failure | No configuration backups were handed over | Back up every configurable device and include the files in the closeout package |
Practice it
Take a system that has been handed over at your site.
- Every signal path and control function has been tested and recorded.
- The punch list is empty or agreed in writing.
- As-built drawings and corrected schedules are issued.
- Configuration backups exist in two places.
- Serial numbers, warranty dates and support terms are recorded.
- Users and technical staff have been trained, and it is recorded.
- The client holds the complete package.
Documentation on a Live Show
Live events document too, but the paper has different names and a much shorter life. A show's drawing set is built in a week, used hard for a day, and thrown away — except for the parts that go out again next year, which is why the good ones are kept.
The event's version of a drawing set
A show has a patch list or input list instead of a cable schedule, a plot instead of a plan, a block diagram of the system that is the same signal-flow drawing by another name, a rigging plot showing points and weights, and a power plan.
It also has documents an install never needs: a running order, a cue sheet, a channel list, a stage plan, and a pack list saying what came in the truck and has to leave in it.
Patch lists and channel lists
The patch list is the event's spine: channel number, what is on it, where it appears on stage, what kind of input it is, and which stage box and socket it lands in. Everybody works from it — the stage crew patching, the monitor engineer, the front of house engineer, the broadcast split.
It is printed, taped down and photographed, because it changes during rehearsals and the printed one becomes wrong. The version everybody agrees to is the one on the stage box at showtime.
Plots and drawings for a show
A lighting plot shows every fixture, its position, its address and its circuit. A video plot shows screens, projectors, processing and sources. A rigging plot shows points, weights and heights, and it is a safety document rather than a convenience.
These are drawn to scale over the venue plan because the questions are physical: will the throw work, is the point above the right place, does the truss clear the balcony. That is a different use of drawing from the topological block diagram, and shows use both.
Show files, presets and their backups
The console file, the media server project, the lighting show file and the processor configuration are all documentation in a real sense: they contain hours of decisions nobody can reconstruct under pressure.
A show goes one copy further than an installed system. The touring rule is three copies: the working one, one on a person, and one that is not near the truck. Named by date and show, saved at the end of every rehearsal and every night. This is the single most common documented disaster in live work, and it is entirely preventable.
What the two worlds should steal from each other
Installed-systems work should steal the event world's habit of a single printed page that everybody works from, and its brutal clarity about what is actually on stage today.
Event work should steal the install world's discipline about labels, revisions and keeping the drawing true as things change. A show file saved as final_FINAL_2 is the event version of a drawing with no revision block, and it costs the same.
Installed-system documents and their event equivalents
Recognise the document under the unfamiliar name.
| Installed system | Live event |
|---|---|
| Signal-flow diagram | System block diagram |
| Cable schedule | Patch list or input list |
| Equipment list | Pack list or gear list |
| Rack elevation | Rack drawing or racking sheet |
| Plan and reflected ceiling plan | Lighting, video and rigging plots |
| Configuration record | Show file and presets |
| Functional description | Cue sheet and running order |
| As-built | The marked-up patch list at the end of the day |
- The names change with the country and the sector. The questions each document answers do not.
On the job
A festival monitor engineer arrives to find the patch list three revisions old and the stage boxes patched to the current one. Ten minutes before doors, the fix is not cleverness but paper: one printed list, taped to the box, agreed by the two people who own it, photographed by everybody else.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| Two departments patch to different versions of the list | The list changed during rehearsal and only one copy was updated | One controlled copy on the stage box, with changes marked and photographed by everybody |
| A console dies and takes the show file with it | One copy, on the device that failed | Three copies, one off the truck, saved at every break |
| Next year's return of the same show starts from scratch | The show's documents were thrown away at load-out | Archive the final patch list, plots and files with the show's name and date |
Practice it
Take a show or event you have worked.
- One controlled patch list exists and everybody has photographed it.
- The plots match what is actually rigged.
- Show files are saved in three places, named by date.
- Changes during rehearsal were marked, not remembered.
- The final versions were archived for the next time.
Documenting Well & Using Documentation
Everything in this book reduces to four words — clear, consistent, accurate, current — and to one habit: writing things down at the moment they become true. The rest is convention, and conventions can be learned in an afternoon.
Clear, current documentation is a skill that pays off through the system's whole life.
Documenting clearly and consistently
Good documentation is clear, consistent, accurate, and current. Clear means anyone in the trade can read it without confusion — standard symbols, clean layout, complete labels. Consistent means it follows conventions so different documents and different people's work align. Accurate means it reflects the real system. Current means it is updated as the system changes (kept as-built). Documentation that is messy, inconsistent, wrong, or outdated fails at its job and can actively mislead. The discipline of producing and maintaining quality documentation is itself a valued professional skill.
Labelling ties documentation to the physical world: cables, devices, and ports labelled to match the documentation mean anyone can connect the drawing to the actual system. A signal-flow diagram is far more useful when the real cables carry the labels it shows. This consistency between the documents and the physical, labelled system is what makes documentation truly usable on the floor, and it reflects the same labelling discipline seen in prep and warehouse work.
Clear means a stranger in the trade reads it without asking a question. Consistent means the same symbol, the same name and the same layout everywhere, so a reader learns your set once. Accurate means it matches the physical system. Current means it matched it this morning.
Of the four, current is the one that fails, because it is the only one that needs maintaining after the work feels finished.
Using documentation through the system's life
Documentation serves a system across its whole life, which is why it matters. During the build, it is the plan everyone works to. During operation, it shows how the system works so people can run it. During troubleshooting, it is what you trace to find a fault — a signal-flow diagram turns a mysterious problem into a traceable one. During servicing and upgrades, it tells the next person how the system is built and configured. And at handoff, it transfers the system to the client or the next team as a documented, maintainable asset rather than a black box. Good documentation pays off at every one of these stages.
Master the core documents (signal-flow diagrams, rack elevations, as-builts), the design logic behind them, and the discipline of clear, current documentation, and you become someone who builds systems the right way — designed on paper, built to plan, documented for the future. This is foundational professional knowledge (part of the CTS body of knowledge) that makes you more capable on every system you touch, and it is exactly the discipline behind every well-run AV installation and organised live show.
The same set does five jobs: it is the design tool, then the build plan, then the operating reference, then the troubleshooting map, and finally the asset record the client owns. Most of the cost is paid at the start; almost all the value is collected later.
This is why documentation is so often under-resourced. The person paying for it is rarely the person who benefits from it, and the benefit arrives years later, quietly, as problems that never happened.
Practical sign-off
Documentation skill is built by reading and creating real docs. The learner reads a signal-flow diagram and rack elevation, creates clear versions for a small system, keeps an as-built, and uses documentation to trace a system. A mentor signs off when the learner can document a small system clearly and accurately.
- Read and narrated a signal-flow diagram and rack elevation
- Created clear, consistent documentation for a small system
- Kept documentation as-built and matched labels to the physical system
- Used documentation to trace and troubleshoot a system
Troubleshooting from the drawings
A signal-flow diagram turns a fault from a mystery into a bisection. Pick a point halfway along the path, prove whether signal is there, and you have halved the problem. Repeat, and four or five measurements find almost anything.
Without the diagram you cannot bisect, because you do not know what the path is. That is the whole difference between a technician who fixes a system in twenty minutes and one who is still there at midnight, and it is almost never about talent.
How much documentation is enough
Enough is the point where a competent stranger can build, operate, troubleshoot and service the system without contacting the person who made it. Less than that leaves a dependency; much more than that is cost without a reader.
Scale it to the system. A rehearsal room rig needs a one-page block diagram, a labelled rack and a settings backup. A campus needs a full drawing set. Both need the same four qualities.
Honesty in documents
Never sign a check you did not perform, never draw a circuit you did not verify, and never issue a document you know to be wrong without saying so. The next person is going to act on it, possibly on a ladder, possibly on a live system.
When you do not know, say so on the sheet: assumed, to be confirmed, not verified. A marked uncertainty is professional. A confident wrong line is the thing that gets somebody hurt.
The four qualities, and how each one fails
Each quality fails in a characteristic way. Recognise yours.
| Quality | Fails as | Costs |
|---|---|---|
| Clear | Private symbols, crowded sheets, no legend | Questions, and drawings nobody opens |
| Consistent | Three names for one device | Wrong cable, wrong port, wasted hours |
| Accurate | Drawn as intended rather than as built | Faults chased in the wrong place |
| Current | Never updated after a change | Documentation that actively misleads |
- An out-of-date document is worse than no document, because it is trusted.
On the job
A technician is sent to a site nobody at the company has visited for three years. In the rack door there is a printed elevation, a cable schedule and an IP schedule, all dated after the last change. They find the failed device in ten minutes, and the client assumes it was easy. It was easy — somebody made it easy, years ago, in half an hour.
What goes wrong
| Symptom | Likely cause | What to do |
|---|---|---|
| Everybody works around the documentation instead of from it | It has been wrong often enough that nobody trusts it any more | Re-survey, reissue once accurately, and never let it drift again; trust is rebuilt only by being right |
| The documentation is enormous and still does not answer questions | Volume substituted for the four qualities | Ask what question each document answers, and cut anything with no reader |
| A fault takes a day to find in a system that is fully drawn | The drawings were never used because nobody knew they existed | Keep a copy with the system — in the rack, on the wall — not only in a project folder |
Practice it
Judge a real document set against the four qualities.
- A stranger in the trade could read it without asking you anything.
- One thing has one name, everywhere.
- It matches the physical system today.
- The last change made to the system is on it.
- A copy lives with the system, not only in a project folder.
Documentation as a Career Skill
Documentation is the least glamorous skill in AV and the one that most reliably moves people up. It is how a technician becomes the person who is asked what the system does, and then the person who decides what the next one will be.
Why documentation gets people promoted
Somebody who can draw a system accurately can be trusted to describe it to a client, to hand it to a colleague, to estimate a change and to run a job. Those are the tasks that separate a technician from a lead, a project engineer or a designer, and every one of them is documentation with a different name on it.
It is also the most visible skill in the trade. A clear drawing with your name in the title block is read by people who will never watch you work.
Building the habit on your own work
Start with the systems you already touch. Draw the rack you maintain. Write the patch list for the rig you set up every week. Take a configuration backup of the processor you nurse. Put a printed elevation in the rack door.
None of that needs permission or software, and within a year you will be the person who knows where everything is, which is a reputation that travels.
Where this sits in the trade's qualifications
Documentation, design process and project phases are core to the industry's general certification, and the vocabulary in this book — needs analysis, phases, verification, closeout — is the vocabulary those examinations use.
It is also the entry point to the design and consulting side of AV, where the deliverable is entirely paper, and to project management, where the deliverable is a job that finished with everything written down.
What to keep from every job
- A copy of any drawing set you worked from, if the client's agreement allows it.
- Your own notes on what the design got right and what it did not survive contact with.
- Templates: a title block, a cable schedule, a functional description you can reuse.
- The measurements you took, because they are the start of your own judgement.
- The punch list items that recurred, because those are your checklist for next time.
Where documentation skill leads
Each of these roles is documentation-shaped work with a different title.
| Role | What the documentation becomes |
|---|---|
| Lead technician | The drawing everybody on the crew works from |
| Project engineer | The set that turns a design into a build |
| Commissioning engineer | The test record that proves the system |
| AV designer | The whole deliverable |
| Consultant | The tender set other companies price and build |
| Service manager | The as-builts and records that make support profitable |
- Every one of these roles is closed to somebody whose systems exist only in their own head.
Practice it
Do one of these this week, on a system you already touch.
- The systems you look after are drawn.
- Their racks carry a printed elevation.
- Their settings are backed up and dated.
- You keep templates you improve after every job.
- Somebody other than you could take over tomorrow.
Glossary
| As-built | Documentation corrected to match the system exactly as it was installed. |
| Backboxes | The recessed boxes in a wall or floor that AV plates and outlets mount into. |
| Bill of material | The commercial list of everything that must be bought for a system. |
| Blanking panel | A blank rack panel fitted over empty rack units to control airflow. |
| Block diagram | A signal drawing showing the shape of a system with detail deliberately left out. |
| Cable schedule | The list of every cable: identifier, type, both ends, route, length and test result. |
| Change order | A recorded, agreed change to a project's scope, cost or time. |
| Closeout | The final project phase, delivering as-builts, records, training and handover. |
| Commissioning | Bringing a system into service: configured, tested and proved against the brief. |
| Configuration record | What each configurable device is set to, and where its backup file lives. |
| Containment | Conduit, tray or basket that cables run in, installed by another trade. |
| Coordination drawing | A shared background on which every trade's work is checked for clashes. |
| Detail | A close-up drawing of one arrangement, drawn large. |
| Documentation | The drawings and records describing a system. |
| Elevation | A drawing of a vertical face, such as a wall or a rack front. |
| Equipment list | Every device in a system, with model, quantity, location and drawing name. |
| Functional description | A plain-language document saying what the system does when operated. |
| IP schedule | The record of network devices, addresses, VLANs and switch ports. |
| Needs analysis | The structured conversation that turns a request into a written brief. |
| NTS | Not to scale — a diagrammatic drawing that must not be measured from. |
| One-line | A drawing that collapses multi-conductor connections to single lines for readability. |
| Operation and maintenance manual | The closeout package handed to the client, covering how the system is run and supported. |
| Patch list | The live-event equivalent of a cable schedule: channels, sources and stage box positions. |
| Plan | A drawing looking down at a floor, showing positions and routes. |
| Plot | A scaled event drawing showing fixtures, screens or rigging points in the venue. |
| Punch list | The numbered list of outstanding items at commissioning, each with an owner and date. |
| Rack elevation | A drawing of what is mounted where in a rack, by rack unit, top to bottom. |
| Rack unit | The standard 44.45 mm increment of rack-mount equipment height, written U. |
| Redline | A mark made on a drawing during the work, recording a deviation the day it happens. |
| Reflected ceiling plan | A drawing looking up at a ceiling, for mounts, projectors and speakers. |
| Revision | The identifier and date recording which version of a drawing this is. |
| RFI | Request for information — a formal question when documents are unclear or contradictory. |
| Sequencing | The designed order in which devices in a rack power up and down. |
| Signal-flow diagram | The drawing of how signals travel between devices, from sources to destinations. |
| Submittal | What an installer proposes to install, sent for approval before purchase. |
| System design | Turning a need into devices and connections. |
| Title block | The panel on a drawing naming the project, sheet, revision, date and author. |
| Verification | Checking that what was installed matches what was specified, and recording the result. |
What the gear actually looks like
Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.
Find the destination.
Work along the path between them.