How to Write Acceptance Criteria for Reserved B300 GPU Capacity

A procurement team reserves B300 capacity for an upcoming workload. The contract has a delivery date. The hardware arrives on time.

Then the problems start.

The systems still need to be installed. Networking is incomplete. Firmware versions are inconsistent. GPUs are visible to the host but cannot sustain the expected workload. The cluster is technically “delivered,” yet the engineering team cannot use it.

This is an acceptance-criteria problem.

For reserved B300 capacity, procurement should write the contract so the commercial delivery event happens only after a defined technical acceptance event. The objective is simple: turn “we delivered the hardware” into “you can run the capacity you reserved.”

1. Define the acceptance boundary before defining the tests

Start by specifying exactly what procurement is buying.

If the requirement is reserved capacity built around a Supermicro HGX B300 architecture, the acceptance boundary should cover the usable system, not merely the GPU trays or servers.

That normally means defining the relevant compute nodes, B300 GPUs, host configuration, network connectivity, storage dependencies where applicable, management access, firmware and driver stack, and any infrastructure required for the capacity to operate.

This matters because suppliers can otherwise satisfy a narrow hardware-delivery definition while leaving integration work outside the acceptance event.

A useful contract distinction is:

Physical delivery: equipment has arrived at the agreed location.

Technical readiness: the equipment has been installed, configured, connected, and exposed to the customer as specified.

Acceptance: the agreed tests have passed and procurement has formally accepted the capacity.

Only the third should trigger a contractual statement that reserved capacity has been delivered.

If you are sourcing capacity rather than individual components, review how Pacific structures reserved GPU capacity around the capacity requirement rather than treating hardware arrival as the end state.

2. Write acceptance criteria as observable outcomes

Avoid criteria such as “system operational,” “cluster available,” or “GPUs installed.”

They are too easy to interpret differently.

Each acceptance requirement should produce evidence that procurement and engineering can independently verify.

For example, instead of:

Eight B300 GPUs installed.

write a criterion closer to:

All contracted B300 GPUs are visible to the operating environment, report the agreed configuration, and successfully complete the agreed validation workload without hardware errors.

The exact validation workload should be agreed before signing. The principle is more important than any single benchmark.

Procurement should be able to answer three questions for every criterion: what gets tested, what constitutes a pass, and what evidence records the result.

This converts acceptance from an argument between buyer and supplier into a checklist.

3. Test the system, not just the inventory

Hardware identity is only the first layer.

For a Supermicro HGX B300 deployment, acceptance should cover whether the full system behaves as contracted. Depending on the deal, that may include GPU enumeration, node health, network connectivity, driver and firmware compatibility, management-plane access, burn-in or stress testing, and successful execution of an agreed representative workload.

The mistake is making the test too shallow.

A server can boot while a GPU is unhealthy. Every GPU can enumerate while inter-node networking remains unusable. A cluster can complete a ten-minute test and fail repeatedly under sustained load.

The acceptance suite therefore needs enough duration and workload intensity to catch obvious deployment failures before sign-off.

The goal is not to reproduce months of production operation during acceptance. It is to establish that the capacity has crossed from inventory into a usable compute system.

For buyers assembling a broader sourcing strategy, Pacific Intelligent Technologies, Inc. works across reserved capacity and the surrounding infrastructure required to make that capacity usable.

4. Separate acceptance failures from minor punch-list items

Not every imperfection should block acceptance.

Procurement should define which failures are material.

A failed GPU, inaccessible node, broken required network path, or inability to execute the agreed workload should generally be treated differently from a cosmetic labeling issue or a non-critical documentation correction.

This is where a severity framework helps.

Blocking defects prevent acceptance because the contracted capacity cannot be used as intended.

Conditional defects permit acceptance only if the supplier provides an agreed remediation plan and the issue does not reduce required capacity or functionality.

Non-blocking defects enter a punch list and can be resolved after acceptance.

Without this distinction, buyers face two bad outcomes. Either they accept unusable capacity because most of the system works, or they hold up acceptance over issues that have no practical effect.

Write the hierarchy before delivery, while both sides still agree on what matters.

5. Tie the commercial milestone to signed acceptance

The contract should identify who can accept the system and what evidence they receive.

Do not leave acceptance as an informal Slack message between engineers.

The supplier should provide an acceptance package containing the agreed test results and relevant system evidence. The buyer then has a defined review period and either signs acceptance or identifies failed criteria.

This also makes remediation clearer. If a test fails, the supplier fixes the issue and reruns the affected acceptance test. The acceptance date becomes the date the contractual criteria are actually satisfied, not the date the first truck arrived.

This distinction matters particularly when teams are coordinating reserved capacity with an existing compute requirement. If the new environment cannot be accepted immediately, bridge capacity can cover the gap between the required compute date and permanent capacity becoming usable.

Define the acceptance event before you reserve the capacity

Pacific Intelligent Technologies, Inc. can help procurement teams translate a reserved B300 requirement into a capacity brief with explicit delivery and acceptance boundaries.

Book 30 minutes with Harper to review the requirement.

6. Put the acceptance schedule into the procurement timeline

Acceptance testing needs time and named owners.

The procurement plan should specify when the supplier declares readiness, when testing begins, who participates, how failures are recorded, how quickly retesting can occur, and what happens if acceptance extends beyond the contractual target.

This prevents the delivery date from becoming a single ambiguous milestone.

We can think of the sequence as:

hardware arrives → system becomes technically ready → acceptance tests run → defects are remediated → buyer signs acceptance → capacity is delivered.

That sequence gives both parties a much cleaner operating model.

FAQ

What should “delivered” mean for reserved B300 capacity?

It should mean the contracted capacity has satisfied the agreed acceptance criteria and has been formally accepted by the buyer. Hardware arrival alone should be tracked as a separate milestone.

Should procurement specify a particular benchmark?

Only when a benchmark meaningfully represents the requirement. The stronger approach is to agree on a validation suite that proves the required hardware is healthy, connected, correctly configured, and capable of running the intended class of workload.

Should acceptance testing include every component?

It should include every component whose failure would prevent the buyer from using the contracted capacity as intended. The acceptance boundary should be explicit so neither party discovers after delivery that a critical dependency was considered out of scope.

What happens if most of the cluster passes but one node fails?

The contract should already define whether partial acceptance is permitted. For reserved capacity, procurement should be cautious about accepting less capacity than contracted unless the commercial treatment, remediation process, and remaining usable capacity are explicitly defined.

The core rule is straightforward: reserve capacity against an acceptance event, not an arrival event. Physical hardware is an input. Accepted, usable compute is what procurement is actually buying.