# NoMAC: two modes and one trajectory workflow

Implemented 24 September 2026. The new interface is a model integration, not validation against real traffic or a claim that every product requirement is finished.

## Mode selection

- **Trajectory based** (`index.html`): Scenario → Simulation → Results. Generated traffic and drawn U-plans enter the same persistent, continuous world. DCB, sensing, DAA, disturbances, restrictions and outcome evaluation use that world. A single run, independent batches and capacity studies share the same engine.
- **Sample based** (`research.html`): the existing independent Dn snapshots, geofence mass redistribution, A/n classification, route checks, manual inspection and saved comparisons. Its A/n classification rule is preserved; engine 2 corrects polygon sampling and disk area, and reports spatial metrics per snapshot. A/n observations are not imported as trajectory NMAC events.

The mode selector preserves each mode's compact declarative configuration in session storage before switching (the expanded route graph is rebuilt on import). Explicit JSON export is the durable copy. Each mode has its own inputs and metrics. The former separate DAA experiment and Traffic & capacity pages are no longer product tabs; their reference engines remain available for tests and CLI use.

## Daily mixed traffic (current trajectory workflow)

See [DAILY_TRAFFIC.md](DAILY_TRAFFIC.md) for the current demand, profile, time and KPI contract. Each terminal specifies expected deliveries/day, operating hours and aircraft/DAA profiles; optional background transit has its own demand and profiles. Explicit U-plans join the same world. Population B weights delivery destinations. Dn is not used to fit or generate the daily traffic, and its comparison overlay is hidden for these scenarios.

A replicate covers a complete scenario day plus a finish period. The Scenario page chooses one day, repeated days/actual-flight-hour targets, or capacity levels. Simulation renders one selectable hour of one actual replicate. Opening a replay retains the entire study's Results and exported artifact. The first replicate is available without selecting an unusually eventful day. Results include mean/peak airborne aircraft and a per-source accounting table.

See [DELIVERY_MODEL.md](DELIVERY_MODEL.md) for round-trip geometry. Additional sensor/aircraft profiles share the reference CA controller; they do not represent independently validated supplier algorithms.

## Legacy geographic traffic and Dn

The bundled Norrköping Dn GeoJSON is a relative spatial input, with no verified aircraft-traffic provenance. Its nonnegative weights are normalized within the operating bounds and aggregated into a 6 × 5 grid using the source cell centres. The 39,121 source cells are **not** treated as observed trajectories.

The initial route assumption is a synthetic bidirectional grid joining the 30 analysis-cell centres. This is not the street network, an inferred OD matrix or LFV-approved corridors. Altitude, cruise speed, capacities, headway and kinematics are separate inputs. The generated fleet has one common reference profile; explicit U-plans retain their own speed and altitude. Missions describe the airborne route: takeoff from the ground and landing phases are not modelled.

A fixed, seeded library of up to 160 distinct OD pairs is independent of the simulation seed and added geofences. For each baseline route, the ordinary trajectory engine constructs acceleration/coast/braking segments and waypoint yaw waits. Exact grid-boundary intersections integrate aircraft-time in each cell.

For route j, let Tj be its airborne duration and cij its fraction of airborne time in cell i. The fit estimates nonnegative aircraft-time mixture weights qj, summing to one, so that predicted occupancy pi = Σj qj cij approaches normalized Dn di. Multiplicative mixture fitting uses 240 iterations and 0.5% uniform mixture regularization. It is a constrained approximation, not an exact inverse of Dn.

**Departure weights are qj/Tj, normalized to sum to one.** Using qj directly as flight probabilities would overrepresent longer flights. Expected unconstrained flight duration is Σj wj Tj; expected airborne count at stationary rate λ is λ E[T]/3600. This is an analytical baseline, not the observed number during empty startup.

The UI reports total-variation mismatch: ½ Σi |pi − di|. Zero is an exact coarse-grid match; one is complete disjointness. This is not collision probability. A measured default fit currently has approximately 13.2% mismatch. It makes no accuracy claim below the coarse cell size. The same colour scale compares target, unconstrained baseline and executed occupancy.

