# ADR 0022 — Operator surface ownership

Status: accepted, 2026-07-26

## Context

The first simulation and LiDAR qualification slices exposed implementation
results where they were produced. Saved observation sessions lived in the live
spatial workspace, public datasets lived under Polygon, and the local-surface
laboratory result was labelled as device diagnostics. This made the operator
infer backend history instead of following product concepts.

The same ambiguity affected Centre: separate overview, health and activity
pages repeated static capability inventories instead of showing the current
compute and network contour.

## Decision

Mission Core assigns one owner to each operator concept:

| Product area | Owns | Does not own |
| --- | --- | --- |
| **Наблюдение** | Current live sensor scene and live-only spatial controls | Saved-session selection or offline experiments |
| **Данные** | Saved sessions, replay, public datasets, streams, entities and export | Simulation execution or laboratory conclusions |
| **Тестировочный контур** | Versioned laboratory work, test configuration and visual evidence | Source-of-record retention or public dataset storage |
| **Центр → Состояние контура** | Live compute nodes, processes, network reachability and connected devices | Static feature inventory or a separate activity page |
| **Система** | Deeper module, integration, network, audit and configuration administration | Daily operational health summary |
| **Парк** | Devices, sensors and live device operation | Offline algorithm-development reports |

The existing internal root id `polygon` remains stable for compatibility, but
its operator label is **Тестировочный контур** and it is last in the header.
Legacy `?workspace=polygon-datasets` and `?workspace=polygon-run` links resolve
to **Данные → Датасеты**. They do not recreate the previous Polygon dataset
page.

Saved session replay is mounted only in **Данные → Сессии и записи** or from a
selected recorded LAB work. **Данные → Сессии и записи** keeps the original
compact dropdown in the panel header and one full-size spatial viewer; it does
not expand the catalog into the content column. Leaving either archive returns
**Наблюдение → Пространственная
сцена** to the runtime-published live source. A selected archive cannot leak
into the live observation surface.

Dataset sources use a single-open accordion. Expanding one source mounts its
viewer and analysis inside that source card, pushes later sources down, and
closes the previously expanded source.

The laboratory surface is a two-level catalog:

1. a **laboratory contour profile** fixes the tested rig, modules and worker;
2. a **laboratory work** selects one immutable result inside that profile.

The selected work opens one reusable output structure: task and configuration,
full-size visual evidence, then structured metrics, errors, timing and
conclusion. LAB E28 owns the L2.6 local-surface viewer, complete-recording
timeline and review queue. LAB E29 owns the camera-first semantic/geometry
coverage result. Recorded E19–E26 LAB instances are exposed through a separate
published-perception profile backed by the existing observation-session
catalog. They are not rendered as a second saved-session archive.

Neither E28 nor E29 is live device diagnostics. A future device-diagnostics
workspace must require an attached device and its own diagnostic contract.

Contour health reads only live contracts:

- `GET /api/health`;
- `GET /api/v1/device-plugin-runtimes`;
- `GET /api/v1/polygon/worker`;
- current Mission Runtime state for active device and perception metrics.

Unknown or unavailable values remain empty/offline. The UI does not invent
load, latency, activity or connected devices.

## Consequences

- Public datasets and private sensor records are both discoverable under Data,
  but remain separate evidence classes.
- Laboratory evidence is inspectable without confusing it with live device
  health or closed-loop simulation.
- The current Simulation Worker may be offline while its prior laboratory
  evidence remains available.
- The generic Control Station remains device-neutral; device names and
  implementation details come from plugin/runtime contracts.
- New operator pages must declare one product owner before implementation.