Architecture Designer — methodology

Contents

1. What it decides, and what it does not
2. The composition: which engine answers which question
3. Hardware Match’s answer is copied verbatim
4. The pipeline: stages, rates and the fan-out
5. Composing stages on one accelerator — the class E assumption
6. How the verdict is composed, and where it is capped
7. Three inference envelopes
8. Verdict drivers
9. Alternatives keep Hardware Match’s order
10. Where the whole-system rollups come from
11. Legacy figures with no V2 owner, and what happened to each
12. What the result reports about its own coverage
13. What invalidates a result
14. Method changelog

1. What it decides, and what it does not

The Architecture Designer answers one question: given this workload, these constraints and this pipeline, what is the whole deployment — which platform, at how many nodes, with the cameras split how, running which model at each stage, against which constraints, with what bill of materials, and what should be measured before any of it is bought.

It does not decide which platform wins. That is Hardware Match's question, and its answer is copied here without change. It does not decide which model to run either — that is Model Match's, per stage. It does not compute a throughput, a latency, a memory figure, a thermal margin or a carrier verdict of its own: every one of those comes from the engine that owns it, stamped with that engine's name, so any number on the page can be reproduced by calling that engine directly with the same inputs. That is what makes the composed answer checkable rather than asserted.

Derived carrier requirements (method 1.5.1). For bare modules, Hardware Match always composes Carrier Finder. This engine forwards environment-derived needs as DERIVED (industrial for factory / harsh indoor; outdoor and mobile pass ambient, fanless and enclosure independently — never industrial for outdoor alone), and derives module_included: false so bundled systems stay out of scope unless the caller states module_included: true or form_factor: system. Stated carrier needs override per id. The architecture block carries carrier_id, carrier_needs provenance, and prices the selected carrier through Deployment Cost & TCO when a registry price exists.

Environment → planning ambient (method 1.17.0). When no ambient_max_c is given, the environment sets the ambient the thermal checks run at. The figures are planning bands from the site's thermal research (the environmental-match bands and the vehicle zones), not measurements of any site: class E, published as an assumption, recorded in provenance.defaulted and provenance.derived, and overridden by any stated ambient_max_c.

A derived ambient above 25 °C is sent to Hardware Match as ambient_max_c, so it also becomes a carrier temperature need, exactly as a stated ambient always has. The enclosure is not derived from the environment: state it, and the thermal checks add that enclosure's internal rise.

Battery and UPS (method 1.17.0). Battery and UPS runtime are not modelled: no energy-storage, runtime or power-limit model exists. The request still accepts power_source: battery or ups, and the result lists it under not_evaluated with that reason and an assumption line; it never becomes a constraint. Mains and PoE are modelled. See Jetson Power & PSU for supply sizing.

What it does own is the composition itself: how the per-stage results are put together on one node, and what that composition is allowed to claim. There is exactly one judgement in that, it is unmeasured, and §5 is about nothing else.

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.

2. The composition: which engine answers which question

Every constraint returned carries engine and check, its evidence class, its source records and the assumptions behind it. The result also carries sub_engines: the method version and dataset version of every engine that contributed, and a legacy flag on the one that is not V2 yet (the cost engine).

3. Hardware Match’s answer is copied verbatim

This is the rule the engine was built around, and it is worth stating in the flat form:

• No second ranking pass. There is no scoring function in this engine. The platform, the node count, the per-node camera assignment, the hardware cost and the hardware power are what Hardware Match returned; the five term scores and the weight table on the page are its own, published so the total can be recomputed from the printed numbers.
• No confidence re-pick. A LOW confidence on the winner is reported, never a reason to reach past it for the runner-up. The legacy orchestrator did exactly that — ranked, then spliced a multi-node economics winner to the front, then re-picked on a confidence tier — and the disagreements it produced are the reason this engine has one selection step instead of three.
• No mutation of the alternatives. alternatives[] is Hardware Match's ranked list minus the winner, in its order, carrying its own role labels — lower_cost, lower_power, higher_headroom, stretch. Nothing here re-sorts it, filters it, re-scores it or adds a role to it. The page renders it in the order it arrives.
• No override input. There is no field by which a caller picks the winner. Pinning a platform narrows the candidate set Hardware Match ranks and changes no other rule; it does not choose an answer, and if the pinned platform cannot hold the load the result says so instead of substituting one you did not ask about.

