How the Carrier Finder ranks carrier boards, systems and dev kits against your production needs.

Contents

1. Purpose and scope
2. Inputs
3. Need catalogue
4. The UNKNOWN rule
5. Ranking rule
6. Production constraint verdict rule
7. Evidence classes
8. The registry
9. Limitations and gaps
10. Versions
11. Citation format
12. Method changelog

1. Purpose and scope

Sizing an edge AI module (Jetson Orin, Hailo, Coral, RK3588, Raspberry Pi) tells you the compute — it does not tell you what to actually bolt it to. The Carrier Finder searches the production-carrier registry — carrier boards, complete systems, developer kits and host SBCs — for the module you picked and ranks every candidate against the production needs you give it: how many cameras it can take, how it talks to the network, how it is powered, whether it survives your enclosure's temperature range, and what it costs.

It does not estimate compute throughput, memory fit or power draw for the module itself — that is the Camera Stream Capacity, Model Memory Fit and Module Power Calculator engines' job. It also does not check flash/software compatibility — for Jetson modules, run the Jetson Configuration Checker against the JetPack release you plan to run.

2. Inputs

Inputs (WP-01). A field that is not stated takes its documented default and is listed in provenance.defaulted; a field that is stated but invalid — a count of 0, a negative, a fraction or a non-number, true in place of a count, an unknown value of an enumerated input, or an empty string — is rejected with VALIDATION_ERROR naming the field, never replaced by a default.

Input keys (WP-02). The engine accepts one list of input keys — the inputs documented here and their declared backward-compatible aliases. Unknown input keys are rejected with VALIDATION_ERROR naming the key: an invented or misspelt key is never silently ignored, a __ test hook never reaches the engine, and an alias sent together with the key it stands for is rejected too (the engine would read only one of them). export_json.inputs echoes every input the engine honoured, so replaying it reproduces the result.

3. Need catalogue

Every need has a kind that fixes how it is compared against the carrier's field, and a plain-English pass rule. min needs pass when the carrier's value is at least what you asked for; max needs pass when it is at most what you asked for; bool needs pass on an exact true/false match; present needs pass when the field is populated (or, if you asked for false, when it is empty); the two temp needs and the one range need have their own rule below the table because they compare against a range, not a single number.

min_temp_c and max_temp_c are independent — give both to require a full range (e.g. min_temp_c: -20, max_temp_c: 60) and the carrier must clear both ends. Validation rejects min_temp_c greater than max_temp_c, a dc_input_v outside 1–100 V, and a temperature outside −60 to 120 °C.

4. The UNKNOWN rule

A need is UNKNOWN whenever the carrier's field for it is null — the vendor page or datasheet used to build the registry did not state that fact — or, for the range need (dc_input_v), when either the minimum or the maximum of the range is missing. UNKNOWN is not a failure: it does not lower a candidate's fails count, and it never blocks a PASS verdict on its own. It is tracked separately as unknowns and used only to break ties in ranking (below) and to set the REQUIRES_VALIDATION verdict. The rule exists because a missing figure on a vendor page means "not published," not "unsupported" — guessing either way would be worse than saying so plainly. Every result names which needs were UNKNOWN so you know exactly what to confirm on the datasheet before ordering.

5. Ranking rule

Every candidate for the module (or family) is sorted by this key, in order:

Fewest misses always wins first — a carrier with one FAIL never outranks one with zero, regardless of price. Among candidates with the same number of fails, fewer UNKNOWNs wins — a fully documented carrier beats a cheaper one you cannot fully verify from the vendor page alone. Among those, the better-documented record ranks first (a price on record counts as one of the six facts). Only after that does price break the tie, and a carrier with no published price ranks behind one that has a price, however low. Vendor and product name are the final, deterministic tie-breakers so the order never depends on registry insertion order.

