A rack elevation looks like the least interesting document in a build. It is a rectangle with lines in it. That is exactly why it causes more disputes than any other artefact in a data center project.
When an elevation is treated as a sketch, three things happen. First, decisions that should have been made on paper get made on the floor, by whoever is holding the screwdriver. Second, changes happen silently — a network switch moves two U because a rail kit would not fit, and nobody updates the drawing. Third, at handover, the documentation describes a rack that no longer exists.
What "signed" actually means
A signed elevation is a statement about four things, and if any of them are missing it is not a plan, it is a hope.
- Position and orientation. Every U is assigned, including the blank ones. Airflow direction is explicit, not assumed from a photo of the front.
- Power. Which device is on which PDU, and which feed. A/B assignment written down, not decided when someone notices both cords came out of the same strip.
- Weight and load. Heavy items low, load distributed against the rack rating and the floor loading spec. This is a safety decision, not an aesthetic one.
- Cable entry and service loops. Where cable enters, how much slack is left, and how it will be dressed. Retrofitting this later means pulling devices.
The deviation log is the point
Plans survive contact with reality badly, and pretending otherwise is how you lose an evening. The useful discipline is not a perfect plan — it is a rule that nothing changes without being recorded.
Every deviation gets a line: what changed, why, who approved it, and when. Two consequences follow. The engineer on the floor stops having to make silent judgement calls, because logging is faster than arguing. And at handover, the as-built matches the physical rack because the drawing was updated as reality diverged from it.
If your contractor hands you as-built documentation with no deviation log, you should ask a follow-up question: either nothing changed, which is implausible, or the changes were never written down.
Make it a deliverable, not a drawing
The practical move is contractual. Elevations are a deliverable with an approval step before mobilisation, and an as-built revision issued at handover. Both are dated, both are versioned, and both are attached to the acceptance pack.
Once the elevation is a deliverable rather than a convenience, most build disputes disappear — because the disagreement that would have happened in week six now happens in week one, on paper, when it costs nothing to fix.
Need this applied to your site?
Our engineers run these checks as standard on every delivery. Send us the scope and we will tell you what we would look at first.