Commissioning and documentation
The handover from a network that is installed to a network that is trusted, and the paperwork that keeps it that way.
What it is
Commissioning is the process of proving that what was designed is what was built, and recording it. That means verified link speeds and duplex on every run, confirmed multicast group membership under realistic load rather than on an idle fabric, PoE draw measured against budget, and failover exercised once with results written down. The documentation side is the port map, the VLAN and address tables, switch configuration backups, a written restore procedure, and a labeling scheme that matches the paperwork the crew will actually open. A baseline capture of healthy traffic belongs in the same package, because it is the reference you compare against when something changes and nobody knows what.
Why it matters
A show network is handed to people who did not build it and will maintain it for months or years. The commissioning package is what makes that handover survivable. Without it, every fault becomes an investigation from first principles, usually conducted by one person under time pressure with the house filling. With it, a dead switch is a swap and a config restore, an unexpected device is visible against a known baseline, and a change made during the run can be traced. It also protects the design itself: undocumented systems drift, because each small undocumented change is reasonable on its own and the accumulation is what eventually breaks.
Configuration backups plus a written restore procedure, so a dead switch is a swap rather than an investigation
A baseline capture taken while the system is healthy is the reference you will want at half hour
Label at both ends, to the same scheme as the paperwork the crew opens, not a scheme that lives in the design file
Document what happens when each single element is removed, and who is permitted to change the configuration
What belongs in the handover pack?
Physical and logical topology, port map, VLAN and address tables, switch configuration backups with a restore procedure, PoE budget with remaining headroom, protocol paths showing what sends what to whom, tested failover behavior, and contacts with an escalation path. It should be usable by a competent engineer who has never seen the rig, because that is who will eventually open it.
How do we validate multicast before load-in ends?
Test under load, not at idle. Confirm group membership on the switches rather than inferring it from a stream that appears to work, since flooding can make a broken snooping configuration look healthy. Then check the ports that should not be seeing a given group and confirm they are not. Capture the result as the baseline, because the same test after a change is what tells you whether the change mattered.
Who owns the network once we open?
Name a person and an escalation path in writing, and be explicit about who may change configuration. The failure mode without this is not malice, it is a series of individually sensible adjustments by different departments with nobody holding the whole picture. Change control on a show network can be lightweight, but it needs to exist and it needs a log.