GPU cable bundles lose their installation sequence

Examples are fictional local conventions. Unless another location is shown, the scope is DC01 / H1. Keep that scope with shortened identifiers.

When to use

Use this guide when GPU cable groups, labels, and sequence become mixed. Staging records support the deployment plan and equipment instructions.

NVIDIA's DGX SuperPOD staging guide uses source, destination, cable type and length, and a bundling sequence number to organize preparation. Apply its equipment-specific instructions to the relevant deployment. NVIDIA cable staging

What to gather

Collect the released deployment manifest, cable inventory, package references, approved endpoint names, printed label pairs, bundle sequence, and the staging handoff owner.

Method

1. Identify the manifest revision that governs the work package. Set aside superseded printouts and record the number of cable rows expected for each bundle.
2. Match each selected cable's documented type and length to its manifest row. Record substitutions as exceptions requiring the deployment owner's decision rather than changing the row to fit available stock.
3. Keep the cable ID, its two labels, and its kit reference together during review. Check the endpoint text against the manifest and account for unused or reprinted labels.
4. Reconcile each bundle independently. Compare expected rows, prepared kits, and label pairs; list missing, duplicated, or out-of-sequence items before the bundle is released.
5. Record the handoff state and receiving owner. If the manifest changes, identify the affected kits and recheck them before carrying forward a previous review result.

Identify whether the problem is revision, identity, or sequence

Start with the released manifest governing the bundle. A set of correctly printed labels can still belong to an obsolete plan. Confirm the actual revision and its release status before comparing cable counts or kit order. A recent print date does not by itself establish that the underlying manifest is current.

If the revision agrees but cable IDs are missing or repeated, investigate identity reconciliation. If every cable ID appears once but the kits are arranged differently from the released staging order, investigate sequence. If the kits and sequence agree but source or destination text differs, hold the affected rows for endpoint review. These causes should not be collapsed into a general “bundle mismatch.”

Keep staging sequence distinct from physical port numbering and cable identity. A sequence value tells the team where an item belongs in this work package under its plan. It does not independently define which NIC, switch, or port should be connected, nor does resequencing automatically authorize issuing a new cable ID.

Record the stage of work actually being reviewed: preparation, label pairing, staged handoff, or installed-record reconciliation. A successful staging check does not establish that the installation is complete or technically accepted.

Establish one reviewable source of preparation data

Identify the manifest owner and the version released to the staging station. Keep its revision visible on the work pack or kit cover according to local practice. Record which source file generated the labels and which file the reviewer used. Two documents with similar names can contain different endpoint assignments.

For each row, retain the cable ID, complete source, complete destination, required documented type and length, bundle, and staging sequence. Use the actual deployment design and equipment instructions for those values. The fictional examples in this library demonstrate record relationships, not a prescribed GPU-network topology.

Separate proposed substitutions from released requirements. If available stock differs from the manifest, record the proposed item and the reason for review without editing the requirement to match what happens to be on the shelf. The deployment owner must decide whether the change is acceptable and which records or labels it affects.

Define the boundary of a bundle in the staging record. A reviewer should know exactly which manifest rows are expected in the group and which rows belong to another group. Avoid an informal physical pile whose contents change while the review is in progress.

Keep the cable, its two labels, and its kit reference together

Assign or retain the kit reference used by the local work process and link it to one manifest row. The kit reference organizes preparation; the cable ID identifies the cable under the site's policy. Record both so a resequenced or repackaged item remains connected to its identity.

Compare each label face with the row's source and destination under the approved label convention. A two-label pair may reverse LOCAL and REMOTE text or use fixed endpoint names; the chosen semantics need to be explicit. Do not assume that the label with the lower sequence number belongs at a particular physical end.

Account for unused, damaged, and reprinted labels. Record which pair is active for the kit and how superseded loose labels are removed from circulation under the team's process. A correct new pair does not eliminate the risk of an old pair still traveling in the same pack.

If the cable cannot be positively associated with its kit and row, hold that kit. Similar appearance, type, or length does not establish that it is the intended identity. Resolve the association through the approved preparation and inventory records before releasing it.

Reconcile identities before relying on totals

Compare the expected manifest rows with the prepared kit identities in both directions. Every expected row needs an appropriate prepared or exception state, and every prepared kit needs a current manifest row. A total count can agree even when one row is duplicated and another is missing.

Then compare the label pairs against the kits. Record both the number of pairs and their identities. Four loose labels are not necessarily two correct pairs. Check that the shared cable ID and endpoint text belong to the same released row for each kit.

Review sequence separately after identity reconciliation. Identify gaps, duplicates, and intentional resequencing under the manifest owner's decision. If the order changes without changing endpoints or cable identities, record that distinction so the team does not unnecessarily reissue the physical IDs.

