How to Document AV Connections

What is an AV connection list (IO list)?

One output port on one device wired to one input port on another: that is the unit of record, a single connection. An AV connection list, usually called an IO list or input/output list, is the complete set of every signal connection in a system. One row per physical link.

The list is just the honest sum of those rows, and it is the backbone of your AV wiring documentation.

Three documents describe the same system, and they are easy to confuse: the signal-flow diagram is the picture, what feeds what, drawn to be read; the IO list is the ledger, every connection captured as data you can sort and filter and count; and the cable schedule is a view of that ledger arranged for the people pulling and labeling cable. Same underlying facts, three shapes. Document the connections once and well; all three stay in agreement.

What does one connection record hold?

On a connection record, every field answers a specific question a builder or troubleshooter will ask.

First six: the working minimum. The rest earn their place as the system grows or the show gets more critical.

Step 1, Build the list from the diagram, not from memory

Documenting connections from memory is how you end up with a list that describes the show you imagined rather than the one you are building.

Work from the drawing. Every line on a finished, port-aware signal-flow diagram is already a connection record waiting to be written down:

1. Start at the first source and walk its output to wherever it lands. Write the row: from device and port, to device and port, signal type.
2. Assign the cable ID and a plain-language signal name as you write each row, not in a second pass. A row without both is not finished.
3. Move to the next output on that device, then the next device, until every drawn line has become exactly one row.
4. Include the infrastructure hops explicitly: source to converter is one connection, converter to switcher is another. Two rows, because there are two cables.
5. Cross off each line on the diagram as you record it. The lines with no cross are the connections you almost forgot.

Doing this by hand once teaches you why it hurts. Every system edit means editing the diagram, then the list, then the cable schedule. They drift the moment you are busy. Deriving all three from one connection-aware model removes the drift. In WireFlow each connection is drawn port-to-port and the wiring documentation is generated from those links, so the list cannot disagree with the picture.

Why record every connection port-to-port?

Intention is what a box-to-box note ("Camera 1 to Switcher") records.

A port-to-port record (Camera 1 / SDI OUT 1 to Switcher / SDI IN 3) records a buildable fact. It forces the problems into the open while they are still cheap paperwork instead of expensive show-day surprises:

• Format mismatches surface on the page: a laptop HDMI output aimed at an SDI input now visibly needs a converter, which means the converter earns its own rows and lands on the gear list.
• Input counts become real: five sources documented into a four-input device fails in the spreadsheet instead of at load-in.
• Port conflicts are caught: two runs claiming the same SDI IN 2 is obvious in a list sorted by destination port, invisible in a box-to-box sketch.
• Each record maps one-to-one to a physical cable, which is what makes the cable schedule trustworthy rather than approximate.

How the list becomes your cable schedule and signal names

Once every connection is a row, the downstream documents are views of the same data rather than new documents to maintain. Sort the list by cable ID and hand it to the crew pulling cable: that is the cable schedule. Filter it to one device and read the signal names: that is the patch list for that rack. Count distinct devices in the endpoint columns and you have started the gear list. Signal name and cable ID do different jobs. A good record carries both:

• The cable ID is how you find the physical cable in a loom of eighty. It is unique and it never changes.
• The signal name is how you reason about the system without tracing wire. It says what is on the run, and it is the label that changes when a run is repurposed.

For each source or processing device, count the outputs you have patched: outputs_used
Count the rows where that device sits on the From side: from_rows
A complete list has from_rows == outputs_used for every device
Example, a switcher patched to program, multiview, and record:
outputs_used = 3
from_rows for the switcher = 3  ->  balanced, nothing undrawn
If from_rows is less than outputs_used, a live output has no destination on record: go find it

How much detail is enough?

Record at port level for every connection a human will build or patch or trace. Summarize only what is genuinely atomic: you document the two ends of a stagebox snake rather than the pairs inside it, because nobody re-patches inside the snake on show day. The rule: if someone will plug it, patch it, fault-find it, it gets a record.

Some fields depend on numbers you should not guess.

Maximum run length for a format varies by product. So does the exact connector on a model, and how a proprietary link is terminated. Mark those pending rather than inventing a figure, then confirm them against the source before the list is issued.

Keep the list current: proposed vs as-built

You plan from the proposed connection list. What actually got built, after the house patch turned out different and a camera moved to a longer run, is the as-built. Update the records during or right after load-in, while changes are fresh. Mark each row's status. Version the list. The as-built is what you hand the client, and it makes the next show at that venue start from truth instead of memory. Date each issue and mark its state, per signal-flow best practices.

Frequently asked questions

What is the difference between an IO list and a cable schedule?

Same connection records, viewed for different jobs. The IO list is the master ledger of every port-to-port link, organized to be complete and queryable; the cable schedule is that ledger arranged for the crew pulling and labeling cable, usually sorted by cable ID with lengths and looms added. Build the connection list first. The cable schedule is a view of it.

Is an AV connection list the same as a wiring diagram?

Same connections, different media. The wiring diagram is the visual form: boxes and lines you read at a glance. The connection list is the tabular form, one row per link that you can sort and count and diff between versions. A port-to-port diagram and its IO list should always agree, which is easiest to guarantee when both are derived from one model rather than maintained by hand.

Do control and network connections belong on the same list?

Yes. Keep them in the same project, usually flagged by signal family (video, audio, network, control) rather than split into disconnected files. The connections that break shows are the cross-trade ones: a control cable to a tracking camera, an audio embed onto a video feed, a Dante link between a mixer and a stage box. Splitting families across separate documents is exactly how those links get orphaned. See switch and port documentation for the network side.

How do I document a connection when I do not know the exact port yet?

Record the row anyway and mark the unknown as pending. The connection exists the moment you know two devices must be linked; the specific port is a detail to confirm rather than a reason to leave it undocumented. A row with a to-be-confirmed port still counts toward your gear and cable totals, and it still shows up on the coverage check. That is what keeps it from being forgotten.

What is the minimum a connection record needs?

Both endpoints as device plus port, the signal type, a unique cable ID, and a plain-language signal name. With those five fields any competent tech can build the run, find the cable, reason about the signal. Everything else (cable length, loom assignment, status history) is worth adding as the system grows but is not what makes the record buildable.

Generate your cable schedule from the diagram

WireFlow derives the cable schedule from your signal-flow diagram, every run labeled end-to-end, exportable for the shop and the truck.

Start a free diagram · Download the CSV template instead