How to Document Source-of-Truth Config Baselines After Reserved B300 Award

Consider a procurement team that has awarded reserved Supermicro HGX B300 capacity. Engineering holds a spreadsheet with approved NICs. The integrator has a newer optics list. Procurement’s purchase-order attachment still references the original rack power assumptions. Each document looks legitimate; none establishes which combination governs delivery.

The missing artifact is a source-of-truth configuration baseline—not another inventory spreadsheet. After award, procurement needs a controlled record that makes the agreed configuration identifiable, reproducible, and usable when documents disagree.

1. Define the authoritative record

The source-of-truth (SoT) baseline is the authoritative, versioned record of the configuration agreed for the awarded scope. It identifies frozen SKUs, firmware targets, network and optics roles, installation assumptions, and expressly accepted deviations.

It can be a signed manifest referencing controlled attachments; it does not need to be one enormous file. What matters is that every incorporated attachment has an exact revision or hash, not a link to a perpetually changing folder.

Create the record after award and issue its approved baseline at the contractual freeze gate. Until approvals are complete, label it draft—not the governing baseline.

For scope context, distinguish the awarded reserved GPU capacity requirement from any interim bridge-capacity arrangement. Separate scopes should not silently share a baseline.

2. Assign ownership across three parties

Name people or accountable roles, not merely departments:

• Procurement owns contractual custody: award references, document precedence, approval collection, controlled publication, and linkage to authorized change orders.
• Engineering owns technical correctness: configuration completeness, compatibility assumptions, firmware targets, network roles, and the technical effect of deviations.
• The integrator owns build-record accuracy: the mapping between the approved configuration and its build package, supporting exports, and identification of discrepancies.

Require all three to acknowledge the same revision. An integrator’s export is evidence, not unilateral authority to redefine the award.

Record the custodian, approvers, approval timestamps, and repository location on the baseline cover sheet. Ensure reviewers can retrieve a historical approved revision without asking someone to reconstruct it from email.

3. Document the configuration, not just the parts

Use a compact manifest with these minimum fields:

• Identity and scope: Award/PO reference, baseline ID, revision, freeze date, covered systems or lots, exclusions
• Frozen hardware: Supermicro HGX B300 system configuration, manufacturer part numbers, quantities, approved options, referenced BOM revision
• Firmware targets: BIOS, BMC, NIC and other agreed firmware versions; image identifiers; hash-list reference
• Network and optics: Management, compute-fabric and storage-network roles; port mapping; transceiver and cable SKUs; endpoint and compatibility references
• Installation assumptions: Rack allocation, agreed weight and clearance limits, input-power requirements, feed and connector assumptions, cooling dependencies, cabling schedule
• Accepted deviations: Deviation ID, affected items, rationale, approving parties, acceptance conditions, and expiry or remediation requirement if applicable

Avoid “standard firmware,” “equivalent optics,” or “power per vendor specification.” Those phrases defer the decision rather than document it.

If serials are not assigned at freeze, mark them pending in the referenced schedule. Specify how later assignments attach to the frozen SKU requirements without implying that an unapproved substitution is acceptable.

4. Version the baseline without overwriting history

Give each approved baseline a unique revision ID; use a content hash where useful to identify an exact export or attachment. A hash identifies bytes—it does not establish approval by itself.

After freeze, permit changes to the approved baseline only through authorized change orders. Each resulting revision should identify:

• The superseded baseline and authorizing change-order ID.
• A concise before/after difference list.
• Affected systems, lots, attachments, and deviations.
• Approvers, effective date, and downstream recipients.

Keep superseded versions read-only. Never replace an attachment behind an unchanged identifier.

A proposed contract concept is: “The approved configuration baseline comprises the manifest and specifically identified attachments; modifications become effective only through an authorized change order identifying the replacement revision.” Ask counsel to review proposed contractual language, including document precedence and signing authority.

5. Attach an evidence annex reviewers can navigate

The annex should prove what was approved and make later comparisons possible. Include three core exhibits:

• Baseline export: a dated, readable snapshot of the manifest and incorporated configuration records, with source tool and export timestamp.
• Serial/SKU schedule cross-walk: a mapping from award line items and frozen SKUs to assigned system/component identifiers, with pending assignments clearly distinguished.
• Firmware hash list: component role, target version, image filename or package identifier, digest algorithm, and digest, linked to the baseline revision.

Add approval records and accepted-deviation evidence. Clearly separate approved targets from observed build-state evidence: a captured firmware version does not automatically become the contractual target.

For procurement support from Pacific Intelligent Technologies, Inc., bring the award schedule, integrator BOM, and unresolved document conflicts. Schedule a configuration-baseline discussion before competing files become competing acceptance expectations.

FAQ

Is this the same as configuration freeze?

No. Change-order configuration freeze governs when changes require authorization. The SoT baseline documents exactly what that authorization boundary protects and where the governing record lives.

Does a firmware hash list satisfy the requirement?

No. Firmware baseline hash locking identifies agreed firmware artifacts. The SoT record also covers hardware, network roles, installation assumptions, approvals, and deviations.

Why include serial records if traceability already exists?

Named-SKU serial traceability connects physical units to ordered items. The baseline incorporates a controlled cross-reference so reviewers can connect those units to the approved configuration without duplicating the traceability system.

Should inventory updates automatically revise the baseline?

No. Continuous inventory reconciliation tracks observed inventory and discrepancies. Observations should trigger review where needed—not silently amend the approved configuration. Preserve the distinction between what was agreed and what is currently reported.