Full Deployment Planner — methodology

Method version 1.6.2 · engine: /engines/full-deployment-planner/ · reads one Architecture Designer result and the planner's own class E planning tables.

A view, not a second designer. The platform, node count, camera split and verdict are the Architecture Designer's, copied without change; this page describes only what the planner adds on top.

Purpose, successors and transition status
Inputs and how they reach the Architecture Designer
What is copied, and what is added
The business-case arithmetic
Evidence limitations
Method changelog

1. Purpose, successors and transition status

The Full Deployment Planner answers POST /api/v1/full-deployment-planner: the production and bill-of-materials view of a camera deployment. It runs the Architecture Designer once and presents its answer with the production extras a buyer asks for — installation, extra sensors, a compliance checklist, certification pathways and a business case.

Successors. The architecture question (which platform, how many nodes, which models, does it fit) is owned by the Architecture Designer; hardware pricing and cost of ownership by Deployment Cost & TCO, whose priced lines the planner's BOM carries. The planner re-decides neither.

Transition status. Live. It is the Production / BOM view over the Architecture Designer's result; its own additions are planning tables (class E) and are labelled so on every line.

2. Inputs and how they reach the Architecture Designer

Input	Accepted	What it does
`scenario`	retail, industrial, traffic, security, robotics, agriculture	Sets the compliance checklist, the default certification pathways and the ROI benchmark. Passed to the designer as its use case, where it is a label and changes nothing in the architecture.
`cameras`	integer (the designer accepts 1–256)	The load.
`resolution`	480p, 720p, 1080p, 4k	The stream size.
`model`	classification, detection, segmentation, pose, multi	The designer's task (each with its own default model family).
`budget_sensitivity` (the Optimize tile)	low, moderate (default), high	A ranking goal, not a filter: low → cost, moderate → balanced, high → headroom. It selects the weight table Hardware Match ranks the platforms with, and changes the platform only where the goals disagree. The result states it in `optimization`.
`power_infra`	mains, poe (battery and ups are accepted and listed as not evaluated)	The designer's power source.
`retention`	days, 1–365	Recording retention.
`environment`	indoor_controlled, indoor_industrial, outdoor_sheltered, outdoor_exposed, mobile	The designer derives a planning ambient from it (25, 35, 40, 50 or 55 °C, class E) for the thermal checks.
`fps`	optional; default 15	Camera frame rate.
`precision`	optional: int8, fp16, fp32	The inference precision. Absent, the designer applies the task’s planning default — FP16 for segmentation and pose, INT8 for every other task — and the plan states it in `precision` as a default (DERIVED for a task-specific default, DEFAULTED otherwise), never as your choice. Named, it is used as named (PROVIDED).

The planner adds two planning constants to the designer request — 24 recording hours a day and an energy rate of 0.13 USD/kWh (a US average retail planning figure) — and invents no other default. Absent fps, budget_sensitivity and precision are recorded in defaulted.

3. What is copied, and what is added

Copied verbatim from the Architecture Designer: platform, node count, per-node camera split, verdict and hardware verdict, primary bottleneck, risks, verdict drivers, the evidence gap that decided the platform (platform_evidence_gap, informational), the power, bitrate and storage totals, the shared recording pool with its RAID level, whether that level was defaulted and the drive failures it survives, the priced BOM lines with their gaps, the overall confidence, the inputs it did not evaluate, the planning ambient, the precision it sized at (precision), and the Hardware Match goal with its weight table. A verdict worse than FIT names the rows that produced it: at least one verdict driver whose status explains it (NEAR LIMIT or a material risk for FIT WITH RISKS, UNKNOWN or REQUIRES VALIDATION for NEEDS VALIDATION, a failed row for NO FIT), rendered under “Why this verdict”. When the designer finds no platform, the planner answers the same refusal (HTTP 200, verdict NO FIT, the planning-only candidates and the questions).

Added by the planner (class E planning tables): installation and commissioning at 20 % of the hardware subtotal; optional thermal-camera, radar, LiDAR and audio-array lines at fixed planning prices (not sized into the architecture); certification pathways with planning cost and duration (not added to the project total); an EU AI Act prohibited-use check; a compliance checklist by scenario; a scale tier by camera count (1–4, 5–16, 17–64, 65+); a topology tier (up to 8 cameras single node, up to 50 two-tier, above that three-tier); and a monitoring configuration.

4. The business-case arithmetic

total_project_cost = sum of the priced BOM lines (hardware + installation + sensor lines) cloud_alternative_annual = cloud_price_per_camera_month × cameras × 12 edge_vs_cloud_savings_3yr = 3 × cloud_alternative_annual − total_project_cost monthly_savings = cloud_price_per_camera_month × cameras − annual_energy_cost ÷ 12 breakeven_months = ceil(total_project_cost ÷ monthly_savings) (only when monthly_savings > 0) tco_3yr = total_project_cost financed_total = total_project_cost × financing multiplier (capex 1.00 · operating lease 1.15 · finance lease 1.22 · camera-as-a-service 1.85) replacement_events = ceil(node_count × lifetime_years × 0.05) risk_adjusted_cost = total_project_cost + replacement_events × unit_cost

