Neocloud Due Diligence: Data Room Red Flags for GPU Loans

Executive Summary

Neocloud due diligence should establish which technical assertions support a credit decision at a defined evidence cut-off. A complete folder cannot establish that ordered graphics processing units (GPUs) are installed, tested, available to the named customer, and eligible for billing. The useful deliverable is a cross-document reconciliation workbook: each assertion joins identifiable equipment and dated evidence to an explicit conclusion. NVIDIA cautions that GPU enumeration can change between reboots; Dell distinguishes original configuration from current configuration. Those boundaries make a server count or screenshot an inadequate substitute for an asset-level reconciliation. ^{[1] [2]}

Power and tests require the same discipline. Dominion Energy describes staged delivery of data-center electric service, while ERCOT requires approval before energization of a new Large Load. Neither public process establishes a particular site's available power. NVIDIA's Data Center GPU Manager (DCGM) diagnostics assess readiness within documented limits, and Kubernetes exposes schedulable GPU resources rather than a measurement of customer activity. The reviewer must join site authority, installed configuration, raw test results, and contractual delivery conditions without treating these records as interchangeable. ^{[3] [4] [5] [6]}

Illustrative arithmetic, entirely fictional: a funded schedule contains 128 GPUs, an installed inventory supports 120, eligible test records cover 112, and customer acceptance supports 104. The resulting 24 GPUs outside the supported acceptance boundary are not automatically failed hardware. They comprise missing installation, missing eligible test evidence, and missing customer allocation and acceptance. This report supplies the assumptions and subtraction behind that bridge. It recommends hold, review, and cleared states with reasons, rather than a completeness percentage or universal risk score.

The financial boundary matters equally. CoreWeave's filing for the quarter ended June 30, 2026 describes committed contracts starting on a fixed date or delivery of specified capacity; that is a company-specific example, not every borrower's contract. The National Institute of Standards and Technology (NIST) evidence-preservation guidance provides an adaptable basis for provenance, and the World Bank's wind-project specimen illustrates review of consistency among contracts. Neither is a GPU lending standard. The committee should receive the conflicting assertion, affected capacity or date, missing cure artifact, accountable reviewer, and reproducible retest. Public research cannot establish the contents or truth of a private borrower's data room. ^{[7] [8] [9]}

Introduction and Background

A neocloud is used here as a working category for an operator supplying GPU computing services. The credit question is narrower than whether its equipment is attractive: which financed resources can support which contractual obligations, at which site and date? A purchase order, a scheduler export, a test report, and a customer invoice describe different events. Kubernetes documentation, for example, describes GPUs exposed as custom schedulable resources after installation of a device plugin. It does not describe a revenue-recognition event. ^[6]

This report proposes a forensic method for GPU loan due diligence. For GPU financing technical due diligence, a red flag means an unsupported assertion material to the decision. “Forensic” means preserving sources and reproducing joins; it does not imply wrongdoing. NIST's digital-evidence publication discusses documenting original sources and preserving hashes. Those practices can inform a diligence register, although that publication addresses evidence handling rather than a mandatory borrower compliance regime. An unexplained discrepancy warrants examination of versions, scope, and timing before a reviewer infers an equipment or delivery problem. ^[8]

The intended readers are private-credit analysts, infrastructure investors, lender counsel, and independent engineers. GPU Smith's position here is that of an adjacent independent engineering advisor. This report complements a broad investor checklist with an assertion-by-assertion method; it makes no claim about any actual operator's private documents. A useful cross-sector analogy is the World Bank's wind-project terms of reference, which separates pre-close technical review from subsequent construction, testing, and operational monitoring. Its project assumptions are not GPU requirements. ^[9]

Research was accessed on October 15, 2026, Coordinated Universal Time (UTC). Vendor documents explain available identifiers, measurement semantics, and configuration boundaries; utility documents explain their own processes; filings and service agreements illustrate their own contractual language. Each supports a reason to request evidence, not a conclusion about an undisclosed borrower. CoreWeave's description of capacity-dependent contract commencement is one such bounded example. Every fictional discrepancy below is explicitly illustrative, with no connection to a GPU Smith client or transaction. ^[7]

Key Changes: Replace Folder Checks with Supported Assertions

Establish provenance before resolving discrepancies

Begin with an evidence manifest. Record the original filename, file digest, source organization, export operator, acquisition method, source-system version, capture time, covered interval, and reviewer. Retain original exports and document subsequent transformations. NIST discusses both original-source documentation and separately retained hashes. A matching digest establishes that the compared file contents match a recorded digest; it does not independently prove the equipment or event represented in that file. ^[8]