The baseline fit excludes DCB, DAA, restrictions, disturbances and explicit U-plans. Realized occupancy includes all actual airborne trajectories. Baseline-versus-realized differences can result from restrictions, queues, rejections, maneuvers, fixed U-plans and finite-sample variability. They are not silently fitted away.

## Planning and the shared world

Daily delivery demand uses per-terminal expected counts and population weights as described in DAILY_TRAFFIC.md. Older short delivery projects use relative terminal shares. The following calibrated-OD description applies to legacy projects.

Poisson departures choose calibrated OD pairs; drawn U-plans are appended with their actual departure times and prescribed waypoint routes. Both participate in the same ordered reservation queue and continuous contact/separation evaluation. U-plans are additional demand, not a replacement for generated flights. Set generated departures/hour to zero for only prescribed U-plans.

With DCB enabled, generated routes use shortest eligible paths through the declared network, excluding edges obstructed by static restrictions or solids. Timed reservations then enforce headway, protective separation and actual corridor/layer capacities. Dynamic restrictions use the existing announcement/replanning logic. A prescribed U-plan is retained, delayed or rejected; the scheduler does not invent an undeclared alternative route for it. Without DCB, the same route network is used without strategic avoidance of restrictions or conflicts.

The geographic route policy checks the shortest available route per layer. It does not exhaustively search longer routes to escape congestion. Explicit limits, rejections and unsupported coordination are reported; a failed search is not silently converted into safe capacity.

Geofences affect real routing/replanning in trajectory mode. **Dn mass is not additionally moved to fence boundaries.** The unchanged redistribution algorithm remains exclusive to sample mode.

Physical contact, protective-volume conflicts and NMAC thresholds remain distinct. NMAC counts continuous pair proximity intervals under configurable horizontal and vertical thresholds. Physical collisions use body spheres. Rates divide events by summed actual airborne flight hours, including prescribed intruders if present. See `TRAFFIC_MODEL.md` and `TRAJECTORY_MODEL.md` for the underlying controller and geometry contracts.

## Time, altitude and 3D inspection

A run starts empty at time zero. Requests arrive during the demand period; the drain period allows admitted flights to finish. There is no claimed warm-up or steady-state estimate. Completed flights per demand hour describes that finite cohort. Censored/unfinished flights remain in results.

Coordinates use the same local equirectangular metres projection as the map editor. Heights are AGL above an explicitly flat reference surface. Cesium positions map those coordinates onto the geographic globe for display; satellite imagery is background context. Real terrain, buildings and vertical-datum conversion are not part of the physical model.

The vendored CesiumJS 1.127.0 renderer evaluates the recorded piecewise constant-acceleration paths at the selected time. It does not rerun physics per display frame or linearly interpolate five-minute samples. Play, pause, scrub, click/select aircraft and focus all use one time value. Dashed routes show plans; teal shows complete executed routes. The translucent sphere around each airborne aircraft is a **radius guide** with radius r (including any speed expansion), not the nominal collision/protection geometry. On selection the amber cylinder shows the actual protective radius and vertical half-height. During a contingency the sphere instead represents the actual enlarged protective volume and the cylinder is hidden. White aircraft markers have a fixed screen size; the selected physical body is also rendered at its model radius. Amber markers show last received sensor measurements from the previous ten seconds, not future truth. Inspection logs are bounded at 200,000 delivered observations; the result records truncation. Physics is unaffected by logging.

Selecting an aircraft pauses replay, moves to its departure if it is not currently airborne, and centres a close orbit on it. Drag rotates, scroll/pinch or +/− zooms, right-drag/Shift-drag pans. Arrow keys rotate the focused canvas, +/− zoom and Home fits the area. The orbit follows the selected aircraft when replay resumes or the timeline changes; pan or Fit area releases that follow. The minimum camera range is 2 m, and the camera stays above the reference ground.

For legacy Dn-calibrated projects, the 3D Dn overlay uses the original 39,121 source cells rasterized to a geographically aligned 2048-pixel-wide texture, independently of the 6 × 5 calibration grid. It uses the same colour ramp and 0.42 intensity exponent as the Scenario map, saturating the colour scale at the 98.5th percentile. These are display choices and never modify Dn weights or results. Original cell boundaries can still be visible at very close zoom. A mismatched imported Dn target disables the source overlay rather than mislabelling the bundled data.

