Cable Schedule vs BOM: Reconcile Links, Parts and Quantities

Give each document one clear job

Use the cable schedule to locate a connection: source, destination, intermediate positions where relevant, route and approved assembly/component references. Use the BOM to consolidate the approved material requirement by part and quantity. Use a separate inventory or allocation record to show what the customer actually has available for the workfront.

A spreadsheet can contain all three views, but the fields should retain their meaning. A quantity marked four is ambiguous until the reader knows whether it means four logical links, four integrated assemblies, four patch cords or four items already received.

Work through a small reconciliation

Consider a hypothetical design with three direct links. Links L-01 and L-02 each use one approved assembly identified as PART-A; L-03 uses one PART-B assembly with a different approved length option. The BOM requirement is two PART-A and one PART-B. If the customer has only one PART-A available, the shortage is one PART-A; the total of three logical links has not changed.

The example assumes direct assemblies only. A channel containing separate modules, patch cords, trunks or cassettes needs an explicit component chain. A breakout assembly must be counted once as a supplied assembly even when several branch rows appear in the endpoint schedule. The design owner must define that relationship.

Define the point-to-point record before adding quantities

A point-to-point cable record should let a reader identify one intended connection, locate both ends and recover the inputs behind it. Give the connection a stable link ID within a named project or site namespace. Keep that identity separate from a cable assembly part number, spreadsheet row number, label text or test-file name. Those references can describe the same work, but they answer different questions. A sort or export must not create a new connection merely because its row number changes.

Define A and B as administrative end names in the field dictionary. They do not by themselves establish signal direction, device role, physical cage identity or a breakout-lane map. Locate each endpoint at the level the approved input actually defines: site/room, cabinet, equipment or panel, and port/termination identifier. Where a chassis has both physical and logical port names, retain the applicable mapping reference instead of silently treating the names as interchangeable. An unknown port stays an owned open input.

The field set below is a practical documentation proposal, not a universal standard. NASA’s configuration-management guidance supports identifiable records and traceable source history; it does not prescribe these cable fields, validate an endpoint or release field work. Agree the actual naming, evidence and review rules with the project owners.

References: [N5]

Generate rows from the issued connection inputs

Treat schedule generation as a traceable translation of identified inputs, not an opportunity to complete the network design. A port map can identify an equipment port without saying which remote port it should connect to. The approved connection requirement supplies that relationship. Identify both records, their applicable issues and the owner who resolves a missing or conflicting relationship before treating a generated schedule as complete.

Agree a field mapping from those inputs into the schedule. A useful mapping states the source field, its meaning, the output field and the rule for an unmatched or ambiguous value. For example, a connection requirement’s endpoint-record key can join to an equipment-and-termination record in a port map. Copying two similarly named columns is insufficient if one contains a physical termination identifier and the other contains a logical interface or local alias. Keep the applicable mapping reference where the input uses more than one naming view; do not derive a cage, lane, port partner or direction from an assumed naming convention.

The steps below describe document handling, not a software command sequence or physical installation method. They are an original practical workflow. The existing NASA configuration-management reference supports identifying inputs and maintaining attributable configuration history; it does not prescribe this field mapping, validate a port or approve the resulting schedule.

References: [N5]

• →Identify the input set and expected connection population. Record the connection-requirement and endpoint/port-map identifiers, revisions, applicable equipment/workfront and intended use. State which record defines the connections to include; do not create partner connections merely because two ports are listed near one another.
• →Map connection identity and each endpoint separately. Retain the source connection key as the stable relationship to the generated row. Resolve each A/B endpoint key against its identified port-map record and retain the located equipment/termination values and source reference. A/B are the agreed administrative end names, not inferred traffic direction.
• →Carry approved component relationships without redesigning them. Preserve the assembly or component-chain reference supplied by the governing input. If that relationship is absent or inconsistent, return it to its owner; do not infer one supplied cable per row or generate a new part selection from the port count.
• →Keep unmatched or ambiguous results visible. A missing lookup, duplicate source key or conflicting applicable issue produces an identified open item linked to the affected connection. Retain the original values and ask the responsible owner for a disposition. Do not silently drop a row, choose the first match or replace a physical identifier with a convenient alias.
• →Check the generated view back to the defined input population. Account for every in-scope source connection as a generated row, an explicitly documented exclusion or an open item. Review the row-to-input references and the agreed field meanings, not only matching totals. Hand over the output issue, input-set references, mapping notes and unresolved items for the nominated reviewer and intended use.

Follow source connections into a draft schedule

Fictional example EX-GEN05 has three in-scope connection requirements, CON-51–CON-53, in CR-05/R1. Each requirement names A/B endpoint-record keys and an assembly reference. The separately issued port map PM-05/R2 resolves five of the six endpoint keys. Both source issues are identified in the example; their existence or approval labels do not make them a consistent complete input set. The absent E-B3 record remains an owner-held input.

