# ADR 0050 — Recorded Observatory first; portable profiles then onboard

Date: 2026-09-02. Decision accepted by the owner; implementation in progress.
This supersedes ADR 0049's realtime-first product gate and execution order,
not its live-stream integrity, ownership or safety contracts.

## Decision

The primary operator workflow is a complete calculation of a compatible K1
recording with a selected immutable profile, followed by publication and cached
review. Processing may be slower than acquisition. Network latency is evidence,
not a prerequisite for using the laboratory. After this workflow works, compare
Docker configurations; later qualify the selected configuration on actual
onboard hardware. No vehicle or remote-realtime acceptance is claimed now.

Keep the existing source admission, queue, artifact store, publication recovery,
streaming runtime and common viewer. Do not introduce another per-LAB application.
One Worker executes one active profile; alternative profiles remain sequential.
M4.9T5 currently supplies CPU TGS; LAB V1 supplies sequential EoMT/DDRNet, not the
complete future detector/distance/motion/TGS/policy profile.

## Recorded analysis versus realtime rehearsal

Recorded analysis preserves source timestamps and causal ordering, uses bounded
backpressure, and accounts for every required scheduled input/result. Its elapsed
wall time need not match the source clock. Source sensor gaps remain unknown.
Do not disguise live drop/resync as a complete recorded result. Introducing this
execution mode requires an explicit versioned contract, not silently weakening
the existing 1× live freshness, deadline or ownership gates.

Realtime rehearsal remains an independent qualification. Historical network
canaries retain their original FAIL results and thresholds. Neither cached video
playback FPS nor end-to-end upload/export time is a Worker compute benchmark.
Measure preparation, warmup, processing, delivery and publication separately;
onboard estimates are conditional on matching hardware and effective config.

## Result identity and UI

Only compatible, not-yet-calculated current profile versions belong in the
calculation selector. Published results of every version remain below as evidence.
All calculated means no Calculate action, an empty/disabled selector, and Refresh.
Refresh, source selection and cached review must never start inference.

Reuse requires the exact admitted source fingerprint and immutable definition
(including model, image, configuration, adapter and result-contract identities).
An old LAB name, a legacy overlay, or compute success without publication is not
a matching cache. Missing/corrupt artifacts must not suppress a valid retry.
Publication failure retries publication, not computation, while the sealed package
is recoverable. Changed profile versions become new calculations.

## First implementation increment

Portable queue admission now opts into an atomic duplicate-computation guard.
It uses the existing job identity, not a second cache key ontology, and rejects a
different request while the identical job is active, requires reconciliation, or
has a sealed result pending/failed publication. The check and INSERT use one SQLite
transaction. Exact retries retain the original idempotency semantics. A genuinely
failed compute can be retried with a new request key. Legacy queue callers retain
their existing policy; no schema migration or Worker/image change is introduced.

Published-cache verification, catalog projection, selector changes, progress and
complete recorded-analysis execution are still pending. This increment does not
mark stage 1 or the full workflow complete. Tests cover concurrent admission,
durability, changed source/profile, failure retry and HTTP 409 duplicate handling.

## Boundaries

No Synology deployment, hardware actuation, motor integration, new capture,
silent model substitutions or deletion of recordings/results. A Docker image's
portability does not promise that a CUDA build runs unchanged on Apple Silicon.
Physical-live and onboard/vehicle acceptance require the actual target hardware.

The only maintained execution plan is
[the four-stage ExecPlan](../OBSERVATORY_REALTIME_PROFILES_EXECPLAN.md).