How to Create an AV Tech Pack
By WireFlow Team · Published 2026-07-11 · Updated 2026-07-11 · 9 min read
An AV tech pack is the document set a crew needs to build, run, and strike a show's technical system without calling the designer: signal-flow diagram, gear list, cable schedule, IP schedule, rack elevations, plus the plots and contacts that support them. Build it in strict order, diagram first, every other document derived from that drawing, and the pack stays consistent by construction. It passes when a competent stranger could build the show from it alone.
First, which "tech pack"? (Not fashion, not a rider)
Two disambiguations before anything else, because the term is overloaded. In fashion and apparel, a tech pack is the garment specification a designer sends a factory, measurements, materials, stitching. Different industry, different document; if that's what you searched for, this isn't it. In event production, the tech pack is the technical documentation package for a show's AV system, and that's what this guide covers.
The second mix-up is closer to home: the technical rider vs. the tech pack. A rider is what the artist or act *requires*, channel counts, monitor mixes, backline, power. It's a demand made of the production. The tech pack is how the system is *actually built*, the answer to the rider and everything else the show needs. Rider says "we need eight monitor mixes"; tech pack shows which console, which outputs, which cables, and which wedge every mix lands on.
So the working definition: the tech pack is the document set a crew needs to build, run, and strike the system without calling the designer. Every document in it exists to answer a question someone will otherwise radio you about at 7 a.m.
What goes in an AV tech pack
The contents flex with the show, a two-camera panel doesn't need an LED wall plan, but the full set looks like this:
| Document | What it answers | Source of truth |
|---|---|---|
| Signal-flow diagram | What feeds what, port to port | The master document, everything else derives from it |
| Gear list | What ships, and how much of it | Derived from the diagram |
| Cable schedule | Every run: ID, both ends, type, length | Derived from the drawn connections |
| IP schedule | Address, subnet, VLAN for every networked device | The network layer of the same diagram |
| Rack elevations | What lives in which RU, front and rear, with internal patch | Rack drawings built from the gear list |
| LED wall plan / pixel map | Cabinet layout, data paths, pixel geometry | The wall spec (when the show carries a wall) |
| Power plot | Where power lands and what draws from it | Power report laid over the venue plan |
| Run-of-show / labor pointers | Who does what, when | Production office, referenced, not duplicated |
| Contact sheet | Who to call when something breaks | Production office |
The last two rows matter: the tech pack doesn't *author* the run of show or the crew schedule, those live with the production office, but it points to them, because the tech crew works from one packet, not a scavenger hunt. Methods for the core documents are covered in their own guides: how to build a cable schedule, how to create an IP schedule, and how to design an AV rack elevation.
Assemble in this order: the retype-nothing principle
The classic tech pack failure isn't a missing document, it's two documents that disagree. The cable schedule says SDI, the diagram says HDMI, and the crew discovers the disagreement at the worst possible time, then trusts neither document for the rest of the show. Disagreement comes from retyping: every document built by hand from another document is a copy that starts drifting the moment it exists.
The fix is an assembly order where nothing is retyped, every document is *derived* from the one drawing:
- Draw the signal-flow diagram port-to-port. This is the single source of truth; the method is in how to create an AV signal-flow diagram.
- Derive the gear list from the diagram, every device on the drawing is a line item, and nothing that isn't drawn ships.
- Derive the cable schedule from the drawn connections, each port-to-port line becomes a run with an ID, endpoints, type, and length.
- Assign IPs on the same drawing, then export the IP schedule, the network plan lives on the system diagram, not in a separate spreadsheet with its own opinions.
- Build rack elevations from the gear list, place what actually ships, front and rear, and document the internal patch.
- Add the wall plan and power documentation where the show needs them.
- Wrap it: cover page, revision block, contact sheet, and pointers to the run of show and crew schedule.
This is the workflow WireFlow is built around: the gear list, cable schedule, and power report are generated from the same diagram data, rack elevations export as install-ready PDFs, and the tech pack export bundles diagram, gear list, and cable schedule into one crew-ready packet. Change the design, re-export, and every page still agrees, see exporting diagrams and tech packs for the mechanics.
Versioning and distribution: issued vs. as-built
A tech pack has two lives. The issued pack is the plan, versioned, dated, and sent with enough lead time that the crew reads it before they travel. The as-built pack is what actually got constructed after the venue's house patch turned out different and two runs got re-pulled; it's updated during or immediately after load-in, and it's what the client keeps and the next show at that venue starts from. One person owns the current revision; everyone else consumes it.
- PDF for the truck, the pack must work with zero connectivity, printed or on a tablet, because loading docks are where Wi-Fi goes to die.
- Link for the phone, a read-only share link opens the current version on any crew phone without an account; WireFlow share links work exactly this way, so "which PDF is current" stops being a group-chat archaeology project. See sharing with clients and crew.
- Revision discipline, date and revision on every issue, changes summarized on the cover, superseded versions clearly retired. The scheme is in versioning your documentation.
What a good pack looks like at 2 a.m. under a work light
The pack is consumed in the field, so judge it by field conditions:
- Page numbers and document titles on every page, pages separate from their packet within an hour of load-in, and an orphan page must still identify itself.
- Revision date on every page, not just the cover, because the cover is the first page to disappear.
- Readable at arm's length on a dark stage, real font sizes, high contrast, no 8-point labels that were legible on a 27-inch monitor and nowhere else.
- Offline-usable, no login, no assumption of venue internet, nothing that only renders in the design software.
- One name per device, everywhere, the device is called the same thing on the diagram, the cable schedule, the rack elevation, and the case label. Synonyms read as different devices to a tired crew.
The hand-off test
The finished pack gets one exam: could a competent stranger build, run, and strike this show from the pack alone? Not a genius, not a mind-reader, a solid tech who has never seen this system. If anywhere in the build they'd have to call you, the pack has a hole at that spot. Every question they'd ask is a missing label, an undrawn connection, or an undocumented decision.
The practical version: hand the pack to a colleague who wasn't on the design and have them talk you through the build, document by document. Where they hesitate, fix the pack, not the explanation, the explanation won't be on the truck. When it passes, the show has stopped living in your head, which is the entire point: the designer who must be on site for the build is a single point of failure, and this document set is the redundancy. For where the pack sits in the wider prep timeline, work through the full AV preproduction checklist.
Frequently asked questions
- What's the difference between a tech pack and a technical rider?
- The rider states requirements, what the artist or act needs provided (inputs, monitors, backline, power). The tech pack documents the built system that satisfies those requirements: the diagram, gear, cables, addresses, and racks. Rider is the question; tech pack is the worked answer.
- Is this the same as a fashion tech pack?
- No. An apparel tech pack is a garment manufacturing spec, measurements, fabrics, construction details sent to a factory. The event/AV tech pack shares nothing with it but the name. This guide covers the event production document.
- What's the minimum viable tech pack for a small show?
- Three documents: a port-to-port signal-flow diagram, the gear list, and the cable schedule, plus a contact sheet. That set already lets someone else build the system and lets you troubleshoot it by document instead of by memory. Add the IP schedule the moment the rig has more than a handful of networked devices.
- Who creates the tech pack?
- Whoever designed the system, typically the system designer, engineer in charge, or the production manager wearing that hat. Ownership matters more than title: one person issues revisions, and everyone builds from the issued version, not from side conversations.
- When should the tech pack be issued?
- Before the crew travels, with enough lead time to actually read it, questions that arrive while you can still change the design are free, and the same questions at load-in cost truck time. Then update it to as-built during or immediately after load-in, while the changes are still fresh enough to be true.
Export a full tech pack from WireFlow
Diagram, gear list, cable schedule, and rack views in one crew-ready PDF packet, generated from a single project.