docs(observatory): prioritize recorded laboratories and cached review before onboard profiles

2026-09-02 23:16:01 +03:00
parent 35c1249631
commit 049ed3eed4
3 changed files with 187 additions and 1 deletions
@@ -0,0 +1,74 @@
+# 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).