Evidence Sufficiency Under Partial Hardware Observability — A Cross-Vendor Empirical Study
Author: Selim Kandaz · Status: Working manuscript / independent research (not peer-reviewed, not published)
Background
Enterprise servers do not expose a single variable called “readiness.” Their state is inferred through partially overlapping sources such as BMC telemetry, firmware inventory, historical logs, operating-system evidence, component health data, and bounded workload behavior. Different sources can disagree, go silent, or become unreachable depending on the system’s physical power and firmware state.
Research question
What evidence is sufficient to justify — or withhold — a specific operational-readiness claim?
The study develops a claim-dependent evidence model and evaluates it using ASUS server case studies, an HPE cross-vendor cohort, controlled state transitions, and retrospective operational evidence.
Core idea
Readiness is treated as a bounded claim justified by evidence, rather than a directly observable hardware property. Evidence sufficiency is claim-dependent — the evidence needed to support “identity verified” is different from the evidence needed to support “bounded workload stability observed.” A claim-dependent model means the question is never just “is this server ready,” but “ready, according to which claim, supported by which evidence, observed through which path.”
Main findings
- No single observation source was sufficient for all readiness claims. BMC telemetry, firmware inventory, and workload evidence each supported different claims and left different gaps.
- Current and historical state are not equivalent. A system’s present sensor reading does not stand in for a record of what it has done over time, and the two shouldn’t be substituted for each other.
- Observability can change with physical operating state. What a management interface can report before power-on differs from what it can report after, sometimes substantially.
- Missing, empty, unavailable, and failed observations are not equivalent. Collapsing them into a single “no data” bucket discards information that matters for deciding what to do next.
- Software verdicts can diverge from independently re-observed physical outcomes. A reported PASS is a claim about what the software checked, not a guarantee about the physical component.
- Evidence collection can legitimately stop before active workload testing. When a required evidence source can’t be reached through an authorized path, stopping is a valid outcome, not a failure of the process.
- Evidence principles transferred across vendor environments even when interfaces did not. The specific fields, error codes, and access paths varied by vendor; the underlying reasoning about what counts as sufficient evidence held up across them.
HPE Phase 2 example
One HPE system could not reach the intended in-band layer through the authorized management path and therefore remained NOT_EVALUATED. A second system exposed substantially stronger memory evidence only after power-on. Its state changed from Warning/Off to Critical/Starting, two DIMM records reported MapOutError, and the IML gained 27 records before workload execution.
The experiment stopped rather than forcing a PASS/FAIL result.
Additional evidence increased confidence in the decision while making the readiness assessment less favorable.
What the study does not claim
This study does not establish:
- Remaining useful life prediction
- Fleet failure rates
- Vendor ranking
- That a short bounded workload constitutes burn-in
- A universal minimum number of tests
- A validated distributed coordination protocol
Research themes
- Hardware observability
- Evidence sufficiency
- State-dependent observation
- Validation automation
- Reuse and refurbishment