Use a claim ID that survives document revisions. A replacement spreadsheet should create a new evidence version attached to the same issue, rather than erase the conflict. The workbook should preserve the original assertion, differing observation, submitter's explanation, and reviewer's disposition. This is a proposed workflow, not a prescribed industry standard. It makes a benign version correction visible without silently rewriting the review history.

Time needs independent treatment. Record event time, export time, and receipt time separately, retaining the original time-zone offset. Request for Comments (RFC) 3339 defines numeric offsets relative to Coordinated Universal Time (UTC); an offset-bearing timestamp can be normalized for comparison. Correct formatting alone does not establish clock accuracy. RFC 8633 advises operators to monitor their time sources, supporting a request for synchronization status alongside timestamped evidence. ^{[10] [11]}

Recommended intake fields are:

• Source identity: originating system, organization, operator, and access method.
• Original artifact: native export plus a digest and preserved original.
• Time boundary: event interval, export time, receipt time, and zone.
• Scope boundary: site, room, rack, server, device, customer, and exclusions.
• Version history: configuration revision and transformations used for reconciliation.
• Reproduction method: saved query, parser version, filters, and resulting exception list.

These are recommended workbook fields. They adapt evidence-preservation and time-management principles rather than asserting that a particular file format is legally required. ^{[8] [11]}

Bind equipment to stable identities and purchased scope

For GPU collateral verification, the equipment chain should run from funded equipment schedule to purchase order, supplier invoice, original equipment manufacturer (OEM) configuration, receiving record, installed inventory, and topology export. Record the purchased stock keeping unit (SKU) and bill of materials (BOM) at their actual granularity. Dell's support process distinguishes the original configuration obtained using a Service Tag from a scan of current configuration. That distinction illustrates why shipped and installed states should be retained separately. ^[2]

An illustrative GPU index such as “GPU 0” is not an adequate persistent join key. NVIDIA recommends consistent identifiers because enumeration ordering is not guaranteed across reboots. Its documentation also distinguishes board serial numbers from GPU universally unique identifiers (UUIDs), and notes that a board serial can be shared by multiple GPUs. The proposed workbook therefore retains both identifiers with host identity and physical location, rather than assuming either maps unambiguously to an invoice line. ^[1]

Use scoped joins. Join the OEM service identifier to the server record, then device UUID and board serial to the observed GPU, with parent assembly and slot where available. Preserve peripheral component interconnect (PCI) bus identifiers as observations tied to capture time and topology. A changed slot, replaced board, or re-enumerated device needs an explanation and lineage. A public command manual supplies identifier semantics; actual identity still requires transaction-specific records. ^[1]

System boundaries also matter. NVIDIA's DGX B300 reference architecture describes an eight-GPU system. ^[12] It identifies four network fabrics, including distinct compute, storage, and management roles. ^[13] These are boundaries of that reference architecture, not universal specifications for all GPU collateral. An eight-GPU server line item does not establish that the purchased network, storage, and supporting infrastructure match the promised service.

The minimum reconciliation should preserve:

• Commercial identity: schedule line, purchase order, invoice, SKU, quantity, and amendments.
• Physical identity: OEM tag, server serial, board serial, location, and receiving record.
• Observed identity: GPU UUID, host identifier, topology, and capture interval.
• Configuration identity: accelerator, memory, networking, storage, software, and firmware revisions.
• Exceptions: substituted components, replacements, unjoined records, and duplicate keys.
• Legal referral: title, collateral description, filing, priority, and access questions for counsel.

The last category is a referral, not an engineering conclusion. The model Uniform Commercial Code (UCC) reproduced by Cornell includes collateral rights among conditions for an enforceable security interest. Counsel must assess applicable enacted law and actual documents. A successful serial match cannot establish ownership, attachment, perfection, or priority. ^[14]

Power and Capacity: Reconcile Rights, Boundaries, and Dates

Separate a request from an authorized, commissioned service

Neocloud power and capacity verification starts with the site's actual utility and colocation evidence, retaining the boundary behind any “megawatts available” statement. Dominion lists a site plan, load letter, and load-ramp schedule among inputs to its data-center service process and describes staged delivery. ERCOT separately identifies approval required before energization of a new Large Load. These examples support checking status and milestones; their processes should not be imposed on a site in another jurisdiction. ^{[3] [4]}

