Structured investigations that grew out of practical engineering work, some finished, some still open questions.
Featured study
When Is a Server Ready?
Evidence Sufficiency Under Partial Hardware Observability: A Cross-Vendor Empirical Study
Author: Selim Kandaz · Status: Working manuscript / independent research
Research question
What evidence is sufficient to support a specific operational-readiness claim, and what evidence is sufficient to withhold that claim or stop further validation?
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.”
Main findings
- No single observation source was sufficient for all readiness claims.
- Current and historical state are not equivalent.
- Observability can change with physical operating state.
- Missing, empty, unavailable, and failed observations are not equivalent.
- Software verdicts can diverge from independently re-observed physical outcomes.
- Evidence collection can legitimately stop before active workload testing.
- Evidence principles transferred across vendor environments even when interfaces did not.
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.
Interpretation: additional evidence increased confidence in the decision while making the readiness assessment less favorable.
What the study does not claim
- Remaining useful life prediction
- Fleet failure rates
- Vendor ranking
- That a short bounded workload is 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
Or download the working manuscript directly:
Field notes
Short, dated observations from active work: the kind of thing that would otherwise live only in a terminal scrollback or a commit message.
Why a Green BMC Status Is Not Enough
A green or "OK" status from a BMC reflects what the management controller could check, not the full physical state of the system. It can be accurate and still be based on a narrow set of sensors, or on data that hasn’t been refreshed recently.
Evidence statesEMPTY vs UNAVAILABLE vs QUERY_FAILED
These three states look similar in a report but mean different things: no data exists, data exists but wasn’t returned, and the query itself didn’t complete. Treating them as equivalent discards information that matters for deciding what to do next.
StorageWhy 100% SSD Health Does Not Prove a Drive Is New
A health percentage is usually a vendor-computed summary of a small set of counters. It can’t distinguish a drive that’s genuinely unused from one that’s seen light, well-behaved use; both can report the same number.
AutomationWhy Automation Should Wait for State, Not Only Time
A fixed delay is a guess about how long a physical action takes. Waiting for an observable state change instead, such as power state, controller status, or a specific sensor value, is slower to write but doesn’t silently assume success.
LoggingWhat Historical Hardware Logs Can and Cannot Tell Us
Logs are a record of what was captured, not a complete record of what happened. Gaps, rotation, and vendor-specific retention windows mean an empty log is not the same as "nothing happened."
TerminologyWhat Does NOT_EVALUATED Mean?
NOT_EVALUATED marks a case where a decision was deliberately withheld rather than defaulted to pass or fail, usually because a required evidence source couldn’t be reached through an authorized path. It’s a stopping point, not an error to be silently retried past.
Why a Green BMC Status Is Not Enough
A green or "OK" status from a BMC reflects what the management controller could check, not the full physical state of the system. It can be accurate and still be based on a narrow set of sensors, or on data that hasn’t been refreshed recently.
More notes will be added as they come up in ongoing work.