Hardware Match — methodology

Contents

1. What it decides, and what it does not
2. The candidate universe
3. Where each fact comes from
4. The feasibility filter
5. The five ranking terms
6. The weight table
7. The multi-node rule
8. The winner, and the alternatives that are not a second pass
9. How UNKNOWN is treated
10. Why ecosystem scoring was dropped
11. Where the prices come from
12. What invalidates a result
13. Method changelog

1. What it decides, and what it does not

Hardware Match answers one question: for this workload and these constraints, which platform, at how many nodes, and why that one and not the next. It returns a single winner, the whole feasible set in score order, the platforms it eliminated with the constraint that eliminated each, and the arithmetic behind every score.

It does not price a deployment beyond the compute nodes, size a supply, plan a network, choose a carrier board or design an architecture. Those are separate questions with their own inputs and their own engines: Jetson Power & PSU, Carrier Finder, PoE Node Planner, Drive Endurance Fit. Asking those questions here, with nothing supplied to answer them, would return UNKNOWN for every candidate and cap every verdict on a question nobody asked.

Most importantly, it has no override. There is exactly one place a platform is chosen, and it is the top of the ranked list. No caller can request a different winner, no confidence tier re-picks one, and no complete-configuration economics winner is spliced to the front afterwards. If you disagree with the winner, change the inputs; there is nothing else to turn.

2. The candidate universe

The candidates are the eighteen platforms in the hardware catalog, the same set the API publishes at /api/v1/catalog. Nothing is hardcoded in the page and nothing is added silently.

Several ids carry real registry data but have no catalog row — the AGX Orin Industrial, the Orin Nano 4GB, the Raspberry Pi 5, the Intel N100 and three data-centre GPUs. They are not candidates and are listed in the result's gaps so their absence is visible rather than silent. The catalog also carries an alias whose target is not a catalog platform; that too is reported as a gap rather than resolved to something it is not.

Coverage varies across the candidate set and the result says so. Ten platform-scoped registries are counted per candidate; a platform present in only two or three of them is evaluated and ranked like any other, but the checks it cannot answer come back UNKNOWN, which caps its verdict and lowers its evidence term. The pin input restricts the candidate set to named ids without changing a single other rule — every threshold, term and tie-break behaves identically on the smaller set.

3. Where each fact comes from

Hardware Match computes almost nothing itself. Each candidate is evaluated by calling the engine that owns each fact, and every constraint that comes back is stamped with the engine that asserted it, so any number on the page can be traced to a single owner and reproduced by running that engine directly.

Every result carries sub_engines: the method version and dataset version of each engine that actually ran, alongside the single composite dataset_version. A number that changes between two runs can therefore be attributed to the registry that moved.

One rule governs the composition: a figure is only ever pushed into an engine whose registry it belongs to. The catalog's maximum module power, for instance, is not fed to the thermal or power-input checks — for the Orin NX 8GB that figure is the 40 W Super mode while the power-input registry states a 20 W maximum, and comparing one registry's number against another's ceiling manufactures failures. The catalog figure is used only for the cross-platform power term, where it is the one number every candidate has.

4. The feasibility filter

Hard facts only. A candidate is infeasible at a given node count when any constraint comes back FAIL or UNSUPPORTED, or when the node count times the unit power exceeds a power ceiling you stated. It is infeasible outright when that holds at every node count up to the cap.

There is deliberately nothing else in the filter. In particular:

• No tolerance multiplier on stream counts — a load 1.5× over a published capacity is over it.
• No soft penalty for a platform in preview, and no multiplier on an interpolated benchmark. Both are handled where they belong, as evidence class.
• No budget filter. A platform you cannot afford is a different decision from one that cannot do the job; over-budget candidates stay in the ranked list, flagged, and can carry the stretch role.
• No elimination on UNKNOWN. See §9.

Every eliminated candidate is returned with the single constraint that eliminated it — the engine, the check, the status and the two numbers — so an exclusion is always arguable rather than asserted.

5. The five ranking terms

Every survivor gets one score: Σ wᵢ sᵢ over five terms, each normalised to [0, 1]. There are no multipliers, no overlays and no goal-specific code paths; the goal selects a row of the weight table and nothing else changes.

Two details are worth stating because they are not obvious. A constraint that its owning engine marked PASS at a utilization of 1 or more is an identity check — "the module at its published maximum is within its published maximum" — and is skipped by the margin term; counting it would pin the margin of every such candidate at zero. And a candidate with no measurable utilization at all scores a margin of zero, not one: unknown headroom earns no credit.

Every result returns the per-term scores alongside the total, so Σ wᵢ sᵢ can be recomputed from the published numbers and must reproduce the score exactly. A ranking whose arithmetic cannot be checked from the numbers it publishes is not falsifiable, so this is enforced by the validation suite on every combination it runs.

6. The weight table

This is the only judgement in the method, and it is class E: engineering judgement, not measurement. There is one table. It lives in one constant in the engine, is published here, is echoed on every result and is served in the API catalog. No second table, overlay or goal-specific branch exists anywhere else. Each row sums to 1.0.

Ties break deterministically and in this order: fewer nodes, then higher evidence, then lower power, then lower cost, then the platform id. Two identical requests always return byte-identical results.

One ordering rule sits above the score: a candidate whose decode, memory and inference checks are all UNKNOWN is listed after every candidate that has some coverage. Within each of those two groups the list is in non-increasing score order. This is what makes "the winner is the top of the list" safe — a platform nobody can check cannot lead while a checkable one exists.

