How EdgeAIStack sizes edge AI deployments.

Data sources

Platform specifications come from vendor datasheets first, cross-checked against community measurements where available. Inference throughput figures prefer vendor-published benchmarks (for example Ultralytics YOLO11 TensorRT results) and are labeled by provenance. All figures are approximate and dated — most recently reviewed mid-2026 — and stream-capacity numbers assume the stated resolution, frame rate, precision, and runtime rather than best-case marketing claims.

Known weak points, stated plainly: in the legacy codec-ceiling table, 1440p and Jetson Thor rows are modelled rather than measured (the V2 decode dataset replaces them with datasheet rows, and labels any interpolated point class D); Thor T4000 datasheet rows are still marked preliminary by NVIDIA; and cost figures are snapshots of US market pricing that drift between reviews. Where a table mixes measured and estimated rows, each row carries its own provenance tag internally.

How the engines decide

Hard physical requirements determine eligibility; preferences influence ranking; optimization goals remain balanced unless explicitly defined as lexicographic; and informational alternatives expose trade-offs without secretly changing the winner.

Evidence class and elimination authority

Every figure an engine compares carries two separate labels. Its evidence class (A to E) describes provenance: who published the figure and how it was obtained. Its elimination authority decides something else: whether that evidence can prove a hard requirement is violated, and so whether a FAIL through it may eliminate a candidate or return NO FIT. Only evidence capable of establishing that a hard requirement is violated may eliminate. Every constraint row publishes elimination_authority, stamped by the engine that computes the figure and carried unchanged by every engine that composes it.

• A / B / C → may eliminate when applicable (authoritative): a vendor specification, an EdgeAIStack measurement or an external measured benchmark, used as published.
• D-bounded → may eliminate (bounded_model): a class D figure only when the derived quantity is a documented, deterministic and directionally safe bound for the requirement being tested — a conservative capacity ceiling derived from measured or vendor evidence, or a deterministic unit or resolution transformation with a documented conservative rule.
• D-estimate → planning / validation only (planning_only): an interpolation, a heuristic efficiency factor, an approximate thermal model, a speculative scaling or a poorly bounded estimate.
• E → never independently eliminates (planning_only).

A derivation is only as strong as its weakest link: one estimated step makes the whole chain planning-only. The bounded steps are an exact unit conversion; a resolution transform that scales a measured figure down for a larger input and never up; the pessimistic edge of several measured rows; a vendor decode rate carried to a stream profile by pixel rate; the reciprocal of throughput, a lower bound on latency; the weights and KV cache of a published architecture, a floor on memory; the air around a module, a floor on its temperature; the IEEE PoE class table; and the largest capacity any candidate in a registry can provide, which no candidate exceeds. The estimated steps include the multi-stream efficiency curve, power-mode calibration factors, cross-platform, cross-task and GFLOPs scaling, class D corpus rows, cooling bands, enclosure rises and design margins, default peak factors, write amplification and motion shares, typical camera draws, runtime and OS memory overheads and host CPU budgets.

A figure that rests on an estimate can still prove a miss when the check fails with every estimated term at its physical bound: an estimated addition to demand at zero, an estimated multiplier on demand at one, a power-mode factor below one replaced by the figure measured at the row's own, higher mode. The FAIL then rests on the bounded evidence, and the row carries that authority.

A miss that rests on planning-only evidence is never a FAIL. The row reads REQUIRES VALIDATION with the modelled shortfall stated and the demoted status recorded; a single-platform engine caps its verdict at NEEDS VALIDATION, and Hardware Match lists the platform as planning-only instead of eliminating it, ordered inside that tier as before (modelled fit first). UNKNOWN is unchanged: it is never a PASS.

Per-engine methodology

Engines built on the V2 constraint framework publish their own methodology page: every formula, every data table with document id, revision and verification date, the evidence class of each figure, and the rule that turns evidence into a confidence label. Results from these engines carry a method version and a dataset version in their permalink.