The proposed capacity bridge joins the contracted service boundary to electrical drawings, meter identifiers, commissioned rack load, and the customer's service boundary. Preserve distinctions between power requested, power contracted, capacity available at a stated date, and load demonstrated under the relevant configuration. The Energy Information Administration (EIA) defines interruptible demand by its availability for curtailment under contract or agreement, so a headline capacity figure should retain its curtailment conditions. ^[15]

Request a site-specific evidence chain:

• Rights: executed service or colocation agreement, amendments, ramp, and conditions.
• Authority: approvals and confirmations applicable to the actual jurisdiction and facility.
• Boundary: meter, room, rack, supporting systems, and allocated customer capacity.
• Commissioning: signed records, observed load, test date, and unresolved dependencies.
• Availability conditions: curtailment, maintenance, reservation, and transfer restrictions.
• Schedule: dependency owner, prerequisite artifact, forecast date, and promised service date.

This is a request structure, not a universal energization procedure. Staged service and jurisdiction-specific approvals explain why a dated statement of present availability should be reconciled to the actual promised delivery milestone. ^{[3] [4]}

Keep electrical and cooling calculations in their own worksheet

Power usage effectiveness (PUE), as described by the Department of Energy (DOE), compares annual facility energy with annual information technology (IT) equipment energy. It is a boundary-specific energy ratio. It should not be relabeled as a measurement of instantaneous rack headroom or treated as proof of a project's contracted power rights. Request the period, meter boundaries, and measured inputs behind any stated PUE. ^[16]

The American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE) distinguishes nameplate rating from actual power draw and describes configuration-specific liquid-cooling flow and pressure requirements. Consequently, a server nameplate or utility capacity letter alone cannot complete a cooling assessment. Preserve the applicable configuration, design conditions, commissioned operating measurements, and reviewer findings. The independent engineer should assess the project's design evidence within the commissioned scope. ^[17]

Use the dedicated GPU-cluster electrical-design worksheet and guidance and GPU power calculator for the power model, then link its version and conclusion into this register. Retain the supplied assumptions instead of rederiving electrical designs in the conflict log. DOE's design guide specifically recommends recording monitoring accuracy, including calibration status; the capacity workbook should reference the relevant meter evidence. ^[18]

Illustrative timeline, fictional dates: customer delivery is promised for October 1, 2026, while the submitted utility schedule lists planned energization for October 12, 2026. The subtraction is 11 calendar days. It is a dependency mismatch, not a universal delay allowance or reliable revised delivery date. Acceptance testing and customer prerequisites may remain outstanding. Clear the issue only with a supported revised sequence and the contract reviewer's treatment of the promised date, not by adding an invented standard buffer.

Acceptance, Utilization, and Revenue: Preserve the Measurement Boundary

Reconcile tests with the commissioned fleet

A dashboard showing a successful diagnostic invocation answers a narrower question than whether the financed cluster met contractual acceptance. NVIDIA describes DCGM Diagnostics as assessing readiness and expressly limits its diagnostic scope. It supports selected entities, configurable parameters, and machine-readable results. Accordingly, preserve the raw result, invoked command, effective configuration, selected devices, software versions, timestamps, and exclusions before attributing a result to the installed fleet. ^[5]

Require the serial-bound diagnostic package to join through observed device identifiers to the installed configuration and applicable acceptance clause. Record whether each outcome is pass, fail, not run, excluded, or unavailable, using the actual tool's result semantics. These are proposed register categories, not a reinterpretation of vendor output. An omitted test is not a failure result; an unexplained omission remains an evidence gap. ^[5]

Distributed performance evidence also needs its execution boundary. NVIDIA Collective Communications Library (NCCL) tests cover collective-operation performance and correctness and rely on the Message Passing Interface (MPI) for multi-process, multi-node operation. A best-node result cannot establish the behavior of an untested distributed topology. Preserve participating hosts, device membership, network path, command, message sizes, duration, correctness output, and environmental conditions so another reviewer can reproduce the submitted result. ^[19]

Configuration is part of the claim. NVIDIA's DGX B300 firmware guide describes a combined archive for system and GPU-tray components while separately identifying a BlueField image outside that bundle. “Firmware updated” therefore needs a component matrix and applicable release, rather than an unqualified assertion that one package covers everything. This is a documented product boundary, not a claim that any particular borrower omitted an update. ^[20]

Use the GPU-cluster acceptance-testing runbook for test execution, and the NVIDIA DSX diligence guide and NVLink Fusion rack diligence guide for their respective architecture questions. This workbook records which configuration each result supports. None of those architecture labels should be treated as a substitute for the actual purchased BOM and acceptance boundary.