Priced first (method 1.4.0). When Hardware Match composes Carrier Finder for a deployment, it sets prefer_priced, and a known price moves ahead of record completeness (step 4's known-first test runs before step 3): among carriers that miss and leave unknown the same number of needs, one the bill of materials can price ranks ahead of a better-documented one it cannot. A request that does not set it, including this engine's own page and the carrier pages, keeps the order above.

The response fields best and closest pick carriers for production attachment, not just display order. best is the top ranked row whose verdict is MEETS — every stated need is sourced and passes — or null when no candidate is a clean MEETS. closest is the row that would have been best under the earlier rule: the top MEETS_UNVERIFIED row when one exists, otherwise the first row in the full ranking (fewest fails, then unknowns, then price). It is null when there are no candidates. Warnings name closest when nothing fully meets; the production constraint cites best when it is set, otherwise closest, and records which in detail.cited (best or closest). Downstream orchestrators (Hardware Match) attach a priced carrier only from best — a row that is only closest stays planning-only until every need is verified.

6. Production constraint verdict rule

A port count summed over several fields (Ethernet ports of any speed, 2.5 GbE or faster) is a lower bound when one of those fields is unstated. A carrier that misses a need only on such a partial count has not been shown to miss it, so the search-wide FAIL is established only when every candidate misses a need on a stated figure; otherwise the production row is REQUIRES_VALIDATION (planning-only evidence cannot eliminate — see elimination authority).

Every result carries one production constraint whose status summarises the whole search, computed from the ranked candidate list:

Confidence follows the same evidence used for the top candidate: HIGH when the verdict is PASS and the best candidate's evidence is class A, MEDIUM when the verdict is REQUIRES_VALIDATION with class-A evidence (or any PASS resting partly on class-C evidence), and LOW when no candidate was found or the best candidate is backed only by class-C sources. A single per-need UNKNOWN never lowers confidence on its own — it is what drives the REQUIRES_VALIDATION verdict in the first place.

7. Evidence classes

Every carrier row, and every field on it, traces to one of two evidence classes used in this registry.

A carrier's overall evidence_class is A if any of its sources is class A, otherwise C. Each field's provenance is still the specific source it was quoted from — see the sources list on every per-carrier page.

8. The registry

36 carrier boards, systems, developer kits and host SBCs across 14 edge AI modules (NVIDIA Jetson Orin/Thor, Hailo-8/8L, Google Coral, Rockchip RK3588, Raspberry Pi 5), 16 vendors. 20 of 36 rows state a full operating temperature range; 16 of 36 have a public list price. 33 rows carry at least one class-A (vendor) source; 3 rows rest on class-C sources only.

A developer-kit row lists every module its carrier accepts, but the kit ships one module, and its price is the kit's. NVIDIA states that the Jetson Orin Nano developer-kit carrier supports all Jetson Orin Nano and Orin NX modules; the kit ships the Orin Nano 8GB development module, so the row names the modules it takes but does not ship (modules_not_included: Orin Nano 4GB, Orin NX 16GB, Orin NX 8GB). For a module the kit does not ship, the listing does not include it and has no price for it: the candidate shows module_included: false, no price and available_separately: false (NVIDIA does not sell the carrier on its own), so it never reads as a $399 answer for an Orin NX. The original Jetson Nano Developer Kit carrier (P3449, for the first Jetson Nano) is a different board: NVIDIA states the Orin Nano and Orin NX modules are not supported on it. It is not in the registry, and no module name, alias or search reaches the Orin Nano kit carrier through its names: “Jetson Nano Developer Kit”, “Jetson Nano” or its part number is refused as an unknown module.

Full browsable tables: the Production Carriers hub (all 36 rows and the module coverage table), a page per module, and a full spec sheet per carrier with every source quoted. Machine-readable copy with the complete provenance record for every field: production-carriers.json.

9. Limitations and gaps

• 20 open research gaps remain on individual rows — mostly unconfirmed operating-temperature ranges, USD prices only available from a reseller (not the vendor), or a spec that could not be quoted verbatim from a fetchable page. Every gap is listed with the specific product and field on the registry hub and repeated on the affected carrier's own page.
• A field left null is reported as UNKNOWN by every need that reads it — this is deliberately conservative. A carrier may in fact meet an UNKNOWN need; the registry just does not have a citable figure for it yet.
• Prices are a single list price as of the date shown, not live pricing — most industrial-channel vendors quote on request and their rows are UNKNOWN on max_price_usd.
• The registry does not track stock/lead-time, minimum order quantity, or regional distribution — only the vendor's own published specification and (where stated) list price.
• Camera capability is recorded as connector count and lane width where published; exact sensor compatibility (which CSI sensors a given carrier's ISP/driver stack actually supports) is out of scope.
• The engine does not check module × carrier electrical/mechanical compatibility beyond the registry's own modules[] list for each row — always confirm form factor and connector pinout against the datasheet before ordering.

10. Versions

Every result URL carries mv (method version) and dv (dataset version); when either differs from the current values, the result page flags that the data has changed since the link was made.

11. Citation format

Cite a Carrier Finder result or a registry row as:

Every result and per-carrier page names its own sources — cite the underlying vendor page or datasheet directly for a specific spec, and cite the URL above for the ranking/verdict itself. The sources[] array in the API response and in production-carriers.json gives publisher, document, URL and the date each fact was last verified for every field.

12. Method changelog

Method changes bump the method version; registry updates (new carriers, corrected specs, newly confirmed fields) bump the dataset version. Both appear in every result's citation block and in the dataset_version / method_version fields of every API response.