One consequence is worth being explicit about, because it looks like a bug until you see the alternative. Hardware Match ranks platforms against one model's load — the workload's model family and variant — because that is the question its five terms are defined over. The pipeline is then composed on the platform it picked. So a pipeline that does not fit on that platform is reported as not fitting, at whatever percentage of one accelerator it needs, rather than quietly triggering a second ranking pass against a different load. The result names the levers: reduce the fan-out, pin a smaller model, raise the node cap, or pin a platform.

The request put to Hardware Match carries that stage’s vision task (classification, detection, segmentation or pose) with its model, so the throughput it ranks on is read for the task the stage runs — unless the model is filed under another task (a detector named for a segmentation stage is sized as the detector it is, not as a cross-task estimate). With no model named, segmentation and pose are sized on their own defaults, YOLO11s-seg and YOLO11s-pose (method 1.17.0) — never on the detector. The benchmark corpus has measured FP16 rows for those two models on some Jetson Orin modules — YOLO11-seg on the Orin Nano Super and the AGX Orin, YOLO11-pose on the Orin Nano Super, the Orin NX 16GB and the AGX Orin 32GB — but no INT8 row on any Orin: no INT8 YOLO11-seg or calibrated INT8 YOLO11-pose measurement on an Orin is published. Segmentation and pose therefore default to FP16 (method 1.20.0): with no precision named they are sized on the measured FP16 rows, and the precision is recorded as a derived planning default, never as your choice. A named INT8 is evaluated as asked: on an Orin it reads NEEDS VALIDATION and names the missing benchmark. It also carries the caller’s power_mode unchanged. Hardware Match resolves the mode as a ceiling and the design is computed at the preset it selected (planning_configuration.power_mode); an unrecognised mode is a validation error naming power_mode, never dropped. The exact request is published as composed_requests.hardware_match.