The generated draft CS-05/D0 preserves the three connection keys. It carries two complete documentary endpoint pairs and one unresolved B-end lookup. It does not invent a sixth port-map entry or remove CON-53 to produce a clean-looking two-row output. All identifiers, locations and source relationships below are invented for explaining document translation, not actual products, topology, compatibility, site conditions or a recommended connection design.

• →The review return identifies CS-05/D0, CR-05/R1 and PM-05/R2, the agreed field mapping, CON-53/Q-G03 and the owner response required. It does not label the whole schedule released for installation merely because all three rows are present.
• →If the owner supplies the missing record or changes a requirement, retain the response and its applicability, then reconcile the affected generated row through the existing controlled-issue process. The later schedule should still be traceable to the exact inputs it used; do not rewrite the earlier incomplete draft as though it always contained the answer.

Compare three point records with their evidence

Fictional example EX-POINT-04 contains three intended direct connections in schedule CS-EX / R3. For this example only, each link references one individual assembly; the approved input identifies PART-A for two links and PART-B for one. That gives three link records and a material requirement of two A assemblies and one B assembly. This assumption must not be carried into a channel or breakout design with a different component relationship.

The endpoint notation in the table means cabinet/equipment/port, under one fictional site and room namespace. The evidence entries are invented observations for explaining a comparison, not actual inspections or a recommended way to access equipment. EX-L403 deliberately lacks an approved B-end port. Its material reference can exist while the connection definition remains incomplete. No row in this example has a test or customer-acceptance result.

Only EX-L401 has a recorded endpoint pair that agrees with the stated planned pair. EX-L402 has an observed disagreement, and EX-L403 has both a missing design input and no observation. None of those documentary outcomes proves connectivity, performance, compatibility or permission to energize or change a connection. The point of retaining the separate fields is to expose the next decision without turning a populated schedule into a completed-work claim.

Hand over a record with a defined state

Review the dataset in layers. First establish which work package and revision it describes. Then check stable IDs, endpoint-field meanings, component references and retrievable input files. Compare intended values with the separately recorded physical evidence, retaining unresolved values and discrepancies. Finally state who may decide each issue and what evidence the receiving owner needs. This is a documentary review sequence; it supplies no instruction to disconnect, inspect internally, alter or test equipment.

A duplicate link ID is not resolved by deleting whichever row appears second. Compare the two rows and their source history to determine whether they are repeated exports, conflicting revisions or two genuinely different intended connections that were given the same ID. Keep any resolution attributable. Likewise, two rows using the same endpoint are a review question for the defined design; the spreadsheet alone cannot establish whether they represent an error, an approved sharing arrangement or an unresolved naming problem.

Include the field dictionary, source schedule/drawing revisions, open-item list and required review state in the handoff. A filtered installation view should retain enough identity to join back to the controlled source. Keep evidence files accessible to the permitted recipients without distributing credentials, unrestricted topology or private customer details. Agree actual access and retention with the project; a schedule export is neither a purchasing instruction nor a blanket installation, testing or customer-acceptance release.

References: [N5]

Preserve the attributes that change the part

Retain the full approved identifier, connector ends, length option, unit of issue and any applicable configuration reference. Do not collapse two different length options into one generic cable line if the installation requires separate parts. A kit and an individual component also need distinguishable units to avoid counting the same contents twice.

Record which design revision generated the BOM. If a route or endpoint changes, identify the affected link rows and recalculate the material requirement from the revised component relationship. Keep the prior approved revision available rather than editing an old quantity without explanation.

Reconcile delivery without assuming the box contains everything

Check the supplied equipment documentation and actual order records before treating accessories as included. NVIDIA’s DGX B200 guide states that supported networking cables are not shipped with that system. This is a model-specific example of why the purchased server and the project’s complete cable requirement are different lists.

A receiving count establishes what arrived under the authorized receiving process. It does not establish compatibility or allocation to a particular link. Mark substitutions and shortages for the responsible owner; do not replace the approved part with a similar-looking item merely to make the quantity balance.

References: [N4]

Issue a material requirement with a stated purpose

A useful BOM tells its next reader what the listed quantities represent and which decisions remain open. State the work package, document identifier, revision, issue date, intended use and nominated reviewer. Identify the drawings, equipment configuration and other approved inputs behind the requirement. A list prepared for quantity review should not silently acquire an installation-release or purchasing status when someone forwards it.

For each line, retain a stable line identifier, exact approved part or clearly unresolved description, unit of issue, required quantity, quantity basis and decision reference. Keep a proposed alternate separate from the current requirement until the nominated owner accepts the change. Where a part identifier, included content or quantity is unknown, record the missing input and its owner. A blank field or zero can otherwise conceal a requirement that has never been resolved.

NASA’s configuration-management guidance describes unique identification, controlled baselines and recorded change status. Those general document-control principles support this approach; NASA does not prescribe this BOM format or approve a data-center installation. Agree the actual issue and review process for the project.

References: [N5]

Work through a material issue without an order

