Build & Validate
Release hardware with evidence behind the decision.
Leviathan offers hardware burn-in and QA for equipment moving into integration, deployment or refresh. We agree the configuration, checks, resources and acceptance parameters before the run, then organize the evidence around each identified unit and its disposition.
Discuss a ProjectKnow what was checked, on which configuration
A hardware delivery, a successful start and a useful QA record answer different questions. Infrastructure teams need to know which unit was examined, what configuration was present, which checks ran, what was observed and what remains unresolved before releasing it to the next team.
This service is for operators, integrators and enterprise teams preparing new hardware, investigating a suspected issue or qualifying equipment for reuse. The objective is a documented hardware decision against the agreed plan. The report should make the limits of that decision as clear as the result.
A power-on check is not a burn-in result
Power-on check
A bounded confirmation of the agreed basic hardware status. It does not by itself establish sustained-load behavior, reliability or overall system readiness.
Hardware burn-in
A customer/OEM-approved test procedure executed for a defined period under the agreed available test conditions. Record the configuration, observations, results, failures and exceptions against the acceptance criteria.
Full cluster commissioning
Broader software, networking, workload and performance validation. It is not included in the standard hardware burn-in offer.
Build the QA engagement around the equipment
Unit and configuration identification
Reconcile the equipment identifiers and relevant configuration so each observation belongs to a defined unit and test state.
Test-plan definition
Agree the checks, applicable OEM guidance, tools, permissions, test conditions, duration and acceptance parameters for the actual hardware.
Hardware burn-in and QA execution
Carry out the approved sequence using the resources confirmed for the engagement. Record observations and interruptions against the plan revision.
Exception handling and retest
Separate suspected defects, incomplete checks and changed configurations. Agree who decides the next action and when a retest is appropriate.
Evidence and release handoff
Organize the results, open items and disposition for the customer owner releasing equipment into assembly, shipment or deployment.
Agree the decision before selecting the test
State the question
Define whether the work supports initial release, issue investigation or reuse, and identify the customer acceptance owner.
Approve the plan
Confirm the exact equipment, diagnostic access, location, qualified personnel and safe operating provisions before scheduling execution.
Run and record
Keep the unit identity, configuration and plan revision attached to observations, logs, interruptions and authorized changes.
Review the disposition
State the outcome of the agreed checks, unresolved issues and any retest or supplier/customer action needed before release.
Release a test plan before powered testing
Identify the exact equipment and OEM configuration, the customer/OEM-approved procedure, agreed duration, available power and cooling environment, qualified operating personnel and authorized diagnostics or tools. Define which conditions will be recorded, how failures and exceptions will be handled, and who authorizes a retest or accepts the result.
BIOS configuration, firmware management, management-IP configuration, OS imaging, software administration and application commissioning are not standard services. Any specialist configuration needed before testing is a customer-controlled or separately authorized prerequisite. No powered test begins without the agreed site and equipment authorization.
The duration follows the equipment and test requirements; there is no universal 24-, 48- or 72-hour commitment. Burn-in does not guarantee reliability, defect detection, performance or production readiness. The final handoff records what was tested, under which conditions, and what remains unresolved.
Send the hardware list and the acceptance question
Provide the hardware model and configuration, quantities, identifiers where appropriate, condition and intended next use. Explain any suspected fault, prior observation or required customer/OEM acceptance condition. Identify who can authorize configuration changes and who will review the evidence.
Test location, power and cooling provisions, tooling, diagnostic access, licenses, personnel, duration and limits are confirmed for the engagement. There is no universal burn-in recipe for every server or GPU platform. Restricted logs and identifiers should use the agreed project channel.
Match the QA brief to the release decision
Start with the decision the next team needs to make. A new delivery, a reported hardware problem and equipment proposed for reuse can require different evidence even when the model name is the same. Identify that purpose in the brief so the agreed plan addresses the actual equipment and its next use.
New equipment entering a build
Identify the supplied units and configuration, the records already available, the checks requested before integration and the person accepting that evidence. State whether the next handoff is to assembly, deployment or another appointed team. The QA package can then be scoped around that transition instead of treating receipt, a basic start and burn-in as interchangeable milestones.
Equipment with a reported issue
Describe the observation, affected unit, known configuration and the evidence available to the authorized reviewer. Separate a reported symptom from a confirmed diagnosis. Agree the permitted checks, the information the supplier or customer needs, and who decides the next action if the observation is not reproduced or the run is incomplete.
Equipment proposed for reuse
Identify the current known state, relevant prior records, intended next use and any configuration work owned by a separate team. Define the hardware question that must be answered before that next handoff. A previous pass on a different configuration or earlier use does not supply the missing evidence for the newly agreed decision.
Give each unit a traceable disposition
Agree how the report will connect each unit to the plan, observations and customer decision. A batch summary is useful only when the reader can follow an individual unit through completed checks, unresolved items and any later review. These are reporting requirements to settle in the scope, not a substitute for the approved test procedure.
Bind the observation to the actual state
Use the agreed unit identifier, configuration reference, plan revision and execution record to connect each observation to its supporting artifact. Record what information is unavailable instead of merging unmatched logs into a named unit's result. The customer can then see which evidence belongs to the equipment being released.
Keep incomplete work visible
Distinguish a completed check from one not run, interrupted or awaiting review, and record why the distinction matters to the agreed plan. Link the affected requirement to the next decision owner. Do not turn an unfinished check into a pass because another check completed or the rest of the batch passed.
Retain the exception and retest chain
Link any authorized follow-up to the original observation, the disposition that permitted it and the relevant configuration or plan change. Retain both records so the next reviewer can understand what changed. The appointed acceptance owner decides what evidence is sufficient for the agreed release; the service report does not silently expand that decision to warranty coverage or full cluster readiness.
Make the QA record usable at handoff
Agree the report format and required artifacts before execution. A proposed package includes:
Equipment and configuration register
Unit identifier, relevant components, configuration state, plan revision and the reason the equipment entered QA.
Per-unit check record
Agreed check, execution date, method or tool reference, relevant conditions, observations and the location of supporting evidence.
Exception and retest register
An issue description, affected unit, incomplete checks, nominated owner, disposition and any subsequent retest reference.
Release summary
The checks completed, their agreed acceptance outcome, exclusions and unresolved matters that the next team needs to see.
Hardware evidence with an explicit scope
Hardware QA is the primary service. BIOS and firmware changes, IP/network configuration, OS imaging and software or workload commissioning are not standard inclusions; separate requests are assessed for the platform and available resources. A hardware record does not establish application readiness or a guaranteed lifetime without faults.
Liquid-loop installation or testing and facility electrical construction remain excluded. The actual test method, equipment, personnel and acceptance parameters must be confirmed for the engagement; no specific platform benchmark, temperature, runtime or performance result is promised here.
Project questions
Does this include software commissioning?
BIOS, firmware, IP configuration, OS imaging and complete software commissioning are not standard services. The project scope identifies separate system responsibilities and any additional requirements before work begins.
Can one hardware QA engagement cover several models or configurations?
It can be scoped for identified equipment groups, with the applicable plan, prerequisites and acceptance question defined for each. Provide the model/configuration list and quantities, and identify any differences that need the customer's or OEM's review. A shared project does not make one unit's procedure or result applicable to every other unit.
What happens if a check is interrupted or cannot be completed?
The record should identify the affected unit and check, the available observation, the interruption or missing prerequisite and the next decision owner. The agreed plan controls whether work is resumed, repeated or referred for review. An incomplete check remains visible in the release package; it is not reported as a pass.
Can we provide existing supplier logs or earlier test reports?
Yes. Identify their source, unit/configuration reference, date and relevant plan or method so the authorized reviewer can decide how they inform the engagement. Use the agreed project channel for restricted records. Earlier evidence is retained with its limits rather than presented as a new Leviathan test result.
Does a QA report authorize a warranty return or the equipment's next deployment?
The report supplies the agreed hardware observations, results and open items. The appointed customer acceptance owner decides the scoped release, while supplier warranty or return decisions follow the applicable supplier process. Full cluster commissioning and a different site's readiness remain separate responsibilities.
Define the hardware release question
Tell us what hardware you have, why it needs burn-in or QA and what decision the evidence must support. We will follow up to discuss the test scope, requirements and availability.
Discuss a ProjectEmail Project Scope