As-Built vs Proposed AV Drawings

What is the difference between proposed and as-built AV drawings?

Confusing them is how a tech shows up to service a system carrying a drawing that went obsolete the day load-in started. Same system, two points in its timeline. Not two unrelated documents. A proposed drawing answers what do we intend to build, and what will it cost? An as-built answers what is actually installed right now?

Between them sits a third state, and naming all three keeps the argument straight:

• Proposed: the design you bid and sell from. It reflects intent, the system as specified, before a single cable is pulled. Clients approve it and estimators price from it.
• Issued (for construction): the released, approved set the crew builds to on site. It is the proposed design frozen and stamped as the current build target.
• As-built: the issued set corrected to match reality, every substitution, re-patch, and field change captured. It is the drawing a service tech should trust, because it describes the system that actually exists.

The document states from bid to handoff

One diagram moves through a predictable set of states; track which state a drawing is in and half of the confusion on a project disappears, because everyone knows whether they are looking at a plan or a record.

Why version AV drawings at all?

Nobody trusts a drawing nobody can date. So everyone re-verifies the system by hand every time, which defeats the point of documenting it. Versioning is what lets a drawing carry authority:

• Service without a scavenger hunt: a tech dispatched months later works from the as-built instead of tracing every cable to rediscover the system.
• Change control: when the client asks why the scope grew, dated revisions show exactly what changed and when.
• Blame-free troubleshooting: "the drawing says SDI IN 3, the patch is on IN 4" is a five-second find when the drawing is current, and an hour when it is not.
• A head start on the next phase: the as-built is the proposed drawing for the next revision, so work compounds instead of restarting from memory.

Here is where a single-source tool earns its place: because the gear list, cable schedule, and rack views all derive from the same diagram in WireFlow, versioning the diagram versions the whole document set at once, with no reconciling five separate files by hand; the corrected drawing exports straight into a crew-ready AV tech pack.

When do you update the drawing?

Update the moment reality diverges from the drawing rather than at some tidy milestone later; the usual triggers on an AV install:

• A substitution: the specified converter was out of stock and a different model shipped.
• A re-patch: house AV handed you a different set of tie lines than the drawing assumed.
• A quantity change: two extra sources appeared, or a display got cut from scope.
• A physical move: a camera relocated to a longer lens position, or the rack moved rooms.
• A commissioning fix: a path that did not work got re-routed to one that does.

How to redline during load-in

Redlining is the discipline of marking every deviation from the issued set as it happens: on site, while you still remember why. The goal is not a pretty drawing; it is a complete one. A workable field method:

1. Carry a version of the issued set you can mark up: a printed copy with a red pen, a PDF on a tablet, or the live diagram open on a laptop. Red exists so changes are unmistakable against the black issued lines.
2. Mark the change at the point it happens: strike the old connection, write the new port, note the new device model. Capture the endpoint, not just the word "moved".
3. Note why in two words when it matters: "out of stock", "house patch", "client add". The reason is what makes the change defensible later.
4. Photograph the rack and key patch points at the end of load-in. Photos resolve the redlines you cannot read the next morning.
5. Reconcile daily on multi-day builds. A redline you transcribe that night is accurate; one you transcribe from a week-old scribble is fiction.

Who gets which version?

Matching the right state to the right audience prevents most documentation disasters:

• Client, at bid: the proposed set, clearly labeled proposed, so an early draft is never mistaken for a commitment.
• Crew, at load-in: the issued set, and only the issued set. A crew building from an old proposed draft builds the wrong system confidently.
• Client and service, at handoff: the as-built, plus the derived gear list and cable schedule. This is the deliverable that closes the job.
• The next crew: the as-built becomes their starting proposed drawing for the next phase.

Read-only share links help here: instead of emailing a PDF that is stale the moment the next redline lands, share the live diagram so crew and client always open the current version; the AV installation handoff checklist lists the full set of deliverables while sharing with clients and crew covers link setup.

How do you turn redlines into a clean as-built?

Redlines are raw field truth. The as-built is that truth made legible for someone who was not there. Converting one to the other is a mechanical process rather than a rewrite:

1. Open the issued diagram as the base. Never start the as-built from a blank page; you will lose the connections nobody redlined because they did not change.
2. Apply each redline as an edit to the real connection: change the port, swap the device, update the cable ID so the drawing and the physical label still agree. See how to label cables and ports.
3. Re-derive the dependent documents. The gear list and cable schedule should regenerate from the corrected diagram, not get hand-edited to match it.
4. Bump the revision, date it, and set the state to as-built in the title block.
5. Export the handoff packet: diagram, gear list, cable schedule, and rack views together. See exporting diagrams and tech packs.

Keeping drawings alive across revisions

Documented once and never touched again, a system rots. The install changes and the drawing does not, until the drawing is worse than useless because it lies with authority. Treat the diagram as a living record:

• A version scheme, not vibes: dated revisions with an explicit state (proposed / issued / as-built) beat "Final_v2_REAL.pdf". See versioning your documentation.
• One source, many exports: version the diagram and the derived documents follow. Reconciling five separately edited files is how versions quietly drift apart.
• A revision note: one line per revision saying what changed and why. Future you reads it in five seconds instead of diffing two PDFs.

Never let the gap between the drawing and the rack survive past load-in. That is the practical rule. Redline in the field. Reconcile to an as-built at handoff. Every future visit then starts from truth. Start the signal-flow diagram as a proposed draft, and the same project carries it all the way to as-built.

Frequently asked questions

What does as-built mean in AV?

An as-built, also called a record drawing, is the version of an AV drawing corrected to match what was physically installed, after every substitution, re-patch, and field change from the original design. It is the drawing a service tech should trust, because it describes the system that actually exists rather than the one that was proposed.

Is a redline the same as an as-built?

No. A redline is the raw, in-progress markup made in the field during load-in, changes struck and rewritten in red over the issued set. The as-built is the clean drawing produced by applying those redlines back into the base diagram and re-issuing it. Redlines are the input; the as-built is the finished record.

What is the difference between issued for construction and as-built?

Issued for construction (IFC) is the approved set the crew builds to, the plan frozen and released. As-built is that same set corrected after the build to reflect what was actually installed. IFC is forward-looking (what to build); as-built is backward-looking (what got built).

Who owns the as-built documentation, the integrator or the client?

Ownership is set by your contract, not by default, so confirm it in the deliverables section before the job starts. Commonly the client or owner receives the as-built as a project deliverable while the integrator keeps a copy for service. When it is unclear, defer to the signed agreement and the project specification.

How often should proposed drawings be updated before install?

Update the proposed set every time the design materially changes during approval, and re-issue it so the crew never builds from a superseded draft. Once the design is approved and released it becomes the issued set, and further changes are tracked as redlines and revisions rather than edits to the proposal.

Build this diagram in WireFlow

Port-aware devices, validated connections, and exports your crew can read on site. Free plan includes three editable diagrams, no credit card.

Start a free diagram · Explore the sample show first