Fictional example EX-BOM-18 concerns four equipment positions and six direct cable links. Its internal reference, revision R1, defines one fictitious KIT-RAIL-A per position and explicitly says that each kit contains two rail members. It also identifies four approved PART-A assemblies and two approved PART-B assemblies. These invented identifiers do not describe an OEM kit, an actual rack design or compatible products.

The material requirement is four kits, four PART-A assemblies and two PART-B assemblies. Eight rail members explain the contents of the four kits; they are not eight additional items to add to the requirement. Retain that included-content relationship so the receiving and purchasing owners can compare their own records using the same unit. Do not combine the mixed units into a grand total called cables or parts.

The fourth line below deliberately remains unresolved. The package can expose that gap for review while retaining the three identified lines. It cannot honestly claim that every material requirement is complete. Nor does identifying a requirement establish the supplier, stock, quotation, order quantity, price, delivery commitment or permission to place an order.

Reissue the requirement and show the line delta

Continue the fictional example with an approved input change, CHG-07. Revision R2 removes position M04 and changes one of the six direct links from PART-A to PART-B. The input explicitly leaves the other five link requirements unchanged. The revised requirement is therefore three kits, three PART-A assemblies and three PART-B assemblies. The unresolved accessory line remains unresolved unless the change record separately answers it.

The table is a requirement delta. It does not say what was bought, accepted by a supplier, received, reserved, installed or returnable. A decrease of one required kit does not establish an unused kit to return. A new PART-B requirement does not establish an order to place. Give the appointed purchasing owner the changed line and basis so that owner can compare the requirement with the actual commercial records. Do not net unlike items into a zero change because one assembly was removed and another was added.

Issue R2 with its reviewer/status, source-change reference and the prior revision retained. If a supplier responds with a different part, pack size or kit content, record that proposal against the affected line for the nominated reviewer. Do not edit the approved requirement merely to match the offered quantity. A BOM author can make the requirement and unresolved questions traceable while the customer and appointed supplier separately establish purchasing and supply commitments.

References: [N5][L2]

Agree the material-documentation deliverable

Define whether the engagement requires a point-to-point schedule, grouped material list, reconciliation report or all three. Name the design reviewer and the responsible purchasing, delivery and shortage-resolution owners. Confirm supported file formats and actual production resources before promising a software-specific export.

Leviathan offers bounded physical planning, cable schedules and technical material/BOM documentation. Name the appointed purchasing owner, equipment/material supplier and delivery responsibilities separately from the physical work. A BOM alone is not an order. The useful output is a traceable relationship from an approved link to its required components and the customer’s release decision, not an unexplained total cable count.

References: [L2]

Issue a bid basis alongside the connection schedule

Before requesting installation bids, identify the schedule issue, workfront and connection population to be priced. Give every bidder the same retrievable input set and a visible list of unresolved items. State whether the request concerns new installation, supplied-assembly placement, labeling, records, testing within an agreed scope, removal, or some combination. An endpoint list identifies connections; it does not automatically include every activity needed to deliver them.

For each included connection, provide the two endpoint identities, approved assembly or component relationship, route and length basis where those inputs are available, and the relevant drawing or port-map issue. Distinguish an approved value from an estimating assumption or an unanswered question. Identify the supplied-material owner, receiving and access dependencies, applicable work windows and required handoff evidence separately. State who must answer a missing input and which bid line it affects. Do not invite one bidder to assume a direct assembly while another prices modules and patch cords for the same unnamed optical link.

Include a response field for the bidder’s inclusions, exclusions, assumptions and unresolved questions. Ask for the basis of any quantity that differs from the issued requirement. Where an input is missing, request an explicit conditional treatment or separate unresolved line rather than a fabricated length, part or endpoint. Confirm the actual commercial treatment through the project’s procurement and contract owners; this article provides no quotation, entitlement or binding bid instrument. The existing NASA reference supports keeping identified baselines and changes traceable, not these original bidding fields or a universal installation specification.

References: [N5]

Compare bid scope without changing the connection population

Fictional example EX-BID12 concerns four connection requirements under schedule CS-BID/R2. Two rows identify complete direct assemblies. A third identifies a separable optical channel comprising two modules and one patch cord. The fourth lacks its B-end port and approved route basis. These stipulated documentary relationships are invented; they are not an actual design, compatible product list or installation instruction.

Three of the four requirements have a stated component basis. That gives two complete direct-assembly requirements and a separate channel requirement with two module identities and one cord identity. Keep those units separate. It is misleading to turn the population into five interchangeable cables, and equally misleading to omit the fourth connection because its inputs are unresolved. The schedule has four intended connections, not three completed or accepted links.

Suppose bidder A includes placement and recording of the supplied direct assemblies and patch cord, while treating module installation and the unresolved fourth connection as separate scope questions. Bidder B says four links installed without identifying component scope or the fourth row’s missing inputs. Those responses cannot yet be compared as equivalent packages. Return the specific differences for clarification, preserve both submitted responses and record the accepted comparison basis if one is later supplied. A populated comparison table is neither an agreed price nor authorization to substitute parts, access equipment or perform the work.