Use a clear exception list for incomplete groups. Name the missing or held kit, cause, decision owner, and condition for release. A bundle can be partly prepared without being represented as fully reviewed.

Manage manifest changes as a scoped recheck

When a new revision is released, identify the rows that changed and the fields affected. A source, destination, type, length, identity, or sequence change can have different consequences for the prepared kits. Preserve the revision comparison so the staging team can see why a previously reviewed item requires another check.

For an endpoint change, compare both label faces with the revised row. The label at the unchanged physical end may still describe the former remote endpoint. For a sequence-only change, confirm whether the existing pair remains correct and update the kit-order reference under the released plan. Do not assume every revision requires the same rework.

Mark earlier review outcomes as applying to their original revision. Keep them in history rather than treating them as acceptance of the new version. The receiving owner needs to know which revision the handoff actually covers.

Scenario: counts agree but one cable kit is duplicated

In a separate fictional case, bundle B-G10-301 in DC01 / H1 expects three rows under MAN-G10-301 revision 4: CAB-G10-301, CAB-G10-302, and CAB-G10-303. The staging area contains three kits and three apparent label pairs, so a count-only review looks complete.

The row-by-row comparison finds two kits associated with CAB-G10-302 and no kit for CAB-G10-303. The duplicated kit reference came from a copied preparation line. The reviewer records the actual identities and holds the affected group rather than changing the expected manifest to fit the pile.

The staging owner resolves the duplicated association through the preparation records, prepares the missing kit under its correct identity, and accounts for the invalid label pair. The revised reconciliation shows each expected row exactly once with the appropriate two label faces and documented type and length.

A second reviewer repeats the comparison from manifest to kit and from kit back to manifest. They then review the released sequence and record the receiving owner. Closure retains the discrepancy and correction evidence so the matching final counts are supported by individual identity checks. It does not claim that any cables have been installed or that the network has passed technical acceptance.

Scenario: a destination changed after the labels were printed

In another fictional case, kit KIT-G10-301 contains CAB-G10-304. Manifest MAN-G10-302 revision 2 assigned its destination to DC01/H1/R304/SW-G10-301/P07. Revision 3 assigns the destination to DC01/H1/R305/SW-G10-302/P09 while retaining the cable identity and source under the fictional plan.

The reviewer detects the revision mismatch on the kit cover and compares both faces. The old source-end label still points to the former destination. The old destination-end label also belongs to the superseded pair. The kit is held under EX-G10-301 while the current row is confirmed.

The print owner prepares the revised pair from revision 3 and records the disposition of the old labels. The staging reviewer checks the complete source and destination, shared cable ID, and required documented type and length against the current row. The kit cover and handoff record now name revision 3.

If either obsolete label had already been applied in an operational area, the issue would need the applicable field change process. Staging cannot silently declare that installed correction complete. The receiving owner is told exactly which preparation and application outcomes are supported.

Handoff a partial bundle honestly

Record the prepared, missing, held, and released kit identities individually using the site's supported states. Agree with the receiving owner whether a partial physical handoff is permitted and how its boundary is identified. This guide does not decide the deployment's installation sequence or release authority.

Include the exception list with the handoff record so a missing kit is not mistaken for an intentional omission. Identify who owns each pending decision and what evidence will release it. If the receiving team changes the staging arrangement, preserve the relationship back to the released manifest and kit identities.

Record the handoff event, receiving owner, manifest revision, and actual contents. A signature or status without the list of included rows does not establish which part of the bundle was accepted. Keep later additions or substitutions traceable to their own review rather than silently appending them to an earlier completed handoff.

Adapt preparation to existing halls and new deployments

In an existing data hall, distinguish staged new work from installed operational connections. A manifest row may describe a planned change while the current record still correctly describes the existing arrangement. Preserve both states and their event boundary instead of overwriting current endpoints during preparation.

In a new deployment, establish the manifest-to-kit-to-label relationship before preparing the full batch. Review representative similar-looking kits and revision-change cases so the team can demonstrate how it prevents mix-ups. Include receiving operations in the handoff design because it must interpret the kit identity after the staging team leaves.

Close with evidence that can be checked after handoff

Retain the released manifest reference, the actual kit list, accepted label-pair comparisons, exception outcomes, and receiving owner. The reviewer should be able to start with a cable ID and find the kit and manifest row, or start with a sequence position and identify the intended cable without changing its identity.

Check that all closed rows were reviewed against the revision stated in the handoff. Preserve open decisions visibly rather than burying them in a note below a completed bundle status. A receiving team should not need to reconstruct the review from loose print sheets.

