Cable ID Standards and Numbering Systems

What is a cable ID standard?

Your identifiers get their rulebook from the cable ID standard. How many fields an ID has. What each field means. How wide the number runs. Which signal types get their own namespace.

You set it once at the top of a project, and it sits upstream of everything physical. The tag that carries the ID onto the wire and the schedule that records every ID with its endpoints are both covered in how you label cables and ports. This article is about the scheme itself: the numbering system those two documents inherit.

Get the scheme right and the rest is bookkeeping: every run inherits a clean, sortable ID and nothing collides. Get it wrong and you find out mid-build. Bake in the wrong information, run out of digits, overload one prefix: renumbering then means reprinting tags and re-touching every row of the schedule.

TIA-606 vs show-world prefix schemes: which fits your job?

Two design philosophies dominate cable identification, and they optimize for opposite worlds.

Location-based standards like ANSI/TIA-606, the telecom industry's structured-cabling administration standard, identify a cable by where it physically lives: which building; which telecom room; which rack; which patch-panel port. That suits permanent infrastructure, gear installed once and left for years. The ID doubles as a map.

Signal-family prefix schemes are the show-world convention. They identify a cable by what it carries and nothing else: a family letter (V video, A audio, N network, C control, P power) plus a zero-padded running number. So V007 is video run seven wherever it is plugged in tonight. That suits gear that moves: a touring rig, a flypack, a broadcast remote. Any location baked into the ID would be a lie by load-out.

The permanent-ID principle: the ID names the cable, not the patch

One principle sits under every durable scheme: the ID identifies the physical cable, not the job the cable is doing today. What a cable carries and where it lands are properties of the current patch. Patches change. So the stable ID belongs to the cable. Everything volatile lives in the schedule beside it rather than in the tag: the signal name, the endpoints.

It also tests which fields a scheme may safely encode. A field is safe to bake into the ID only if it is as permanent as the cable itself. A running number is safe: it belongs to the cable forever; a signal family is usually safe too, since a video cable stays a video cable. A destination is not safe: 'CAM1-SW3' becomes a lie the first time that run is re-patched to a prompter, and a venue location is not safe for touring gear either, though it is safe for fixed plant, which is exactly why TIA-606 location fields work for installs and fail for tours.

Printing the same ID on both ends, keeping the signal name on a separate line: the labeling mechanics that enforce this in the field are covered in the cable and port labeling workflow. The scheme's narrower job is to guarantee that the only thing printed as the permanent ID is information that stays true after the next re-patch. Run each candidate field through one question first. Will this still be true after the cable is re-patched and recoiled and shipped to next week's venue? If not, it belongs in the schedule, not the ID.

How do you design the ID fields?

Two required parts make up a show-world ID, plus one optional one in bigger systems:

• Family prefix: one or two letters for the signal family. V video, A audio, N network, C control, P power. This is the namespace, and numbering restarts inside each one.
• Running number: zero-padded, unique within its prefix, assigned in the order you draw runs. Zero-padding is not cosmetic, it keeps IDs sorting correctly so V002 lands before V014 on paper and on screen.
• Optional qualifier: a system or location field, added only when a job genuinely spans multiple self-contained systems (front-of-house versus monitor world, Studio A versus Studio B) and only when that boundary is as permanent as the cable. For a single flypack, skip it. A bare prefix and number is cleaner.

Field width is the one number that bites people.

Pick it for the biggest job the scheme will ever see rather than today's job, because widening it later means renumbering. Count the runs in your largest signal family. Then add headroom for the field adds that always happen.

Largest single family on your biggest job: video, roughly 120 runs (estimate from the diagram, not from memory)
Add headroom for on-site adds and future growth: about 50 percent
120 x 1.5 = 180 runs to plan for
2 digits caps at 99 runs: too small, it overflows mid-tour
3 digits caps at 999 runs: comfortable headroom, V001 up to V180 with room to spare
Chosen width: 3 digits, zero-padded (V001)

Give every signal type you count separately its own prefix rather than stretching an existing one. Fiber, power, and analog audio each earn a letter. One consistent namespace per family beats a clever exception you have to explain to the next tech.

When should an ID carry location or rack information?

Volatile fields are what the permanent-ID principle bans. It does not ban all context. When the context is genuinely permanent, encoding it is not a violation; it is the TIA-606 idea applied with judgment. Three cases earn a location or system field:

• Fixed installs. In a building that will not be re-patched for years, a rack-and-port field turns the ID into a map, which is the entire value of the location-based approach. This is where a full TIA-606-style scheme pays off.
• Multi-system shows. A festival with independent front-of-house, monitor, and broadcast worlds can prefix a system letter so V007 in one world never collides with V007 in another, as long as those worlds stay separate for the run of the show.
• House infrastructure inside a touring venue. The venue's installed tie-lines and patch bays get location IDs, while your touring gear that plugs into them keeps portable signal-family IDs. The two schemes meet at the patch panel and stay in their lanes.

A location field dies when the location changes, so it is the field most likely to make a scheme lie. Add it only where the location genuinely outlives the patch. Keep it in its own position so a reader can take it in or ignore it at a glance.

How do you roll out a scheme without collisions?

IDs get assigned in one place, before anything is cut, or the scheme does not hold.

Assign them on the signal-flow diagram as you draw each run. The ID on the drawing, in the schedule and on the printed tag is then one value that never diverges.

1. Write the scheme down first: list every family prefix the job needs, the number width, and any system or location field, in one line at the top of the project.
2. Assign numbers on the diagram, in family order, as you draw each connection. A number assigned at the wire is a number nobody double-books.
3. Reserve a range per family for on-site adds (say V180 to V199) so the inevitable last-minute run does not force an improvised out-of-scheme ID.
4. Let the cable schedule inherit each ID with its endpoints, type, and length, so the scheme becomes a view of the diagram rather than a second document.
5. Preserve member IDs when runs bundle into a loom or snake: the trunk gets its own ID and its members keep theirs.
6. Match the endpoint fields to the real ports through port-to-port documentation, so every ID resolves to a physical hole.

A port-aware tool does the collision-checking for you. Assign an ID once on the diagram and it flows into the cable schedule, the gear list and the rack builder without being retyped. Two runs cannot quietly share V007. For the columns before adopting a tool, start from a cable schedule template, or see the whole chain on one documented sample show.

Frequently asked questions

Is TIA-606 required for AV cable labeling?

Not for portable production. TIA-606 is a telecom structured-cabling administration standard aimed at fixed infrastructure, and it is genuinely useful there. Touring and broadcast crews almost always run signal-family prefix schemes instead, because a location-based ID stops being true the moment the gear moves. Use TIA-606 logic for permanent installs and portable prefixes for gear that tours. Where a client or local code mandates a specific standard, follow it and confirm with the cabling designer or AHJ.

Should the cable ID include the source and destination?

No. Baking endpoints into the ID, like CAM1-SW3, makes the tag lie the first time the run is re-patched. A wrong label costs more time than no label. The ID names the cable; the endpoints live in the schedule, which is cheap to update. This is the same rule the labeling workflow enforces on the physical tag.

Can I mix a location-based and a signal-family scheme?

Yes, and large shows often do: the venue's permanent infrastructure carries location-based IDs. Your touring gear carries portable signal-family IDs. The two meet at the patch panel while staying in their own lanes. The rule that keeps a hybrid honest is unchanged: any field baked into an ID has to be as permanent as the cable, so location codes go only on gear that does not move.

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