tco_3yr is the project cost, not a three-year operating model: energy and replacements are shown beside it, not inside it. The cloud comparison uses list prices per camera per month (123, 131 or 95 USD for the three providers on record); ROI and payback figures are published case-study benchmarks for the vertical, not a model of this deployment. For a cost of ownership over a horizon with energy, use Deployment Cost & TCO.

5. Evidence limitations

Every line the planner adds (installation, sensors, certifications, financing) is class E and says so; the architecture, rollups and priced hardware lines carry the evidence class their owners gave them.
Cloud prices are list prices at the time they were recorded; ROI and payback are case-study figures for the vertical.
Extra sensors are priced but not sized into the architecture: their bandwidth, compute and power are not in the design.
Battery and UPS power are not modelled; they are listed under not_evaluated.

6. Method changelog

Method	Date	Change
1.6.2	2026-09-30	The Designer's per-node drive rows in a shared-recording design are Drive Endurance's `buffer_capacity` (a one-day buffer), no longer a second meaning of `capacity` (#260). Verdicts unchanged.
1.6.1	2026-09-29	The page always names a task (Detection, Classification, Segmentation, Pose), so this was unreachable from it; a direct API caller who sends `pipeline_stages` with no `model` — forwarded verbatim to the Architecture Designer, which now sizes that single stage’s own task (bug #268, duplicate #272, method 1.22.0) — previously read its output `precision` block as DEFAULTED with no task, rule or basis although the design itself was correctly sized (e.g. FP16 for a lone segmentation stage); the block now states the stage’s own DERIVED record, exactly as a Segmentation tile’s does.
1.6.0	2026-09-29	The Production view carries the designer's elimination authority (#263, owner ruling 2026-09-29): each verdict driver that names a row carries its `elimination_authority`, and the verdict follows the designer's — a miss on planning-only evidence is NEEDS VALIDATION, never NO FIT.
1.5.0	2026-09-29	Segmentation and pose default to FP16 (owner ruling of 2026-09-29), through the designer (1.20.0): the segmentation and pose tiles were sized at INT8, where no YOLO11-seg or YOLO11-pose row exists on any Orin, and every one refused; they now design at FP16. New optional input `precision` (int8, fp16, fp32 — the page’s Precision row), forwarded only when named; new output `precision` stating the value the designer sized at and whether it was your choice (PROVIDED) or the task’s default (DERIVED / DEFAULTED); an absent precision is listed in `defaulted`.
1.4.2	2026-09-29	The recording pool states its RAID level (bug #259): `recording_pool` publishes `raid_level`, `raid_level_input_state` and `drive_failures_tolerated` from the designer's pool, which is Drive Endurance's redundancy-aware planning default unless a level was stated, so the planning assumption behind the pool's usable capacity is visible here too. The pool itself, its bill-of-materials lines and every figure are the designer's, unchanged. A design whose recording pool no registry host holds is NO FIT here as it is in the designer (the detection tile at 25 × 4K, 151 days read NEEDS VALIDATION with a failing pool row as its driver).
1.4.1	2026-09-28	The view carries why its verdict is what it is (bug #253): the designer (1.18.0) now names every owner row that produced a verdict worse than FIT, so the detection tile at 720p × 1 and × 8 cameras, which read FIT WITH RISKS with no driver, names Hardware Match’s drive-capacity row under “Why this verdict”. The designer’s `platform_evidence_gap` is carried and shown as “Evidence gap”: a planning-only board Hardware Match ranks above the winner, kept out only by missing evidence (why a lighter task can land on a weaker board). It changes neither the platform nor the verdict.
1.4	2026-09-28	The Optimize tile is stated (bug #239): `optimization` names the budget sensitivity, the Hardware Match goal it sets and that goal's weight table, as a ranking goal and never a filter. It was applied but invisible, so at a load where every goal picks the same platform the tile looked dead; at 8 cameras × 4K the goals pick different platforms. The designer's informational use-case entry is not carried, because the planner's scenario does drive the compliance checklist, certifications and ROI.
1.3.1	2026-09-28	Input rules (WP-01 remainder, WP-02): every schema input is checked on the shared rule — a stated but invalid value, including an empty string, is a 400 naming the field — and an unknown key is a 400 naming the key; 480p is an accepted resolution (the page's first tile).
1.3	2026-09-28	The environment sets a class E planning ambient for the thermal checks (an explicit ambient overrides it); battery and UPS power are not evaluated and the page no longer offers them; a business NO FIT is an HTTP 200 answer with the refusal reason, planning-only candidates and questions (it was an error envelope); the model preference selects the variant; segmentation and pose default to their own model families.
1.2.1	2026-09-28	Present-invalid inputs are rejected (WP-01): a camera count that is not an integer is a 400 naming the field; an absent frame rate or budget sensitivity is recorded in `defaulted`.
1.2	2026-09-27	The stage task and power mode are forwarded to the designer end to end, and the designer's verdict drivers are published.
1.1	2026-09-27	The shared-recording pool rows are carried from the designer, and a refusal shows the designer's best planning candidate and its reason instead of a generic message.

Method changes bump the method version; results carry it in provenance.method_version with the dataset version of the registries the designer reads.