Keep staging acceptance separate from installed identity verification and technical acceptance. Link those later outcomes when they occur under the relevant processes. The completed staging record proves the reviewed preparation relationship and its handoff scope.

Worked example

Fictional bundle B07 contains two cable kits under manifest DEMO-GPU rev 4.

BUNDLE B07 / DEMO-GPU rev 4
SEQ 01 / GPU-0101 / KIT K07-01
  SOURCE      DC01/H1/R014/SW1/P01
  DESTINATION DC01/H1/R021/GPU1/NIC1
SEQ 02 / GPU-0102 / KIT K07-02
  SOURCE      DC01/H1/R014/SW1/P02
  DESTINATION DC01/H1/R021/GPU2/NIC1
Expected rows: 2 | Prepared kits: 2 | Label pairs: 2
Staging example only; not an installation plan.

Kit numbers distinguish manifest rows even when their cables share the same type and length.

Common mistakes

• Mixing label sheets from different manifest revisions.
• Treating matching counts as proof that individual endpoint pairs match.
• Reusing a kit's reviewed status after a destination changes.

Verification

• One manifest revision governs the bundle.
• Every cable row maps to one prepared kit.
• Both label texts match that row's endpoints.
• Counts agree and individual identities were compared.
• Exceptions and the receiving owner are recorded.

Worksheet: GPU cable staging manifest

Fields define one row; sample values are fictional. Leave working-sheet dates blank until their recorded event occurs. Sample status: Example only.

Frequently asked questions

Does sequence mean the order of ports on the switch?

Only when the approved deployment plan defines it that way. Keep physical port identifiers separate from a staging sequence.

What if the bundle is only partly ready?

Record the prepared and missing kit identities individually. Use a clear partial or held state in the real workflow instead of presenting the whole bundle as complete.

Can matching cable type and length identify the right kit?

Use them as required row checks, but also reconcile the cable ID, kit reference, and endpoint pair. Several kits can legitimately share type and length. Similar appearance does not establish their identity or sequence.

What if a new manifest revision changes only sequence?

Compare the actual changed fields with the owner. The existing cable identities and label pairs may remain correct, while kit-order records require updating. Record the decision and new sequence without silently issuing new physical IDs.

Does a staged bundle marked complete mean it is ready to connect?

The staging result covers the reviewed manifest, kit, and label relationships. Installation release and technical requirements remain governed by the deployment's approved plan and responsible owners. State the handoff scope so preparation status cannot be mistaken for completed installation.

More worked label examples

Two additional ways to apply this guide. Keep the exact identifiers and relationships consistent with your own approved records.

SCOPE: DC01 / H1; manifest MAN-G10-101 r4
BUNDLE FACE: [KIT-G10-101 | MAN-G10-101 r4]

SEQ  CABLE        SOURCE                 DESTINATION
01   CBL-G10-101  GPU-G10-101 / NIC1-P1   SW-G10-101 / P01
02   CBL-G10-102  GPU-G10-101 / NIC2-P1   SW-G10-102 / P01

PAIR FOR SEQUENCE 01
[CBL-G10-101 | LOCAL GPU-G10-101/NIC1-P1]
[CBL-G10-101 | LOCAL SW-G10-101/P01]
PAIR FOR SEQUENCE 02
[CBL-G10-102 | LOCAL GPU-G10-101/NIC2-P1]
[CBL-G10-102 | LOCAL SW-G10-102/P01]

Kit count: 2 cables; 4 end labels; 2 manifest rows
Type/length: checked per row against MAN-G10-101 r4

SCOPE: DC01 / H1; kit KIT-G10-201; sequence 07
CABLE: CBL-G10-201

OLD MANIFEST MAN-G10-201 r2
GPU-G10-201 / NIC1-P2 -> SW-G10-201 / P07
OLD DESTINATION FACE: [CBL-G10-201 | TO SW-G10-201/P07]

CURRENT MANIFEST MAN-G10-201 r3
GPU-G10-201 / NIC1-P2 -> SW-G10-202 / P09
NEW SOURCE-END FACE: [CBL-G10-201 | TO SW-G10-202/P09]
NEW DEST-END FACE:   [CBL-G10-201 | TO GPU-G10-201/NIC1-P2]

HOLD: old pair detected; destination does not match r3
RELEASE EXAMPLE: old labels voided 2; new labels checked 2
Kit row + two faces + type/length all reconciled to r3

Sources and applicability

• NVIDIA: Cable staging ↗

  DGX SuperPOD staging guidance, updated November 19, 2025; this worksheet covers identity reconciliation only. The expanded triage, decision comparisons, scenarios, and closeout procedures are original editorial guidance.

  Read scope and linked guides

Related guides