Operator and tenant handoff · 8 September 2026

GB300 acceptance evidence

A GB300 handoff needs a named owner, an applicable requirement and inspectable evidence. Use this worked example to separate a proposed test, its recorded result and the decision to accept it.

Who owes which evidence?

For GB300 NVL72 managed Kubernetes, the NCP operates the substrate and the ISP operates its inference stack. NVIDIA’s normative tables distinguish MUST, SHOULD and INFO. Keep those levels with the source ID; a recommended test is not automatically a mandatory gate.

Selected rows below are condensed from NVIDIA’s GB300 inference-provider requirements, checked 8 September 2026. The evidence column is our proposed review material, not a claim of a completed test.

Selected obligations and proposed handoff evidence
Source ID / level	Operator → tenant	Evidence to request
HW-1 / SHOULD	Owns benchmarks → consumes evidence	Versioned NCCL results, topology and agreed SKU target.
HW-2 / SHOULD	Owns rail tests → consumes evidence	Per-rail results, error counters and outlier review.
HW-5 / SHOULD	Owns 24-hour soak → consumes evidence	Workload, power cap, timed logs and incident record.
HW-7 / MUST	Owns inventory → consumes	Inventory export tied to the delivered nodes.
KUB-1 / MUST	Owns managed control plane → consumes	SLA, upgrade owner and cluster identity.
KUB-23 / MUST	Owns topology labels → consumes	Node labels reconciled to physical inventory.
KUB-25 / SHOULD	Owns substrate → tenant owns placement policy	Allocation request, resulting placement and mismatch test.

Worked example: CNP03 to a reviewable result

CNP03 in NVIDIA Requirements for AI Clouds requires NVLink-domain-aware allocation for NVL72. This is a separate source from the GB300 profile above. Our example below is a proposed acceptance test; it has not been run against a customer cluster.

Proposed CNP03 acceptance record
Step	Record
Requirement	CNP03; source revision and retrieval date; named cluster and allocation service.
Precondition	Two known NVLink domains in an inventory snapshot. Record available capacity and node membership.
Positive test	Request a supported allocation constrained to one domain. Reconcile every returned node against inventory and fabric topology.
Negative test	Request more capacity than one available domain can supply. Check that the service refuses or reports the constraint failure; it must not silently split the allocation.
Evidence	Sanitised request and response, timestamps, inventory snapshot, topology export, tool versions and reviewer decision.
Current result	NOT RUN. No customer endpoint, allocation result or acceptance decision is claimed here.

What an API evidence record could contain

The following is a synthetic evidence envelope, not a Neon endpoint or an NVIDIA API specification. Map these fields to the provider’s documented interface. Keeping requested and observed domains separate makes a violated constraint visible. A successful HTTP status alone cannot establish correct allocation.

Synthetic example: illustrative fields; no test executed

{
  "example": true,
  "requirement": "CNP03",
  "status": "NOT_RUN",
  "requested": {
    "nvlinkDomain": "domain-a",
    "nodeCount": 2
  },
  "observed": null,
  "evidence": {
    "request": null,
    "response": null,
    "inventorySnapshot": null,
    "topologyExport": null
  },
  "reviewerDecision": "pending"
}

After running the test, retain the raw evidence in controlled storage. Put stable evidence references and integrity hashes in the review record. Remove credentials and tenant data from shared copies. A reviewer should be able to reproduce the decision without receiving a live access token.

The NVIDIA AI Cloud validation tools can help with applicable functional checks. The repository describes an experimental preview. Pin its commit and selected tests; a green run is scoped evidence, not NVIDIA certification.

Keep the readiness clock separate

The broader AI-cloud readiness requirements place API readiness and transport at T-12 weeks, and ancillary CPU, integrated high-performance storage and data movement at T-8. These are NVIDIA’s offtake-readiness milestones ahead of GPU delivery. Agree that delivery date and the applicable source revision before assigning calendar dates.

Those operational milestones do not describe Neon’s ten-working-day Bid Pack. That is an architecture-package delivery commitment; it is not a promise to install and accept a production cluster in ten days.

What still needs real deployment evidence

A design can specify tenant boundaries and key ownership. Acceptance must also test the deployed boundary: permitted and denied cross-tenant access, control-plane separation, key rotation and erasure, and the scope and freshness of any attestation. Agree who witnesses these tests and what closes a failure. Neither a screenshot nor a proposed test is a passing result.

For what the architecture compiler’s GUI run actually demonstrated, read Neon’s ten customer answers.

Before assigning a benchmark lot or reconciling ports, pin the basis using scalable units and fabric evidence.

Record your current evidence gaps in the NCP requirements self audit.

The brief

How Neon fits your AI factory delivery pipeline

Nine pages for the people who sign: where Neon sits in an enterprise AI factory delivery pipeline, what it owns, what it never touches, and the three questions executives ask. Sent as a PDF.

The Neon briefings explain the design and delivery choices behind the package.

Email me the brief