To correct a rail alignment, an installed expansion shelf is shifted in-rack; afterward nobody touches its cabling, because the chain 'has always been fine.' What must happen before the chain is trusted again?

Any physical relocation of a shelf changes the geometry of every attached cable. An interconnect can end up partially withdrawn from its port, a power cord can rock loose in its inlet, and slack that was dressed can become tension across the connector interface. The accepted practice after moving equipment in a rack is to inspect and reseat both ends of the shelf's interconnects and power cords, then re-verify that both of the shelf's paths report healthy, before the chain carries service again. Relearning bays in the configuration database fails by concept: the shelf's identity and its documented position did not change when the rails did, and if enumeration now fails the cause is physical, not bookkeeping. Self-healing links fail as a dangerous comfort: an auto-recovered link after a transient cannot be distinguished from one now under steady tension that will drop on the next failover, which is precisely the case the re-inspection exists to catch. A firmware resync treats an invented cause — rail work does not desynchronize enclosure services — and replaces looking at the copper with a guess. Exam caveat: every physical change to layout reopens the cabling verification step. Operational check: visually inspect and reseat both ends of the moved shelf's links and cords, confirm both paths healthy, and note the move in the install log.