Two-Cell Planning Walkthrough

Can changing only two planning Cells' azimuths serve more modeled demand without excessive duplicate service? This walkthrough records a baseline, a recommendation and an alternative with less overlap in a small Ankara area. It uses public planning inputs; measured real-world RF accuracy remains unestablished, and the result does not approve a deployment.

Exact inputs and scope

Use a complete Git LFS checkout and the default ankara-open-planning@2026.07 pack from Getting Started. Download the separate two-Cell walkthrough project using the link's Save link as action, or use the file in your checkout. The legacy first-use sample remains an input-only example; its first-run UI selects nearby Cells dynamically and is not this fixed comparison.

The walkthrough project contains two selected records and their complete planning RF profiles, dataset ID/version/hashes and priorities. It intentionally contains no computed results: import it and evaluate on the matching runtime.

These are OpenCellID-derived planning records, not verified physical sites or operator-authoritative RF identities. Coordinates identify the existing public pack records, not a new measurement campaign. Demand attributes are heuristic planning weights, not measured traffic or population.

The recorded run used A.T.O.M 0.13.0, source fc0f1e489110bbd30277c3454e4db95e0ca302d6, Go 1.26.10 on macOS arm64, and model/version urban_short_range. Exact hashes and the complete canonical request are in the recorded evidence. Buildings SHA-256 is d952a853b1146fe4e4136c2d8bac1b8e2c7152b33d78b0d9f82399350bfd50fc; Cells SHA-256 is c460c254d8748df52305d141b2f5e5147757a00b9d0581d8670084aa29ee3bd8.

Keep these settings fixed throughout:

The fixture also freezes load 70%, reuse 1, channel CH-1, noise figure 7 dB and sample spacing 40 m. Radio quality is disabled in this optimization, so no SINR or throughput conclusion follows from those settings. Only azimuth changes; power, locations, heights, frequency and patterns remain fixed. The default bounded search and retained Pareto frontier do not prove a global optimum.

Evaluate and preserve the baseline

1. Open the app at http://localhost:8080 (Docker) or http://localhost:5173 (Go + Vite). In the project menu, choose Import and select ankara-two-cell-walkthrough.atom-project.json. Import creates a separate project.
2. Check Network mode with 2 selected. In Inventory, confirm the two records and their fixed per-Cell profiles. Do not replace them by drawing an area or opening the dynamic first-run sample.
3. In Data, confirm the dataset/version and model. Stop if the project shows Dataset differs from this project. Replacing a pack or accepting a different model makes the numeric example inapplicable.
4. Select Evaluate Network. Wait for Ready, then open Results. Record the baseline row below. The map rays show propagation; served buildings and overlap have their own populations and are not ray blockage percentages.
5. Choose Save Version to preserve the evaluated baseline. In Plan → Scenarios, give it a readable baseline name. Keep it available for comparison before changing the plan.

Optimize and inspect the trade-off

1. Open Simulate → Propagation → Advanced analysis, check the five Optimization priorities above, and choose Optimize Network. This runs RF; changing priorities later only reranks the retained alternatives until you explicitly search again.
2. In Results → Optimization, choose View comparison to inspect Baseline vs Recommended. The recommended azimuths are 240° / 130° in API Cell order 26380 / 26381. Optimization loads these into the working draft; verify them before saving.
3. Open Results → Solutions and inspect the alternative 240° / 110°, using Show all if necessary. Choose its point or row to inspect it; inspection alone does not apply it. Use the explicit apply action only if you want that plan in the draft.
4. Compare all three on the same domain and priorities:

The recommendation gains 190 demand-weight units and 171 residential buildings, while removing 105 overlapping buildings, relative to the baseline. Its score increases 41.3959 points; that score is a weighted planning utility, not a coverage percentage or confidence level.

The zero-overlap alternative keeps all 305 demand-weight units but gives up 11 residential buildings and about 410.66 normalized reach-score units relative to the recommendation. It illustrates why the highest weighted score and minimum overlap need not select the same plan. The domain contains 601 relevant residential buildings; neither result means all homes or all outdoor locations are covered. Propagation reach is distance-normalized: each ray contributes up to 100 score units, capped at the lesser of its radius and 500 m. It is not metres, geographic area, user coverage or a path length between the Cells.

Save the chosen plan and export review evidence

1. Choose the recommendation or explicitly apply the inspected alternative. Keep the baseline Version for comparison. Run Evaluate Network for the chosen current azimuths so the retained execution matches the exact plan you are saving, then choose Save Version. Read any stale/history notice before using a result.
2. Use Results → Compare to select the baseline and chosen saved evidence. Confirm matching dataset and model identity before interpreting deltas. A changed radius, frequency or priority is a different comparison.
3. Open the project menu and choose Export. Keep the .atom-project.json outside browser storage. Import it in a separate browser profile and confirm both preserved inputs/Versions. Imported IDs are remapped; provenance records the source identity. Historical results can remain readable without being a new live run, and some map layers require an explicit rerun.
4. In Review → Report, choose Markdown to generate and download a report from the chosen saved Version, or use PDF / Print and save the print output. These files are separate from project export. Choose Review package for a local ZIP containing both HTML and Markdown reports, the project and manifest. See the report reader guide for lineage and A4 print settings.
5. A reviewer should receive the editable project plus a readable report/review package. Check the project/scenario/Version and any source Run, dataset/model, UTC timestamp, complete RF settings and the unestablished-accuracy boundary. A project file does not include the separate Run History database, generated report store or coverage surfaces.

Reproduce the recorded API comparison

With the Go API already running on the matching pack, run from the repository root using Node 24 or newer:

node scripts/reproduce-planning-walkthrough.mjs http://localhost:8080 /tmp/atom-walkthrough-evidence

The script uses the same project importer and request builder as the frontend. It checks dataset hashes and model version, sends two sequential RF requests (Evaluate and Optimize), checks the recorded fingerprint and comparison, and writes request.json, meta.json, baseline.json, optimization.json and summary.json into the output directory. The recorded scenario fingerprint is network-6fe95eaddbb92e9ba9a3bf0fa5384544. These JSON files are execution evidence, not importable portable projects or UI reports.

No request is automatically retried. If the API is busy (429), wait for its Retry-After before rerunning. A changed dataset, model, fixture or result fails the comparison; keep the output and investigate instead of silently replacing the recorded values. This command verifies the API calculation; the UI steps above separately exercise preservation and reporting.