• Camera Stream Capacity — decode, encode, inference, memory and network constraints; NVIDIA datasheet decode tables; method v1.0.
• Model Memory Fit — weights, KV cache, vision tower, runtime overhead and OS/reserve on the shared memory budget; 22-model registry with published architecture and quantised-artefact sources; method v1.0.
• Jetson Configuration Checker — is this Jetson module × JetPack × install method × runtime × power mode a configuration NVIDIA ships, with the verify plan to confirm it; 16-release registry, 5 install methods, 9 runtime pairings, 7 known issues; method v1.0.
• Thermal Feasibility Checker — will this module survive this enclosure, cooling class and site ambient? Four categorical checks against the vendor's published TTP / SoC / operating-range limits; no junction-temperature prediction.
• Frigate Hardware & Detector Fit — will this platform run Frigate for this camera count: the Frigate detector it runs, the detector capacity from Frigate’s own rule against the inference speeds Frigate publishes, datasheet decode of the detect streams, the ffmpeg preset and the config snippet; 18-platform registry; method v1.0.
• Drive Endurance Fit — will this drive survive this camera wall: the write rate from the shared camera-bitrate table against the vendor’s published endurance, the capacity the retention window needs, the years the endurance budget covers and the write rate the datasheet states; 30-drive registry; method v1.0.
• PoE Node Planner — will this PoE switch power this camera mix: ports, per-port ceiling, budget with headroom and IEEE standard compatibility, with the cameras of each class the switch can hold; 21-switch registry; method v1.2.0.
• Jetson Power & PSU — will this supply run this module: the DC rail against the published input voltage window of the board it plugs into, the power mode against the vendor maximum, the PSU against sustained power × a peak factor, and the PoE powered-device path; 14-module registry; method v1.0.
• Hardware Match — which platform, at how many nodes, and why that one: a deterministic feasibility filter on hard facts only (no soft fudge, no budget filter, UNKNOWN never eliminates), then one ranking function over five terms — margin, evidence, cost, power, simplicity — with a single class E weight table published in full; node count is part of the candidate, alternatives are labels on the ranked list, and the ecosystem score is gone; 18 catalog candidates; method v1.0.
• Compute Fit — does the compute hold this load on this platform: the required frames per second from a target or from cameras × detect rate × motion share, against a throughput resolved once from the normalised benchmark database (the pessimistic edge of the matching rows, narrowed to the batch asked for, or the estimator’s fallback with its tier chain printed), scaled by the multi-stream efficiency curve and any power-mode calibration; class inherited from the rows and demoted on resolution scaling or a power factor; latency in tiers read from a per-row flag, where only a publisher-measured figure can pass a target and the reciprocal of throughput can prove a miss but never a fit; UNSUPPORTED gates the resolver, batch above 1 is UNKNOWN without a row; method v1.0.
• Model Match — which model to run on a platform you already have: the strict candidate universe (a benchmark row on this platform, or the class A model registry for a language task) and the canonical map that joins the two ids the benchmark database records one checkpoint under; per-candidate evaluation composed from Compute Fit and the memory owners with nothing recomputed; a filter on hard facts only, where UNKNOWN never excludes and never passes free; one ranking function over accuracy, margin, evidence and size with the class E weight table published in full and every score recomputable from the printed terms; reference accuracy naming its metric and its dataset and never merged with the per-platform quantised figure, and a model with no published accuracy scoring zero rather than borrowing credit; roles as labels on the ranked list and winner = ranked[0] with no override; method v1.0.
• Architecture Designer — one whole deployment composed from the engines that own each fact and re-decided nowhere: Hardware Match’s platform, node count, per-node camera assignment, cost and power copied verbatim, with no second ranking pass, no confidence re-pick and no mutation of the alternatives or their role labels; Model Match per pipeline stage, or Compute Fit for a pinned model; node-level constraints from the V2 engines that assert them, each stamped with its engine, evidence class and sources. The one judgement it owns is composing stages on one accelerator — utilizations summed and memory added on the shared budget, class E because no measurement of concurrent models exists in this corpus, and capping every multi-stage verdict at NEEDS VALIDATION. Network bandwidth, storage size, system power and the non-compute BOM remain labelled class E legacy rollups, and every legacy figure with no V2 owner is disposed of explicitly rather than dropped silently; method v1.0.
• Carrier Finder — which carrier board, system, developer kit or host SBC meets a list of production needs (CSI, Ethernet, PoE, M.2, Wi-Fi, fanless, industrial, temperature, DC input, price), each need PASS/FAIL/UNKNOWN, never guessed; 36-carrier registry across 14 modules and 16 vendors; method v1.0.
• Benchmark Explorer — what has actually been measured for this hardware × model × precision × runtime, by whom, with the expected range, cross-hardware comparison and the class-D fallback chain; 605-row registry across 24 hardware platforms; method v1.0.
• Benchmark Reality Check — you measured X, the published number is Y — why: the Benchmark Explorer expected range as reference, verdict band, gap ratio, and a 17-cause library ranked by prior likelihood × fit to the gap, each with an on-device verify command; Jetson Configuration Checker hand-off; method v1.0.
• Hardware Selector — the quick estimator (legacy engine, not a V2 owner): hard filters HF2–HF11, complete configurations ranked on its own modelled capacity with an evidence floor, the latency requirement as a class D ranking preference, a sourced IP67 check, informational scenario and heuristic ambient screen, and the hand-off that lets Hardware Match validate its pick; method v3.0.
• GPU Sizing — the legacy compute planning envelope (not a V2 owner): required TOPS from the model’s compute figure, precision and batch, catalog TOPS per platform and a heuristic score; Compute Fit owns the throughput question and Hardware Match the platform choice; method v2.0.2.
• Full Deployment Planner — the Production / BOM view over one Architecture Designer run: the architecture copied verbatim, class E planning additions (installation, sensors, compliance, certifications) and the business-case arithmetic; pricing from Deployment Cost & TCO; method v1.4.
• Measurement Protocol — how to measure your own board and submit a benchmark row for review as a class-C measurement; protocol v1.0.