Reproduce utilization before using it in a financial model

GPU utilization data verification starts with metric definition, device population, sampling interval, missing observations, and aggregation query. Prometheus distinguishes counters, which can reset, from gauges, which can rise or fall. Its rate function extrapolates to range boundaries. A reviewer should request source series and the exact query, rather than infer the calculation from a chart's axis label. ^{[21] [22]}

Slurm documents a particularly useful counterexample: GPU-memory and GPU-utilization accounting is not provided for Multi-Instance GPU (MIG) devices under the documented limitation. It also describes task-level high-water-mark summaries. An absent metric is not automatically zero activity, and a maximum is not a time-weighted fleet average. Check the actual scheduler, accounting configuration, partition mode, and metric availability before comparing populations. ^[23]

Keep allocated, active, accepted, invoiced, and collected capacity or value in separate fields. Kubernetes resource declarations concern scheduling. CoreWeave's filing illustrates that committed contracts may commence at a fixed date or on delivery of specified capacity. Neither establishes that every allocation is a delivered service, that every busy GPU is billable, or that an invoice has been collected. The borrower's executed documents determine the relevant joins. ^{[6] [7]}

For neocloud revenue verification, request:

• Contract chain: executed agreement, capacity schedule, amendments, and customer identifiers.
• Delivery chain: named service allocation, acceptance evidence, commencement notice, and exclusions.
• Billing chain: invoice lines, credits, service periods, and reconciliation to the ledger.
• Cash chain: receipts and application to receivables, reviewed with the finance team.
• Measurement chain: raw telemetry, scheduler records, definitions, and reproducible queries.
• Accounting referral: performance obligations and recognition policy for the accountant.

CoreWeave defines remaining performance obligations to include billed and unbilled consideration associated with undelivered or partly undelivered obligations. That public example reinforces the need to distinguish contracted backlog, service delivery, accounting revenue, and cash. Its accounting treatment must not be copied onto another operator without the appropriate professional assessment. ^[7]

Implementation Considerations and Process Changes

Use an assertion register with a reproducible cure

A neocloud due diligence checklist supports intake. The proposed register treats neocloud data room red flags as assertions to resolve, making the conflicting assertion the unit of analysis. Assign an issue owner who can obtain the missing artifact and a reviewer qualified to assess it. State the affected capacity, service boundary, or dependency without converting uncertainty into a failure finding. The World Bank's wind specimen provides an adaptable rationale: assess technical adequacy and consistency among contracts, then report to support credit approval. ^[9]

Table 1 is an illustrative workbook, entirely fictional. Every identifier, filename, revision, and date is synthetic. “Hold” refers to the indicated assertion or related credit dependency, not an automatic rejection of the whole borrower.

The index counterexample is intentional. NVIDIA's enumeration warning explains why a changed ordinal can be compatible with unchanged equipment. Clear that issue when stable identifiers and provenance support the explanation; do not carry it forward merely because screenshots differ. Conversely, a plausible explanation for a missing server does not clear the installation assertion until the replacement or installation record is joined. ^[1]

Illustrative join, entirely fictional: funded line FIC-L-016 references server serial FIC-S-016, absent from inventory v3. Separately, installed server FIC-S-015 maps slot A to board serial FIC-B-015-A and synthetic device identifier FIC-U-015-A, but neither that identifier nor an eligible run appears in the test package. Save separate unmatched-record lists: missing installation evidence and missing test coverage require different cures. The FIC-U strings are readable stand-ins, not valid vendor UUIDs.

Apply materiality to the decision, not document volume

A hold is recommended when the unresolved assertion is required for the relevant credit decision, such as supported installation, energization, or customer commencement. Review denotes an explanation awaiting corroboration or a required specialist conclusion. Cleared requires the cure artifact, reproducible reconciliation, and reviewer sign-off. These are proposed workflow definitions; the lender sets its actual approval authority and conditions.

Write materiality as a causal statement: “This missing test package leaves this population outside supported acceptance,” rather than “the folder is mostly complete.” Preserve counterexamples that could resolve the issue, including a revised scope, later installation, changed device numbering, or different time boundary. A properly recorded offset and monitored time source help assess date explanations, but neither independently proves the claimed operating event. ^{[10] [11]}

A practical resolution sequence is:

