Full Deployment Planner — methodology

Method version 1.4 · 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.

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 and budget_sensitivity 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 power, bitrate and storage totals, the priced BOM lines with their gaps, the overall confidence, the inputs it did not evaluate, the planning ambient, and the Hardware Match goal with its weight table. 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.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.