Validation

The engines are tested by consistency suites that run thousands of input combinations and assert cross-engine invariants — for example, that a power-optimized recommendation never selects a higher-power platform when a feasible lower-power one exists, or that storage, bandwidth, and power outputs agree with each other for the same workload. Suites run at three levels: individual engines, orchestrated engine groups, and the full Architecture Designer.

Figures are from the most recent recorded runs (September 2026). Every suite is at 100%: the eight architecture-suite failures that stood here through August — a headroom floor for performance-goal picks, a check that alternatives never grossly dominate the primary recommendation, and a TDP ceiling for power-goal picks — closed when the Architecture Designer replaced the orchestrator that assembled the answer. The engine ranks once, on five published terms, and a cheaper or cooler candidate beating the winner on one of them is now labelled output rather than a defect. Separately from the engines, the calculator UIs on this site are covered by a Playwright end-to-end suite (1,768 tests across tool flows, engine rules, SEO metadata, accessibility, redirects, and error handling).

Confidence labels

Recommendations carry a confidence label (high, medium, low) rather than a raw score. The label reflects benchmark coverage for your specific workload: measured vendor benchmarks rate higher than interpolated estimates, which rate higher than theoretical TOPS-based extrapolation. When the engines fall back to an estimate, the assumptions panel says so explicitly.

Under the label is a numeric score built from weighted factors — benchmark coverage is the heaviest at 40%, followed by interpolation distance, environment, runtime, precision, and workload-complexity match. A direct benchmark measurement scores full marks on coverage; interpolation within the same model family scores 0.85; scaling across platforms by TOPS scores 0.65; a rough estimate scores 0.40. The composite is a geometric mean capped near the weakest factor, so one bad assumption cannot be averaged away. Scores of 0.85 and above are labeled high, 0.70–0.85 medium, and below 0.70 low. For feasibility-style engines (power, storage), the label tracks headroom instead: comfortable fit is high, a tight fit is medium, and a risky fit is low.

In practice: benchmark-backed estimates carry roughly ±15% expected variance, interpolated estimates widen to about ±20%, and theoretical TOPS-based estimates are planning-only at ±30–50% — community measurements typically land 15–40% below vendor TOPS projections. Scaling a benchmark to a different resolution adds up to ±25% on top. After every run, the assumptions panel lists exactly what the engine used — hardware, runtime, model and variant, precision, resolution, frame rate, streams — plus the estimation method, and flags any resolution scaling. Internally each input is tagged as user-provided, defaulted, or inferred, so a recommendation built mostly on defaults is distinguishable from one built on your actual numbers.