WebGL failure produces an explicitly labelled selectable 2D fallback. Imagery requires network access; the simulator and locally bundled 3D assets do not require a Cesium ion token or service. Attribution stays visible. `vendor/cesium/LICENSE.md` contains the library licence.

## Large studies and replay

Browser runs use a worker. Batches keep bounded aggregates: actual exposure, counts, exact mean delay, a one-second upper-bin approximation for p95 delay, occupancy totals, and up to 12 reproducible run seeds ranked by observed events. They do not retain every flight path from every replicate. A retained seed reruns the exact same scenario in the same engine for 3D inspection.

Browser Stop retains completed batch replicates; exported partial batches can be resumed. Individual simulation runs are atomic: an interrupted run contributes no partial exposure. Capacity studies retain per-level replicate summaries and fresh-seed confirmation, separate from fixed-scenario batches.

The CLI supports parallel independent workers, deterministic merge order, bounded in-flight jobs, and an atomically updated checkpoint after each merged run:

```sh
node scripts/mission.cjs --project my-scenario.json --runs 100 --workers 4 --max-seconds 600 --output batch.json
node scripts/mission.cjs --resume batch.json --workers 4 --max-seconds 600 --output continued.json
node scripts/mission.cjs --project my-scenario.json --target-hours 10000000 --workers 4 --max-seconds 3600 --output long-study.json
node scripts/mission.cjs --project my-scenario.json --single --output inspectable-run.json
```

Without `--runs` or `--target-hours`, a project exported as a batch uses its saved run length (otherwise 20 days). Without `--max-seconds` there is no time limit. Output filenames must be new. A time limit or interrupt writes a partial result and never claims the requested flight hours were achieved. A flight-hour target also has an explicit replicate ceiling. Selected event replays are inspection examples, not an unbiased sample for estimating rates.

The zero-contact bound −ln(0.05)/H remains a separately labelled diagnostic conditional on a Poisson collision process. No amount of model execution independently validates the model. The ten-million-hour requirement has **not** been demonstrated with this geographic engine. Full-day scenarios can be substantially more expensive than the old short cohort. Large-scale feasibility still needs performance work and a measured acceptance run; current per-replicate flight/event limits fail explicitly instead of discarding traffic.

## Requirement relationship and remaining scope

This integration connects the existing work toward REQ-1.1–1.4, 2.1, 2.4–2.5, 2.7–2.8, 2.11, 3.2–3.3, 3.6–3.7 and 4.1–4.5 plus geofence priority. It does not mark those requirements scientifically accepted or universally complete.

Still open: empirical/approved demand and corridor data, real landing sites and ground turnaround; temporal/altitude demand calibration; nonempty warm-up and steady-state studies; real terrain/altitude conversions and multiple areas; fixed-wing motion; vertical sensor FoV; supplier-calibrated CA behavior; full multi-aircraft coordination; RTTA; noise/visual impact; CS25-specific safety evidence; and the full large-exposure acceptance run. These are model-development tasks, not additional switches that make the current assumptions valid.

## Verification

Automated tests exercise exact accelerated occupancy integration, duration-corrected route fitting, fixed baseline under added restrictions, actual detours, combined generated and prescribed demand, inspection-independent physics, checkpoint/resume, and parallel-worker reproducibility. Existing continuous-engine and sample-engine tests are retained. Chrome integration checks cover both modes, the real worker, 3D rendering and its 2D fallback, geometry import, trajectory replay parity, batches, and desktop/mobile layouts.

### Sensor coverage in replay

The selected aircraft has a purple range envelope and horizontal FoV sector. Orientation uses the engine’s shared `sensorHeading` rule, including heading at rest; replay uses the intention known at the selected time. The range is spherical in 3D, clipped by horizontal bearing; no vertical FoV parameter is invented. A 360° sensor therefore shows the full range sphere. The horizontal slice and heading arrow aid inspection. Coverage is independent of the radius-guide toggle, and is hidden for inactive/disabled sensors or contingency suspension. Inspector values come from the recorded per-aircraft sensor profile. Coverage is possible visibility, not a claim that Pd = 1.