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

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. Only after both are equal 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.

6. Production constraint verdict rule

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.

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

• 19 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.