no verified finding yet
The accepted Grade A run ledger is empty. Candidate compatibility results are modeled, not physical lab measurements.
inspect the draft protocol and empty ledger →mini pc homelab compatibility lab
make tiny pcs do unreasonable things.
choose the exact box and the workload. get a fit result you can open up, the limiting axis, every assumption the answer depends on, and the source record behind each check. where a fact is missing, the answer is unknown and names the missing fact.
“the exact box” means this chassis, this processor, this memory, this drive. a model name alone does not resolve it. a workload is one app at one version with a stated deployment method; a stack is more than one workload on the same box. an axis is one place a check can fail: compute, memory, acceleration, storage, network, thermals.
- maintained source records
- 22
- current app version scopes
- 3
- last accepted lab run
- none accepted
- correction intake
- release-blocked
no sponsored rankings. no mystery scores. sources, review dates, and empty evidence states stay visible.
current lab ledger
- modeled configurations
- 5
- pilot app scopes
- 3
- workload recipes
- 3
- lab-verified results
- 0
private pilot schema 0.1.0. the release separates manufacturer-supported facts from inference. grade a means this lab reproduced the run on a bench and published the method with the raw result. nothing weaker is called measured here. grade a measurements remain empty until the physical lab reproduces them.
current decision state
verified when it exists. explicit when it does not.
same workloads, two exact profiles
Compare the Lenovo M720q i5-8500T and ASUS PN42 N100 across the same 3 pilot workloads. Conditions stay visible; the page does not invent a universal winner.
open the exact-profile comparison →correction intake is not configured
No submission channel or open-correction count is being claimed. A brand-owned private channel remains a hard blocker before public release.
review the correction protocol and release blocker →why this exists
the model name is not the configuration.
“thinkcentre m720q” still leaves the processor, memory, storage, expansion hardware, firmware, runtime, and workload unanswered. this lab keeps those conditions attached to the verdict instead of hiding them behind a green checkmark.
three useful ways in
start with what you know
i own a tiny box
resolve the exact configuration, then add one or more workloads.
browse exact configurations →i know the stack
start with the apps and assumptions, then see which boxes clear them.
browse workload recipes →i found a listing
check the processor, memory, storage topology, and missing parts before buying.
resolve a configuration →how a verdict is made
facts in. conditions kept. answer out.
- resolve the hardware. chassis, cpu, memory, storage, network, expansion, and firmware-sensitive capabilities.
- declare the workload. software version, deployment method, concurrency, media or device assumptions, and storage needs.
- evaluate each axis. compute, memory, acceleration, storage, network, thermals, and operational risk stay separate.
- show the evidence. each check exposes its attached evidence records. missing, stale, untyped, or contradictory support forces an unknown result; the separate critical-fact audit determines whether coverage is complete.
pilot coverage
small on purpose
the public pilot is capped at 5 exact configurations, 3 workload recipes, and 1 multi-app stack, built around 1 primary deployment pattern. those recipes use 3 explicit deployment methods. an unsupported combination stays inside the checker as unknown; it does not become a thin search page.
start with the app and deployment ledger, open the stack ledger, read the benchmark queue, or see how corrections change a verdict.