Data Center Design
Data Center Drawing Releases: Keep Revision and Workfront Together
A drawing release register connects each document revision to the work it is authorized to support. A recent file date or an Approved stamp is insufficient without the applicable area, scope and release authority. Keep superseded instructions identifiable and unresolved changes visible to the field team.
Separate three questions that often get combined
First, which file version is this? Second, what review outcome does it have? Third, for which work may the project use it? A file can be the latest version while awaiting review, or approved for one area while another area remains unresolved. Capture those distinctions rather than storing a single current checkbox.
Use the project’s actual status definitions. Spell out terms such as issued for review or issued for construction rather than relying on an acronym whose meaning may differ between teams. This article does not assign legal significance to a stamp or establish who has design authority.
Give each field release an applicability record
Record the document identifier, revision, status, release reference, applicable location/work package and exceptions. Include the superseded revision so someone encountering an older print can identify the conflict. The original example below is independent of any document-control software.
Scroll the table horizontally on smaller screens.
| Document/revision | Review state | Field applicability | Release or hold reference | Source |
|---|---|---|---|---|
| Cabinet layout D-101 / Rev B | Reviewed under project workflow | Cabinet group C only | Authorized release R-18; previous Rev A superseded for this group | Planning analysis |
| Cable route D-205 / Rev C | Review open | Affected overhead route not released | Question Q-07; design owner to resolve entry conflict | Planning analysis |
| Endpoint schedule S-010 / Rev D | Reviewed under project workflow | Links L-01 through L-20 only | Release R-19; other links retain their stated revision | Planning analysis |
| Field observation FO-12 | Observation, not an approved design | Records a discrepancy at cabinet C4 | Disposition pending; does not authorize a route change | Planning analysis |
Original illustrative planning record. Values and identifiers are examples, not a customer record, engineering design or acceptance standard.
Record the references behind the host drawing
A host drawing revision does not, by itself, identify every file that contributes to its displayed content. Autodesk describes a DWG Xref as a link to another drawing and notes that changes to the referenced drawing are reflected when the host is opened or the reference is reloaded. This is a specific AutoCAD behavior, not a statement about every design platform. For document control, the consequence is that an unchanged host filename can be opened against a different reference state. A familiar-looking title block is not enough to identify the complete issue.
Ask the drawing author to identify the dependency set behind the deliverable: the host document and revision, each referenced document and its intended issue, the parent-to-reference relationship, the retained file or controlled version location, and unresolved or intentionally omitted inputs. Include references inside references where they contribute to the issued content. Keep a project revision identifier separate from a file-format version, saved-file date or storage path. If the project retains checksums, use them to identify bytes; they do not establish review or release authority.
The recipient needs a declared basis to compare with the files received, not just a folder named Latest. Record a missing file, an unexpected revision and an intentional exclusion as different conditions, and send the discrepancy to the nominated document or design owner. Do not relabel an unexpected file as the intended revision or silently substitute a convenient newer reference. Actual CAD loading, path changes, reference binding and technical compatibility checks belong to the agreed authoring/review scope; this record is not a command sequence or approval to edit the model.
References: [X1]
Compare the received package, not just the title block
Fictional example EX-XR07 concerns package PK-41 for workfront W-A. Its retained issue record names host D-401 / B, direct reference XR-PHYS / R3, and nested reference XR-AREA / R2 beneath XR-PHYS. It also lists two PDF sheets, D-401-01 / B and D-401-02 / B, under illustrative release REL-41, and a separate model M-COORD / R6 issued for review. These are invented document relationships and decisions, not a customer package or permission to perform work.
The received host still says Rev B, but the supplied XR-PHYS file identifies itself as R4 and XR-AREA / R2 is absent. Those are two documentary discrepancies in the declared native dependency set. The two PDF sheets retain their stated B issue, while the newer review model is not included in REL-41. Neither the file-open result nor the model's later date resolves which instructions remain applicable. Return the discrepancy against the affected package and workfront to the release owner; retain the record of any existing limited release rather than silently treating it as extended or cancelled.
The owner may need to return the intended files, explain a documented exclusion, or issue a revised package and scope decision. Record which response was actually supplied and which question remains open. A decision about the native reference set does not automatically change the separately identified PDF issue, and an unchanged PDF issue does not prove that missing native dependencies are harmless. The project must establish the relationship between those deliverables. Preserve the original receipt and the later correction as separate issues so another team can reconstruct the basis of its work.
Scroll the table horizontally on smaller screens.
| Declared item and relationship | Received record | Documentary return to the responsible owner | Source |
|---|---|---|---|
| Host D-401 / B → XR-PHYS / R3 | Host B is present and still names the expected reference relationship. | Retain the host issue; its unchanged revision does not resolve the reference discrepancy. | Planning analysis |
| Direct reference XR-PHYS / R3 → XR-AREA / R2 | The supplied file identifies itself as XR-PHYS / R4, despite the expected reference filename. | Record expected R3 versus received R4. Request the intended issue or an explicit revision/applicability disposition; do not rename R4 as R3. | Planning analysis |
| Nested reference XR-AREA / R2 beneath the declared XR-PHYS / R3 | No XR-AREA / R2 file was supplied. | Record the missing declared input separately. Its absence is not evidence that the area contains no installation requirement. | Planning analysis |
| PDF sheets D-401-01 / B and D-401-02 / B; REL-41 lists W-A only | Both stated sheet issues are present; their native-source relationship still needs the discrepancy disposition. | Identify these two outputs and their retained limited release. Ask the owner whether the reported dependency mismatch affects that release; no use or cancellation decision is invented here. | Planning analysis |
| Separate coordination model M-COORD / R6; issued for review | A more recent file is present, outside the stated REL-41 instruction set. | Keep it in its declared review purpose. It is not a substitute for a missing reference or a newly authorized installation issue. | Planning analysis |
Original fictional record. The declared native chain contains one host, one direct reference and one nested reference. The two sheet outputs and one separate review model have their own identities and purposes. No actual CAD contents, file integrity, drawing adequacy, authority, site condition or installation result was checked.
Distinguish a model view from an issued installation package
A clear 3D view can make a proposed arrangement easier to discuss. It does not identify all of the instructions, source dependencies, notes, schedules, unresolved interfaces or release decisions the project requires. A screenshot also cannot tell the recipient whether a relevant item is absent, outside the view, intentionally excluded or awaiting an answer. Ask for the identified information set and its intended use rather than judging readiness from visual polish.
The distinction is not 3D versus PDF. A project can define an identified model issue as part of its authorized installation information, with the required supporting information, applicable scope and responsible release decision. Conversely, a neatly plotted drawing or a successfully created ZIP can still be a review issue or an incomplete delivery. Autodesk's Package Drawing documentation describes a configurable group of drawings and dependencies; packaging files is a different fact from the project's review and release outcome. Confirm the actual deliverable and recipient requirements with the author instead of assuming a software export supplies them.
Before asking a team to rely on a package, resolve the information questions below through the project's nominated owners. The answers establish its documentary basis; they do not certify engineering adequacy, site fit, safety, constructability or completed installation. When an answer is missing, identify the affected use and the owner who must decide it rather than adding an Approved label to a presentation image.
References: [X2]
Scroll the table horizontally on smaller screens.
| Information question | Evidence to identify | What appearance alone cannot establish | Source |
|---|---|---|---|
| What is the governing information set for this workfront? | The identified model, sheets, schedules or other agreed documents; each issue and the applicable location/scope. | A useful view is not automatically the complete or governing instruction set. | Planning analysis |
| Which inputs and dependencies produced this issue? | The retained source/reference issues and the declared relationship to outputs, with missing or excluded inputs visible. | An unchanged filename or attractive export does not prove that the expected reference set was used. | Planning analysis |
| What must the recipient be able to retrieve and read? | The agreed files and supporting information, required views or schedules, recipient formats and the actual missing-file/readability return. | A thumbnail, successful transfer or one open view does not prove completeness or usability of the full agreed delivery. | Planning analysis |
| For what purpose and scope was it issued? | The project's actual review/release reference, nominated authority, stated workfront and exceptions. | Visual quality, a software approval or a later upload does not determine project authority. | Planning analysis |
| How will an affected recipient recognize a later change? | The superseded issue, affected outputs/workfronts, recorded distribution and the next responsible decision. | A refreshed image does not reconcile prior instructions or verify the work already recorded against them. | Planning analysis |
Original buyer information questions, not a universal BIM requirement, construction-release procedure or engineering checklist. The project defines its governing information, review roles and release authority.
Handle a revision during an active shift
Illustrative example: a new route revision appears while links using the previous release are being installed. Identify which links and locations the change affects, record the current physical state and ask the authorized owner whether the work remains valid. A blanket instruction to use the newest file could discard a location-specific release or conceal rework.
Record the decision and its effective workfront. Keep work completed under an earlier valid release traceable to that revision and any later disposition. Do not overwrite the source of a field record merely to make every document show the same letter.
Version the cable row and the issued snapshot
Keep a cable schedule’s document revision separate from the identity and change history of its individual link records. A document issue freezes the population and values sent for a stated purpose. A link ID lets a reader trace the same intended connection through those issues. If the project uses row revisions or change references, carry them alongside the stable ID. The third row in a sorted export is not a stable identity.
Retain the input basis for each issue: port-map and route revisions, applicable workfront, included link population, review outcome, release reference and unresolved exceptions. Do not create a current installation view by selecting the newest timestamp from every incoming spreadsheet. That can assemble a collection of individually recent rows that was never reviewed or released together. A location-limited release should remain visibly limited in the exported view.
NASA’s configuration-management guidance distinguishes identified baselines, proposed changes and their implementation status. That is a general traceability principle, not a cable-schedule versioning mandate. The project must define its actual status vocabulary and the people authorized to review and release the work.
References: [N5]
Scroll the table horizontally on smaller screens.
| Record or date | What it identifies | What it does not establish | Source |
|---|---|---|---|
| Schedule CS-REV / R1 or R2 | A retained snapshot, its included link population and source-input revisions | R2 is not automatically authorized for every link or workfront. | Planning analysis |
| Link EX-R701 with its row/change reference | One intended connection traced across snapshots | A changed row number or label output is not a new link identity. | Planning analysis |
| Observation / evidence time | When a stated physical observation was made and under which source issue it was recorded | The observed value is not automatically the new approved design. | Planning analysis |
| Issue / release time and applicable scope | When the package was issued and when its stated use was authorized, if authorized | A saved-file time does not substitute for either record or establish receipt by every crew. | Planning analysis |
| Recipient / acknowledgement reference | Which recipient received a named issue and any recorded acknowledgement | Receipt is not proof that physical work, testing or acceptance is complete. | Planning analysis |
Original documentation distinctions. Date names, row revisions and status terms are illustrative; agree the project-specific system. They do not create design, contractual or site authority.
Show the field revision at link level
Fictional example EX-REV-13 starts with four links, EX-R701 through EX-R704, in retained schedule CS-REV / R1. A field observation FO-09 then reports a possible B-end discrepancy for EX-R702. Change request CR-17 proposes revising that endpoint, removing EX-R703 and changing the route reference for EX-R704. Keep the observation, the request and the resulting decisions as separate records; submitting the request does not approve all three edits.
In the example, decision DEC-17 authorizes the R702 endpoint revision and the R703 removal for workfront W-A, while the proposed R704 route change remains held under Q-18. The declared R2 issue therefore includes R701 unchanged, R702 revised, R704 at its retained R1 technical values with the route question visible, and an explicit removed R703 history entry. Its release reference REL-22 is limited to R701 and R702 in W-A. R704 is not included in that release. These invented decisions explain the records; they do not establish an actual release process or authorize work.
R1 contained four active requirements. The approved removal leaves three active requirements in R2, plus one retained removal-history entry. Two active links fall within the example release scope; the third remains outside it. Those numbers are different from the number installed, tested, accepted or physically removed. EX-R703’s earlier installation evidence stays linked to R1 and its later disposition remains open. A deleted requirement is not evidence that the corresponding physical assembly has disappeared.
Scroll the table horizontally on smaller screens.
| Stable link | R1 record and known physical evidence | Proposal / decision | R2 record and release treatment | Source |
|---|---|---|---|---|
| EX-R701 | A1 → B1; no installation evidence supplied | No change proposed | Same active requirement; included in fictional REL-22 / W-A. No completion is inferred. | Planning analysis |
| EX-R702 | A2 → B2; FO-09 reports observed B9, with no acceptance result | CR-17 proposes B3; DEC-17 approves B3 for W-A | Expected endpoint becomes B3; prior B2 and observed B9 remain in history. Included in REL-22; physical reconciliation is still open. | Planning analysis |
| EX-R703 | A3 → B4; INST-08 records work against R1 | CR-17 proposes removal; DEC-17 approves requirement removal | Removed from active requirements, retained in the change history. INST-08 is not rewritten; physical disposition is unresolved, not automatically removed. | Planning analysis |
| EX-R704 | A4 → B5 via route RT-A; no installation evidence supplied | CR-17 proposes RT-B; that edit remains held under Q-18 | Retains RT-A technical values with the open route question. Excluded from REL-22; no current field permission is inferred. | Planning analysis |
Original fictional decision record, not an actual cable plan or instruction. Four active R1 requirements minus one approved requirement removal = three active R2 requirements. Two released, one outside that release; the removal-history entry is not a fourth active requirement.
Distribute a revision without rewriting the field history
Freeze the actual file or dataset issued under R2 and retain its change summary, source references, limited release and recipients. Show which prior view it replaces and where earlier applicability still needs a decision. A delta is a review aid; give the team access to the complete applicable issue as well, so an unchanged row is not lost merely because it was absent from the change list. Where another system produces labels, material views or reports, record which source revision each output used and which affected outputs require reconciliation.
At the workfront, separate a question about using an instruction from a claim about the work already performed. Preserve the earlier applicable release and recorded physical state while the nominated owner resolves an affected-link conflict. Record the resulting decision against the link, issue and workfront. Acknowledging R2, updating a dashboard or closing a document-control task does not itself verify a physical correction, a test result or customer acceptance. Actual hold, change and release decisions remain with the authorized project owners.
A late observation can also change the evidence without changing the intended endpoint. For example, correcting a mistyped identifier in an observation requires a retained correction trail and evidence basis; it should not be disguised as an approved design change. Conversely, a genuinely approved endpoint change should remain visible as such rather than being called a clerical correction to avoid its review. Agree the distinction, decision owner and output-reconciliation scope before issuing the next snapshot.
References: [N5]
Provide the register with the installation package
Before field release, make sure the team can retrieve the actual files, locate the applicable revision and identify the contact for a conflict. At handoff, preserve the release references, approved deviations and outstanding questions alongside the installed records. A register that points to unavailable files is incomplete evidence.
Leviathan can discuss layouts, routing coordination, schedules and installation-planning documentation within a defined engagement. Confirm the production resources, reviewer and formats for that package. Licensed professional engineering, stamped drawings and regulatory design authority are not implied by a document register or CAD-based layout.
References: [L2]
Check the cabling information, not only the drawing status
A release register identifies the issue and its authority. The cabling information still needs to identify the intended work. A drawing with a current approval stamp can leave the recipient unable to distinguish two similar cabinets, locate an endpoint, join a route to its connection rows, or identify which assembly the material list describes. Return the actual missing information rather than treating the stamp as a replacement for it.
Agree how the drawing and schedules divide that information. A route drawing need not repeat every port row if it points unambiguously to the applicable schedule issue. Conversely, a schedule containing endpoint names does not supply missing route geometry, drawing notes or location references. Make those relationships retrievable, including where another sheet or detail supplies a transition. A readable legend, units and location reference matter because a recipient must understand what a line or identifier means, not merely find it on the sheet.
The following are original buyer review questions, not a universal drawing standard, a field method or a declaration of constructability. Actual pathway suitability, dimensions, separation, supports, loads, safety requirements and installation criteria require the responsible design/site/OEM disposition. The issuer must define the permitted use and exceptions. Document completeness and technical adequacy are different review outcomes.
Scroll the table horizontally on smaller screens.
| Information relationship | What the recipient needs to recover | What still needs its own review | Source |
|---|---|---|---|
| Connection to physical endpoints | Stable connection ID, qualified cabinet/equipment/panel/port identities and the applicable port-map issue. | Actual endpoint identity, configuration and technical suitability; similar display labels are insufficient. | Planning analysis |
| Connection to route | The identified route or segment relationship, location reference, units/legend and supporting sheets or details where needed. | Actual geometry, pathway constraints, safety, separation and constructability. | Planning analysis |
| Connection to material requirement | Approved assembly or explicit component relationship, exact part/option basis or a visible unresolved input. | Actual compatible products, quantity basis and appointed purchasing/supplier decision; a drawing is not an order. | Planning analysis |
| Connection to field and handoff views | The applicable label/record relationship and outputs required for the defined physical scope. | Actual observation, work authorization, measurement and customer/system acceptance. | Planning analysis |
| Whole information issue | Drawing/schedule/input revisions, workfront, named release reference, exclusions and unresolved questions. | The responsible owner’s actual decision about use; completeness alone grants no engineering authority. | Planning analysis |
Original information review, not dimensions, routing instructions, engineering certification or an installation-release instrument. The package may use several linked documents rather than place every field on one sheet.
Carry the ordered platform basis into the port map and BOM
For Rubin planning, retain the exact system and document scope behind the port map. NVIDIA’s named DGX Vera Rubin NVL72 guide describes a rack-scale system and separates hardware, network-port and interface-name information. A Rubin family name alone does not identify which physical termination, logical name or purchased equipment issue a project record means. Request the documentation applicable to the supplied OEM system instead of filling a project map from a different family’s reference illustration.
For Helios handoff, keep reference architecture and supplied implementation distinct. AMD explicitly describes Helios as a reference design for OEM and ODM systems rather than a product for sale. The handoff therefore needs the actual offered or supplied implementation, its retained configuration and applicable manufacturer information. An approved-looking Helios presentation cannot, by itself, supply that missing identity or authorize Leviathan to act as an OEM service provider. This distinction is about the input and responsibility boundary; it is not a claim about product availability or the contents of an actual order.
Before the appointed purchasing owner relies on the material requirement, connect its part and quantity basis to the identified configuration, port/connection issue and route/length inputs where those affect the selected assembly. Before a physical team relies on the installation issue, identify which internal assemblies arrive within the supplied-system scope and which external connections or other tasks belong to the separately agreed package. The nominated source/design owners must resolve mismatches. A change to the external connection set can require a revised material view without changing the identity of every supplied rack component.
Fictional EX-RH17 illustrates two different documentary returns. Package R names a DGX Vera Rubin system issue and an external connection schedule, but its material view was generated from a superseded schedule. Return the affected connection population and component requirements for reconciliation; do not call the BOM current because the platform name matches. Package H names only a Helios reference design and lacks the offered OEM implementation’s port and supplied-component basis. Request that basis before representing the package as ready for the stated physical work. Neither return selects a product, approves a topology, changes an order, authorizes field work or establishes an accepted installation.
Common planning questions
Is the latest uploaded drawing always the one to install from?
No. Check its review state, authorized scope, applicability and release record. A newer upload may still be under review.
Does this replace design approval?
No. The register records the project’s actual decisions and authority. It does not create engineering qualifications, site permissions or a construction release.
How should a cable schedule be versioned through field revisions?
Retain complete document snapshots, stable link IDs and row/change history, the source-input revisions, and each change’s proposed, decided and implemented states. Issue the applicable workfront/release scope with the dataset and keep earlier physical evidence traceable. A newest-row merge or overwritten spreadsheet is not a substitute for an identified issue.
Does approving one cable change release every row in the revised schedule?
No. Record which edits were approved and which links/workfronts the actual release covers. A revised file can still contain held questions or retained values outside the release scope. The EX-REV-13 example has three active requirements in R2 but only two within its stated release.
What happens to a removed cable row if work was already recorded against it?
Remove it from the active requirement view only under the recorded disposition, while retaining its identity, prior revision and work evidence in history. A requirement removal does not prove physical removal, authorize disconnection or establish material returns. The authorized owner must separately dispose the actual physical state.
Does the host drawing revision identify every Xref revision?
Not by itself. Identify the expected reference documents and issues, including relevant nested relationships, and compare them with the retained files or controlled versions delivered. Keep a document revision separate from a file-format version or saved timestamp. In AutoCAD, linked reference content can change when a referenced file changes; an unchanged host title block is not a complete dependency record. Actual software checks and edits remain with the agreed author and reviewer.
Does a successful file transfer or transmittal release the package for construction?
No. Receipt, file completeness/readability, review outcome and authorized use are different records. A package can transfer successfully while containing an unexpected reference revision or remaining issued for review. Record the actual release scope and exceptions, and return any discrepancy to the nominated owner rather than treating a ZIP file or a successful open as authority.
Can a 3D model be part of the authorized installation information?
Yes, if the project's defined process identifies the model issue, required supporting information, intended use, applicable scope and responsible release decision. The objection is not the file format. A polished view without those records is not evidence of an authorized package, and a PDF without them has the same limitation. No actual model, engineering adequacy or site permission is approved by this article.
Must every cabling field appear on the drawing sheet?
No. The agreed package can divide information across drawings, details, endpoint schedules and material views, provided the applicable issues and relationships can be recovered unambiguously. A current drawing status does not resolve missing endpoint, route, material or release information.
Does a Rubin or Helios reference document make the project port map installation-ready?
No. Identify the applicable supplied system or OEM implementation, source issues, connection and component basis, defined work boundary and actual release decision. Preserve unresolved mismatches; a reference description or matching platform name does not approve a project package.
Primary sources
- [A2] Autodesk Docs: review and approve filesChecked 2026-10-14. Example of a document review workflow, version and status record. It does not prove Leviathan software capability or establish project release authority.
- [L2] Leviathan physical planning and CAD scopeChecked 2026-10-14. Layouts, routing coordination, cable schedules and material documentation. Resources, reviewer and supported deliverable formats must be confirmed per engagement.
- [N5] NASA Systems Engineering Handbook, section 6.5: Configuration ManagementChecked 2026-10-19. General identification, baseline-change and current/historical status principles only. The original cable-schedule fields, link examples and release records are not a NASA-prescribed format, a cabling standard or project/engineering authority. No company endorsement or technical method is implied.
- [X1] Autodesk AutoCAD 2026: About Attaching and Detaching Referenced Drawings (Xrefs)Checked 2026-10-19. AutoCAD-specific DWG reference/link and opened/reloaded reference-update behavior, with nested reference relationships. It supports the dependency-identification rationale, not universal CAD behavior, a command sequence, engineering/release authority or Leviathan software/resource capability. The documentary fields and EX-XR07 are original.
- [X2] Autodesk AutoCAD for Mac 2026: Package Drawing Dialog BoxChecked 2026-10-19. A specific Autodesk packaging feature lists drawings/dependencies and permits package contents/notes to be configured. It does not establish file completeness in an actual delivery, project approval, construction authorization, universal model requirements or company software access. No software operating steps are reproduced.
- [R9] NVIDIA DGX Vera Rubin NVL72 User GuideChecked 2026-10-19. Named rack-scale system/document hierarchy only. No port map, generation substitution, product count, method, safety, performance or actual OEM/project approval transferred.
- [H9] AMD Helios: reference design and OEM/ODM implementation FAQChecked 2026-10-19. Reference-design versus supplied OEM/ODM implementation distinction only. No availability, partner affiliation, component quantities, interface mapping, field method or actual customer design approval.