Hardware Selector — methodology

Contents

1. Purpose, and its relationship to Hardware Match
2. Inputs and what each one does
3. Hard filters HF2–HF11
4. Capacity, ranking and the evidence floor
5. The latency requirement
6. Compliance
7. Scenario and ambient temperature
8. Evidence limitations
9. Method changelog

1. Purpose, and its relationship to Hardware Match

The Hardware Selector answers one question quickly: for a camera workload described in a few tiles, which platform is a reasonable place to start, at how many nodes? It ranks complete configurations (a platform at the node count it needs) on its own modelled per-node stream capacity.

Transition status: the Selector stays a separate, quick estimator. It is not a thin view over Hardware Match and is not required to agree with it; a difference between the two is not a defect unless the Selector's pick breaks a hard physical limit Hardware Match sees. Hardware Match is the complete-configuration validator — per-node capacity from Camera Stream Capacity, decode, memory, power, thermal and carrier constraints — and its own methodology applies to its results only; nothing on that page describes how the Selector decides.

Every successful result carries scope_disclosure: an estimate_notice, the stated differences from Hardware Match, a hand-off link, the exact Hardware Match request as hardware_match_inputs (cameras, resolution, frame rate, codec, precision, goal, power limit, fanless, ambient, and the Selector's pick as pin), and not_carried — the Selector inputs Hardware Match does not evaluate from the hand-off (scenario, task, latency requirement, compliance).

2. Inputs and what each one does

3. Hard filters HF2–HF11

A platform is removed only by a hard filter. Each elimination carries its reason, and a request with nothing left is answered with NO_ELIGIBLE_PLATFORMS naming the binding constraint.

• HF11 PoE powered-device ceiling: when a PoE standard powers the node, a platform whose lowest supported power preset draws more than the standard delivers is removed (PoE and power-mode registries). Checked first.
• HF2 power envelope: removed when the platform's maximum power exceeds twice the selected envelope.
• HF3 cooling: fanless removes an actively cooled module unless a documented fanless enclosure exists for it; those pass with a sustained-capacity derate.
• HF4 compute floor: removed when the platform's capability tier is more than two tiers below the task's (one tier for generative and language tasks).
• HF5 decode ceiling: removed when the per-node stream count exceeds the published decode ceiling for the codec and resolution.
• HF6 precision: removed when the platform cannot run the requested precision.
• HF7 RT-DETR at INT8 on INT8-only accelerators; HF8 RT-DETR on Hailo; HF10 YOLO12 on the RK3588 NPU: model-support facts.
• HF9 a platform with no neural accelerator cannot run inference.

4. Capacity, ranking and the evidence floor

Each platform's per-node capacity comes from the Selector's own stream model (benchmark rows where they exist, interpolation or cross-platform scaling where they do not), capped by module memory and by the published decode ceiling. The node count is the smallest that carries the load within 8 nodes. Complete configurations are ranked by one weighted score over cost efficiency, deployment simplicity, evidence quality, power efficiency, capacity fit and compute headroom; the default weights are 0.35 / 0.25 / 0.20 / 0.10 / 0.10 / 0, and budget, reliability, minimum-node and vision-language intents select other published tables. The recommendation is the first ranked configuration whose capacity evidence meets the kernel evidence floor (interpolated or better); a configuration ranked above it on modelled capacity only is named as planning-only, never recommended. Accelerator-only configurations (host not costed) are shown separately and never ranked against complete systems.

5. The latency requirement

Targets (planning definitions, class E): real-time critical 33.3 ms per frame, one frame interval at 30 fps; near real-time 100 ms; batch no target, not evaluated. With no latency input the requirement is not evaluated.

Each feasible configuration's modelled per-frame latency is 1000 divided by the modelled single-stream frame rate at batch 1 from the same capacity model that sizes the plan. It is class D: it excludes capture, network and queueing and is not a measured end-to-end latency. Because the evidence is class D, a miss never removes a configuration. The requirement is an ordered ranking preference: with a target set, configurations that meet it rank ahead of those whose latency is unknown, which rank ahead of those that miss it, and the weighted score decides inside each group. Relaxing the requirement therefore never removes a configuration a stricter one accepted.

Every result publishes latency_check: the requirement, the target, the basis, and one row per feasible configuration with its modelled latency and a status — PASS, FAIL, UNKNOWN when the model has no frame rate, NOT APPLICABLE with no target. When no configuration with admissible evidence meets the target, the winner's FAIL is stated in a warning.

6. Compliance

IP67 is a sourced check against the production-carrier registry: a platform is PASS when a registry system for its module carries an IP67 rating that a cited source states, and UNKNOWN when no such system is on record. UNKNOWN is not PASS. The registry records no module as lacking an IP67 option, so the check flags and never removes a configuration; compliance_checks publishes one row per feasible configuration with the evidence behind each PASS.

ATEX and MIL-STD-810 are not modelled: no platform, carrier or enclosure in the registries carries a sourced ATEX or MIL-STD-810 certification. The page no longer offers them, and a request that names either is refused with a validation error on compliance_requirements rather than answered as if the requirement had been checked. Confirm those certifications with the enclosure vendor.

The advisory compliance values the API accepts (NDAA, EU AI Act, HIPAA, NERC CIP, ISO 26262, PCI DSS) produce warnings only; an unknown value is a validation error.

7. Scenario and ambient temperature

Scenario is informational. It labels the summary and flags capability-profile caveats — for example an accelerator whose profile says it is weak for this deployment pattern — and input_effects.deployment_scenario reports the winner's profile fit. It does not change the ranking, the capacity or the cost; Industrial Inspection and Multi-Camera Analytics map to the same profile.

Ambient temperature is a heuristic screen, not a thermal verdict. It produces a warning when a fanless platform exceeds its planning ambient limit or when an estimated junction temperature suggests derating; it does not change capacity, ranking or confidence. Fanless sizing uses the documented enclosure derate, whatever the ambient. For a thermal verdict use the Thermal Feasibility Checker or Hardware Match with an ambient.

8. Evidence limitations

• Per-node capacity is the Selector's own model, not Camera Stream Capacity per candidate; Hardware Match may size the same workload differently.
• Modelled latency is class D and one reference model per task; the real figure depends on the model, runtime and pipeline — measure on the target.
• Hardware costs come from catalog profiles and price rows where wired; gaps are class E until Deployment Cost & TCO prices the configuration.
• The IP67 check reads one registry and covers only systems recorded there; an absent rating means unknown, not unrated.
• The thermal screen is a rule of thumb (planning ambient limit, junction-temperature estimate); it is not a model of any enclosure.

9. Method changelog

Method changes bump the method version; results carry it in provenance.method_version with the dataset version of the registries the Selector reads.