• Freeze: identify the cut-off, assertion, source versions, and affected scope.
• Reproduce: rerun the join and save unmatched or inconsistent records.
• Classify: distinguish missing evidence, contradicted evidence, and explained differences.
• Route: assign engineering, utility, commercial, accounting, or legal ownership.
• Cure: request the specific original artifact or witnessed observation needed.
• Retest: repeat the reconciliation and record residual limits before sign-off.

The sequence is an analyst proposal. It adapts the distinction between initial technical review and subsequent monitoring illustrated by the World Bank specimen, without importing its wind-project schedule or treating it as a GPU standard. ^[9]

Reconcile support promises with restoration obligations

Support evidence should join the exact equipment and service entitlement to the restoration plan. Dell provides tag-based warranty checks and directs readers to relevant service contracts for entitlement. Lenovo's SR675 V3 documentation qualifies GPU-related service requests within its service-level discussion. The relevant question is what the actual purchased coverage provides at that location, for those components, and during the required period. ^{[24] [25]}

Customer service-level agreements (SLAs) need their own measurement review. Amazon Web Services (AWS) distinguishes regional and instance-level Elastic Compute Cloud (EC2) commitments, defines instance-level unavailability by external connectivity, and specifies supporting records for credit claims. That illustrates why hardware replacement, customer service availability, and claim eligibility require separate evidence. It is not a GPU-cluster acceptance specification or template that overrides the borrower's contract. ^[26]

Join spares by compatible part, location, reservation, access, and replacement procedure. Record the operational plan's assumptions about staff, approvals, shipping, and restoration validation. Treat these as requested project artifacts, not invented vendor commitments. Use the GPU-cloud SLA decoder for contract-measurement analysis, then reference its conclusions in the exception register. The public AWS example demonstrates that the precise measurement and claim boundary matters. ^[26]

Data Analysis and Evidence

An auditable capacity bridge

Table 2 shows illustrative arithmetic, entirely fictional. Assumptions: the funded population consists of 16 servers with 8 GPUs each; every subsequent row is a subset of that same population at the fictional cut-off of October 1, 2026 UTC. Device membership is reconciled individually. All inputs below are invented for explanation, not observations, benchmarks, or deal terms.

The funded-to-accepted difference is 128 − 104 = 24 GPUs: 8 lack installation support, 8 lack eligible test evidence, and 8 lack customer allocation and acceptance evidence. The arithmetic is a reproducible consequence of the stated fictional assumptions. It does not show 24 defective GPUs. Missing tests remain missing tests. The actual bridge must use distinct device sets; a different customer allocation or non-nested test population requires an explicit set reconciliation.

For the same fictional population, the installed-but-not-test-supported difference is 120 − 112 = 8 GPUs. The defensible conclusion is that eligible evidence covers 112 installed GPUs, not that the entire installed population passed. The nominal eight-GPU layout is realistic for the cited DGX B300 reference system, but the example does not assert that every GPU server has that configuration. ^[12]

Recalculate the metric from its definition

An acceptance count is not utilization. For reproducible utilization analysis, retain the selected time window, observed population, missing samples, weighting, and aggregation. Prometheus documents that over-time aggregations give observations equal weight even if timestamps are unevenly spaced. A chart average therefore needs inspection of its query before it can be characterized as a time-weighted measure. ^[22]

Illustrative utilization arithmetic, entirely fictional: two devices are observed for a common 10-hour window. Device A is active for 8 hours and device B for 2 hours under an explicitly chosen binary activity definition. Observed active device-hours are 8 + 2 = 10; observed available device-hours are 2 × 10 = 20; the resulting ratio is 50%. If device B's observations are missing, neither assigning it zero activity nor dropping it silently reproduces that same measurement.

That example defines its own metric. It is not NVIDIA GPU utilization, a workload benchmark, or a billing measure. Slurm's documented MIG accounting limitation is a concrete reason to record unavailable metrics explicitly rather than manufacture activity values. Kubernetes resource allocation likewise does not replace the activity definition or supply a customer invoice. ^{[23] [6]}

Keep power quantities equally explicit. EIA defines energy in kilowatthours by power expended over time; DOE's PUE definition concerns annual energy boundaries; ASHRAE distinguishes equipment rating from operating draw. A monthly energy total, instantaneous load observation, and contractual capacity limit cannot be compared as if they were the same quantity. Record units and periods before drawing a contradiction. ^{[15] [16] [17]}

Implications and Future Directions

Give the credit committee an exception memo it can act on

The exception memo should state the assertion, evidence cut-off, supported population, unresolved difference, materiality rationale, requested artifact, responsible reviewer, and next decision. Attach the reproducible join and preserve its inputs. The World Bank wind specimen explicitly anticipates a technical evaluation report used in lenders' credit approval activities; that reporting concept is adaptable even though its project-specific engineering requirements are not. ^[9]