Precision (method 1.20.0). A precision you name is the precision of every stage and of the model Hardware Match sizes, exactly as named. With none named, each stage of a pipeline you send runs its own task’s planning default — FP16 for segmentation and pose, INT8 for detection and classification — and the model Hardware Match sizes runs the workload’s: the task you state, else — for a pipeline of exactly one stage naming a task Hardware Match sizes (detection, classification, segmentation or pose) — that stage’s own task and model, the stage’s named model if it names one, otherwise that task’s default (method 1.22.0, bug #268), else the task the model registry files the model you name under. Without a pipeline the single stage is the workload and runs that same default; a pipeline of two or more stages keeps the workload’s own (unstated → detection) task — there is no single stage to stand in for it. Pinned to (or filtered to a family of) platforms that run only INT8, the FP16 task default falls back to INT8, their supported precision, and the record says why. The result lists precision in provenance.defaulted, marks each such stage precision_defaulted and adds one DERIVED record per task-specific default, with the reason. When you state a JetPack, a sourced build limitation of a model at its precision on that JetPack’s TensorRT release is carried from Hardware Match into compatibility_risks and risks: YOLO11-seg INT8 is reported not buildable through any upstream-supported path on TensorRT 10.3.0 (JetPack 6.1, 6.2 and 6.2.1). It is a validation requirement, never a reason to change the platform or the verdict.

4. The pipeline: stages, rates and the fan-out

A pipeline is up to four stages. Each stage carries a task, what it runs on, and a rate:

• A stage that runs on camera frames is sized at cameras on one node × the detect rate × the motion share. An explicit per-stage frames-per-second figure overrides that; left blank, the stage inherits the workload's detect rate.
• A stage that runs on an earlier stage's output is sized at the parent's rate × the fan-out, where the fan-out is how many detections each frame produces. It defaults to one per frame and the result marks it as defaulted when it was.

The fan-out is class E. Nothing measures how many objects your scenes contain; it is a statement about your deployment, not about the hardware, and it multiplies straight into the throughput the downstream stage is asked for — two detections per frame doubles that stage's required rate. It is therefore always shown, always labelled, and never silently chosen for you beyond the default of one.

Every stage is sized on one node, not on the fleet, because that is the machine the models actually share. A stage's model is Model Match's pick out of the models with a benchmark row on that platform, or Compute Fit's verdict on the model you pinned; either way, the throughput, latency, precision, runtime, batch and memory figures are that engine's own and are reproduced unchanged.

Model preference (method 1.17.0). The preference chooses the variant inside the family the platform was sized on; it never changes the platform. On balanced the default frames stage keeps the exact model Hardware Match ranked on (YOLO11s by default). On accuracy, speed or size the variant is left open and Model Match ranks the variants of that family that fit this node with its own weights for that preference: accuracy takes the most accurate variant that still fits, speed the one with the most throughput margin, size the smallest weights. When one variant is both the fastest and the smallest (YOLO11n in the YOLO11 family) speed and size agree. A family and variant you name are never overridden. Each stage publishes model_selection — the basis, the family, the preference and why this variant.

5. Composing stages on one accelerator — the class E assumption

When more than one stage lands on one node, they share one accelerator. This engine composes them by summing their utilizations and adding their memory on the shared memory budget. That is the whole model, and it has no measurement behind it.

There is no measured concurrent-model throughput anywhere in this corpus. That statement is precise, and it is worth unpacking, because two things that look like evidence for it are not:

• The multi-stream scaling curve models N streams of ONE model. It says what happens to throughput when you feed a single loaded network more concurrent streams. It says nothing about two different networks contending for the same compute units, the same memory bandwidth and the same scheduler — and treating it as if it did would be borrowing a number from a question it was never asked.
• The one multi-model source on record is a recommendation, not a measurement. It advises running the models in separate containers with CUDA stream priority rather than under MPS, and it budgets roughly 3 % container overhead. It does not measure the throughput either model achieves while the other is running. So it is cited as guidance and it is never turned into a coefficient; a 3 % container overhead is not a concurrency model.
• The stage vocabulary in the research corpus is decode → preprocess → infer → postprocess — the internal stages of running one model, not two models sharing a device.

Summing is the honest choice among the available ones. It is not conservative in every direction: real contention can be worse than a sum, because two resident networks also contend for memory bandwidth and cache, and it can be better, because a stage that is latency-bound rather than throughput-bound may interleave into the other's gaps. Which of those dominates on your silicon, your runtime and your models is exactly the thing nobody has measured here.

So the sum is stamped class E — engineering heuristic, no source record — on the pipeline block, on the pipeline_accelerator_share constraint and in the assumptions, and the result links to the measurement protocol, which is how you replace this assumption with a number. Memory is composed the same way and reports UNKNOWN rather than an estimate whenever a stage has no memory split on record — an unknown is never filled in with a guess.

6. How the verdict is composed, and where it is capped

The architecture's verdict is the worst of: Hardware Match's verdict on the winning platform, every stage's verdict, and the status of every composed constraint. A FAIL anywhere makes it NO FIT; a NEAR LIMIT makes it FIT WITH RISKS; an UNKNOWN caps it at NEEDS VALIDATION and never eliminates anything. Every row keeps the elimination authority its owner stamped, and a FAIL is only ever raised on authoritative or bounded evidence — a miss on planning-only evidence is REQUIRES VALIDATION wherever it is composed.

On top of that there is one hard cap. Whenever more than one stage shares an accelerator, the verdict is capped at NEEDS VALIDATION, regardless of how much headroom the sum shows. A class E sum can show a miss — 155 % of one accelerator — but it cannot eliminate on its own: class E never independently eliminates (elimination authority), so the shared-accelerator row is REQUIRES VALIDATION with the modelled shortfall stated. Nor can it ever confirm a fit, because the arithmetic that would confirm it is the arithmetic nobody has checked. A stage that misses on its own is judged by its owner's row, with that row's elimination authority. A single-stage architecture is not capped: nothing is composed, so there is no assumption to carry.

Each stage is also reported on its own, with its own verdict, so a reader can see which part of the composition is solid and which part is the assumption.

A NO FIT with no platform to design on is an answer (method 1.17.0). When Hardware Match finds no feasible platform, or only planning-only ones, the response is HTTP 200 with verdict: NO_FIT, architecture: null and refusal_reason — never an HTTP 400. It carries the excluded platforms with the row that eliminated each, the planning-only candidates with their reasons, Hardware Match's best planning candidate capped at NEEDS VALIDATION, the questions that could change the answer (including “design on the best planning candidate anyway”, a pin), the workload echo, provenance and the composed Hardware Match request. HTTP 400 is kept for malformed or invalid requests.

Two refusal kinds (method 1.17.2). The shared refusal row names which one it is. When every candidate failed a hard requirement it is ALL_CANDIDATES_EXCLUDED, and each excluded platform names its reason row. When candidates survived but every survivor is planning-only it is NO_RECOMMENDATION_ELIGIBLE (reason INSUFFICIENT_EVIDENCE, still verdict NO FIT): nothing failed, so there may be no excluded platform at all — the planning-only rows, each with its disposition reason code, are the reason, and the question pins the best of them. Applying that option designs on the pinned platform, capped at NEEDS VALIDATION, even when a family filter was set (the option clears it).

Use case and budget tier are not design inputs (method 1.17.2). Security, retail analytics, industrial inspection and traffic are labels: no engine models a difference between them, so the result lists use_case under not_evaluated as informational and the design is the same for all four. The NVR (Frigate) path is a task (task: nvr), not a use case. A budget_tier is accepted and listed as not evaluated; budget_usd is the budget Hardware Match compares each configuration's total cost against, as a label (never a filter).

6a. Three inference envelopes

Several constraints share the check id inference. They are different operating envelopes and are labelled separately on every result (label, represents, envelope). primary_bottleneck names which envelope breaks first — on NVR workloads that is usually Frigate Fit's detector budget, not generic platform throughput.

• Platform detection throughput (camera_stream_capacity.inference, envelope platform_inference) — benchmark-scaled detection fps the accelerator sustains for the streams on one node.
• Frigate detector envelope (frigate_fit.inference, envelope frigate_detector) — detect fps × cameras against the detector's measured detections/s at the detect rate.
• Stage model throughput (compute_fit.throughput, envelope stage_model) — the pinned or selected stage model's benchmark fps on this accelerator.

Decode and preprocessing rows follow the same pattern: Camera Stream Capacity vs Frigate Fit, each with its own label.

6b. Verdict drivers

When the verdict is not FIT, verdict_drivers (on the results and on the architecture) lists every owner row that produced it, verbatim from the engine that owns it (method 1.18.0): each constraint whose own verdict is worse than FIT, each row of Hardware Match’s winner that the design re-ran for its own inputs and does not hold itself, Hardware Match’s planning-only admission on a pinned platform, a material risk on its winner, the class E multi-stage pipeline cap, and any blocking unknown not already listed. A FIT WITH RISKS names at least one NEAR LIMIT row (or a material risk), a NEEDS VALIDATION an UNKNOWN or REQUIRES VALIDATION row, a NO FIT a failed row; a FIT names none.

Each driver carries its owner’s engine, check, status, value and limit (required, available, unit), its stage or scope and a row_source (architecture, hardware_match_winner, hardware_match_admission, hardware_match_winner_risk, pipeline_composition, blocking_unknown), plus cause, validate, to_reach_fit and flips_verdict_to (FIT only when a single NEAR_LIMIT or REQUIRES_VALIDATION driver remains). A row Hardware Match’s verdict rests on is carried even when the designer re-ran that check for its own recording topology and reads it differently, because an architecture verdict is never better than the hardware verdict; every FAIL or NEAR LIMIT driver also has its high- or medium-severity risk. The order is FAIL → NEAR_LIMIT with utilization ≥ 0.95 → REQUIRES_VALIDATION → other NEAR_LIMIT → UNKNOWN, then utilization descending (class E presentation). Rows that produced nothing (a non-flipping or not-asked prerequisite) are listed under verdict_prerequisites.

The evidence gap that decided the platform (method 1.18.0). Hardware Match publishes its best planning candidate even when a winner exists. When that candidate is planning-only and ranks above the winner on Hardware Match’s own ordering past the disposition key (score, then platform, then node count), the result names it in platform_evidence_gap: the candidate and the winner with their scores, Hardware Match’s disposition reason code and the missing evidence. It is informational, not a verdict driver, and changes neither the winner nor the verdict.

6c. Alternatives keep Hardware Match’s order

alternatives[] is Hardware Match's ranked[] minus the winner, in the same lexicographic order: recommendation disposition and eligibility, thin registry coverage, then score — not score-descending. Each alternative carries ordering_key with hardware_match_rank (its index in ranked[]), disposition, coverage flag and score. results.alternatives_ordering_note repeats Hardware Match's weights.ordering_note verbatim.

7. Where the whole-system rollups come from

Bitrate, storage, power and cost come from the V2 engines that own them; each totals tile carries that line's class in totals.classes (and totals.sources names the owner). totals.cost_label is Sourced hardware BOM when every line is priced; totals.cost_scope lists included line kinds and known omissions (switch, cabling, installation, and similar). The bill of materials is Deployment Cost & TCO — registry-priced lines with per-row evidence classes (camera resolution classes remain class E planning allowances). The annual energy rate is a class E input. totals.evidence_class is the weakest class among the rollup lines.

Frigate inference when the pipeline names another detector. When the user names a stage model that is not Frigate's stock detector on that platform, the Frigate inference check is carried as detail.advisory with reason: stock_detector_differs. It does not bind feasibility, node count, verdict rollup, primary bottleneck or risks[]; the other Frigate checks stay binding. A pipeline stage without a model is sized as if no model were named: Model Match picks it and a Frigate workload is judged on the stock detector.

Frigate load parity on NVR workloads. Frigate Fit's per-node detection demand is the pipeline's stated frames-stage rate when one is given (otherwise the shared NVR default). On the reference sixteen-camera NVR input, Frigate inference required equals the frames stage's required_fps.

Invariant: totals.power_w equals the sum of the published power breakdown (module draw × nodes, node-local drive draw, pool drive draw, storage-host typical draw when published, plus camera PoE when PoE-powered). Pool and host draw are separate from the edge-node PSU rating in totals.psu_w.

The compute line is Hardware Match's price — class A–C when a vendor listing is on record, otherwise the catalog planning price (class E). The hardware cost and hardware power on the architecture block are likewise Hardware Match's, not the whole-system rollup's — which is why those two figures and the whole-system rollup can differ on the same result and are shown separately rather than reconciled into one number.

A rollup that does not resolve is reported as null with a risk explaining why, never estimated. When a registry line has no listing, unit_usd stays null, cost_complete is false and the note names the gap.

8. Legacy figures with no V2 owner, and what happened to each

The engine this one replaces produced several figures that no V2 engine owns. Dropping them silently would hide a change in what the page claims, so each one is listed here with its disposition.

9. What the result reports about its own coverage

• Candidates, evaluated, feasible, excluded — and a per-registry count, so a platform that ten registries know well is distinguishable from one that three of them mention.
• Thin coverage is named. A platform present in three or fewer of the platform registries is still evaluated and still ranked, and is capped at NEEDS VALIDATION with the reason stated.
• Registry-only platforms are named. A platform that exists in a data registry but not in the hardware catalog is not a candidate, and the result lists which ones those are rather than leaving them silently absent.
• Stages resolved and rollups resolved are counted, so a partial answer is visibly partial.
• Every eliminated platform comes back with the exact constraint that eliminated it — the check, the engine, the status, what was required and what was available.

Typed comparisons and scope labels (v2.51). Every constraint row on the page and in the copied summary prints its relation with the operator its comparison type declares — required ≤ available for a minimum-capacity check, actual ≤ maximum for a ceiling, minimum ≤ actual ≤ maximum for a range, = / ≠ with the words compatible, satisfied or true for a compatibility, prerequisite or boolean check, ∈ / ∉ for membership, and n/a where the check does not apply — followed by a mark taken from the engine's status: ✓ when the relation holds, ✗ when it fails, ? when it is not established. A failed check therefore reads 40 /s ≤ 25 /s ✗, never as a true assertion. Each row also carries its constraint id (engine.check) and its scope — per node for the checks Hardware Match composes on one candidate node (thermal, power, stream capacity, JetPack, carrier, Frigate, drives), per stage for a pipeline stage's checks, deployment for the PoE switch, pipeline for this engine's own composition rows. Only rows with an identical owner, check, scope, required, available and status collapse into one line with a ×N badge; a node-level check and the same check re-asserted for a stage stay separate. Above the table, four things the verdict badge used to blend are stated one by one: the winner's feasibility (Hardware Match's verdict), its recommendation admission (eligible, planning-only, insufficient evidence), the search coverage (scoped or exhaustive, candidates evaluated, open questions) and the confidence label. No number or status changes in the engine for any of this; it is display only.

10. What invalidates a result

• A new benchmark row. Throughput here is the pessimistic edge of the rows that resolve for each model on this platform. One new measured row can move a stage's available fps, its utilization, its evidence class and therefore the platform ranking underneath the whole architecture.
• A firmware or JetPack change. A different JetPack, runtime or power mode changes what the configuration checker asserts, what throughput the benchmark rows apply to, and in some cases whether the configuration is supported at all. An architecture designed against one release is not evidence about another.
• A different fan-out. The detections-per-frame figure multiplies straight into every downstream stage's required throughput. If your scenes carry four objects where the result assumed one, the downstream stage needs four times the rate and the composition changes completely.
• A measurement that contradicts the sharing assumption. This is the one that matters most. The moment somebody measures two models running concurrently on this silicon, the summed utilization on this page is either confirmed or falsified — and if it is falsified, every multi-stage verdict computed from it moves. Until then the cap at NEEDS VALIDATION is the honest reading, and the measurement protocol is how you close it.
• Anything the sub-engines' own caveats cover. Software versions, thermal state, input resolution, batch size, the multi-stream efficiency curve, and the fact that every benchmark row is inference-only.
• The class E rollups. Network, storage, system power and the non-compute bill of materials are heuristics, not sourced figures. Do not put them in a purchase order without checking them against the vendor quotes.

11. Method changelog

Method changes bump the method version; the composite dataset version follows the newest of the registries the sub-engines read, and every result also carries the per-engine versions in sub_engines, with a legacy flag on the four rollup engines.