7. The multi-node rule

Node count is part of the candidate, not a correction applied afterwards. Each platform is evaluated at one node, then two, and so on to the cap (default and maximum 8, settable to any value from 1 to 8); the node count reported is the smallest that fits. The validation suite checks that claim directly: for every multi-node candidate, one node fewer must fail.

Cameras are split by a balanced assignment, so sixteen across six nodes is 3 / 3 / 3 / 3 / 2 / 2 and sums to exactly sixteen — not "six nodes of three", which would be eighteen. Each node is checked at the busiest share, so the assignment is honest at its worst node rather than its average one.

Comparison is always N × the same platform: total cost is N × the unit price, total power N × the unit power, evidence unchanged. A cheap module that needs eight nodes therefore competes honestly against an expensive one that needs two, which is exactly the comparison the legacy engine had to make with a post-hoc splice. There is no hand-off to another engine above any stream count: if nothing fits at the cap, the answer is NO FIT, said plainly.

8. The winner, and the alternatives that are not a second pass

The winner is the first entry of the ranked list. That is the entire selection step.

Alternatives are labels on that same list, computed against the winner — never a second selection pass, and never a separate block that could disagree with the ranking. A platform may carry several roles or none:

The verdict on the winner — FIT, FIT WITH RISKS, NEEDS VALIDATION or NO FIT — is reported, never acted on. A low confidence or an unvalidated check is something to tell you about, not a reason to hand you a different platform.

9. How UNKNOWN is treated

UNKNOWN is never fatal and never free. A missing registry row, a benchmark with no matching entry, an alias we do not trust: none of them eliminate a candidate. Only FAIL and UNSUPPORTED do.

But an UNKNOWN is not costless either. It:

• caps that candidate's verdict at NEEDS VALIDATION, whatever else passes;
• counts as class E in the evidence term, so a datasheet-backed platform outranks an unverifiable one at equal margin;
• and, when decode, memory and inference are all unknown, drops the candidate below every candidate that has coverage, so it cannot win.

An example of the principle in practice: the Hailo-10H previously inherited the Hailo-8's thermal limits through an alias. That alias was wrong data — a different part with different limits — so it was removed at source. The Hailo-10H now reports its thermal check as UNKNOWN, which is a worse-looking answer and a truer one.

10. Why ecosystem scoring was dropped

The legacy ranking carried an ecosystem term built from four numbers — SDK maturity, model breadth, documentation quality and community tooling — and under one goal it carried a weight of 0.60. None of those four figures has a source behind it. They are opinions with a decimal point, and weighting them at 0.60 made them the loudest voice in the room.

V2 does not rescale that term or find better numbers for it. It removes it. The consequences are visible and intended: winners change on many workloads, and in particular the cases where a high-power module beat a low-power one under a stated power goal, or a low-headroom platform beat a far roomier one under a headroom goal, resolve the way the goal says they should.

What ecosystem maturity genuinely affects — whether a runtime is supported on a JetPack release, whether a detector image exists, whether a model family runs at all — is not an opinion and has not been dropped. It is a sourced software constraint from the Jetson Configuration Checker and the Frigate registry, and it can eliminate a candidate outright.

11. Where the prices come from

No price is ever invented. Each candidate's unit price is one of two things, and the result says which on every entry as cost_evidence_class:

• Class B — a current vendor listing that resolves to a URL and a date it was checked, for the unit you actually buy: the bare module, or for the accelerator boards the board itself. Eight of the eighteen catalog platforms have one today: the Orin Nano, the AGX Orin 32GB and 64GB and the Thor T4000 from Arrow; the Coral USB Accelerator, the Hailo-8 and Hailo-8L boards and the RK3588 single-board computer from their retailers.
• Class E — the catalog planning price, which carries a note rather than a source record. Every other platform, including the Orin Nano Super, both Orin NX modules, the Thor T5000, the Hailo-10H, the Neousys system and the four server GPUs.

A platform with neither would get a cost term of zero and a warning, never a guessed number.

One asymmetry is stated rather than papered over. An accelerator card is not a node: a Coral stick or a Hailo board needs a host to decode, pre-process and run the OS. The host's power is included in the figures, because the host's maximum power is a published vendor number. Its price is not, because no vendor listing for it is on record — so an accelerator candidate shows the card price, its cost evidence drops to class E, and the omission is stated in the planning notes and on every entry as cost_excludes_host.

12. What invalidates a result

• Prices move. The class B listings carry the date they were checked; a repricing of the kind the Jetson line saw in 2026 invalidates every cost term at once.
• A workload whose real frame content is far from the modelled one — very high motion, heavy scene complexity, or a detection rate that differs from the source rate in ways the inputs did not capture.
• Any figure a vendor does not publish. An UNKNOWN check is a hole in the answer, not a pass; a NEEDS VALIDATION winner has not been shown to work, only shown not to fail.
• The weight table itself. It is judgement, and a deployment with a real constraint the terms do not model — a rack unit budget, an existing spares pool, a certification the site demands — will rank differently than this does.
• The margin term reflects the tightest check we can measure. A platform that is comfortable on decode and unverifiable on memory can still be the platform that runs out of memory.
• Accelerator totals exclude the host price, and every node total excludes storage, networking, enclosure, mounting and installation.
• The node cap. Eight is a policy, not a physical limit; a workload that needs nine nodes returns NO FIT rather than a nine-node answer.

13. Method changelog

Method changes bump the method version; the composite dataset version follows the newest of the registries this engine composes, and every result also carries the per-engine versions in sub_engines.