For each open item, distinguish observed evidence, illustrative arithmetic, assumptions, and hypotheses. An observation identifies a fetched public source or actual supplied artifact. Arithmetic exposes its inputs. An assumption states what the calculation takes as given. A hypothesis is a possible explanation that still needs corroboration. A version-boundary explanation should remain a hypothesis until the reviewer can reproduce it against preserved evidence. ^[8]

A concise memo should carry:

• Decision dependency: the assertion required for the proposed action.
• Supported scope: equipment, site, customer, configuration, and interval.
• Residual uncertainty: what remains missing or inconsistent and why it matters.
• Resolution condition: exact cure artifact, accountable owner, and retest.
• Professional boundary: engineering finding and separate legal or accounting conclusion.
• Monitoring trigger: the change that requires the reconciliation to be refreshed.

As configurations evolve, avoid treating an old acceptance record as evidence of an unreviewed replacement configuration. Refresh affected device, topology, and firmware joins, while preserving the historical record. NVIDIA's component-specific firmware packaging illustrates why that refresh should be scoped to the actual change rather than to a generic statement that software is current. ^[20]

The forthcoming power-access checklist should hold the grid-evidence procedure; the forthcoming node-sanitization matrix should hold the data-handling procedure. This register should reference the applicable versions when available. It should record conclusions and open dependencies without duplicating specialist procedures or claiming that an unperformed review has occurred.

Conclusion

The practical output of neocloud due diligence is a supported technical boundary for a credit decision. Start with the assertion, preserve its sources, join the equipment and configuration, reconcile power and service dates, reproduce acceptance coverage, and separate scheduling, utilization, delivery, billing, and cash. The proposed workbook makes unresolved capacity and timing visible without treating every discrepancy as a failure.

The fictional bridge demonstrates the required discipline: exclusions retain their reasons, missing tests remain distinct from failed tests, and contractual acceptance remains distinct from a diagnostic result. NVIDIA's documented diagnostic scope supports keeping that final distinction explicit. Lender counsel determines the relevant legal conclusions, while the accountant assesses recognition and financial reconciliation; the engineer supplies the technical evidence within scope.

The same discipline should continue after close when configuration or delivery population changes. The World Bank's wind-project specimen provides an analogous separation between initial review and later monitoring, not a prescribed GPU process. A cleared item should retain the artifact and reproducible check that resolved it, so the next reviewer can understand the supported conclusion and its limits. ^[9]

For independent pre-close technical due diligence, use the GPU financing due-diligence page to frame the proposed review around equipment, site, acceptance boundary, and unresolved credit dependencies.

References

All sources below were fetched and read during this research session, accessed October 15, 2026 UTC. Vendor documentation supports vendor-specific facts; public contracts and filings support their own disclosed terms. NIST and the World Bank are cited as adaptable frameworks, not GPU lending standards.

• Asset identifiers: NVIDIA System Management Interface. ^[1]
• DGX B300 boundaries: components and network fabrics. ^{[12] [13]}
• Shipped and current configuration: Dell. ^[2]
• Support verification: Dell. ^[24]
• GPU-specific service qualifications: Lenovo. ^[25]
• Firmware packaging: NVIDIA DGX B300. ^[20]
• Diagnostic scope: NVIDIA DCGM. ^[5]
• Prometheus metric and aggregation semantics. ^{[21] [22]}
• GPU accounting limitations: Slurm. ^[23]
• Distributed test scope: NVIDIA NCCL tests. ^[19]
• Allocation semantics: Kubernetes. ^[6]
• Utility staging: Dominion Energy. ^[3]
• Energization: ERCOT Large Load integration. ^[4]
• PUE boundary: DOE. ^[16]
• Meter accuracy: DOE data-center design guide. ^[18]
• Thermal and power boundaries: ASHRAE. ^[17]
• Energy and curtailment definitions: EIA. ^[15]
• Evidence preservation: NIST IR 8387. ^[8]
• Timestamp offsets: RFC 3339. ^[10]
• Time-source monitoring: RFC 8633. ^[11]
• Reporting analogy: World Bank wind-project specimen. ^[9]
• Contract and accounting example: CoreWeave quarterly filing. ^[7]
• Service-level measurement example: AWS Compute SLA. ^[26]
• Legal boundary: Cornell reproduction of model UCC Section 9-203. ^[14]