SILVER/NODEDC_MISSION_CORE
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

feat(observatory): add portable LAB V1 foundation

Browse Source
This commit is contained in:
DCCONSTRUCTIONS
2026-08-31 11:02:34 +03:00
parent d67e86176e
commit c9302c78c2
27 changed files with 7629 additions and 266 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/15_LABORATORY_RUN_CANON.md
+31 -15
View File
@@ -300,16 +300,29 @@ branches rather than hidden retries. The durable queue serializes one recorded
compute owner and does not equate a queued receipt with a Worker execution
receipt.
The only currently queueable pair is the exact `RAVNOVES00` source and
`M4.9T5 · TRAVEL TGS · CPU-only, без ML` RunDefinition. It seals an explicitly
empty learned-model list because TGS is an algorithmic CPU pipeline, not an
unknown model dependency. The binding pins the exact source pack rather than a
volatile whole-catalog digest; the server captures and seals the current catalog
snapshot into each admitted job. `LAB V1 · EoMT Cityscapes Large 1024 + DDRNet-39`
remains a result-only replay: no independently versioned durable executor exists
for that published result, so Mission Core does not invent one. Every other
session/setup pair fails closed until its own source adapter, capability manifest,
RunDefinition and executor identities are admitted.
The only pair currently admitted to the durable queue is the exact `RAVNOVES00`
source and `M4.9T5 · TRAVEL TGS · CPU-only, без ML` RunDefinition. It seals an
explicitly empty learned-model list because TGS is an algorithmic CPU pipeline,
not an unknown model dependency. The binding pins the exact source pack rather
than a volatile whole-catalog digest; the server captures and seals the current
catalog snapshot into each admitted job.
`LAB V1 · EoMT Cityscapes Large 1024 + DDRNet-39` now has a source-independent
portable RunDefinition and lightweight recorded-source capability probe. The
definition seals the exact model/component/resource identities, observation-only
authority and generic `missioncore.recorded-eomt-ddrnet-review/v2` result
contract; it contains no source Session id or label. Compatibility is derived
from the selected Session's real K1 capabilities rather than its name. A
compatible source may therefore report capability `pass` independently from
executor readiness.
That portable foundation is not an executable product path yet. Its executor is
`not-installed`, and there is no accepted server-side definition-SHA/check-SHA
fenced check/submit API, generic v2 result assembler/publisher or deployed Worker
executor. Preflight consequently remains blocked and the UI must not promise or
expose enqueue. The old `missioncore.lab-v1-vegetation-shadow/v1` result is not an
exact/existing result of the generic portable definition, even for its original
source; it remains available only in the immutable legacy LAB catalog.
Recorded work has priority rank `100`. A future live K1 lease has rank `0` and
closes new recorded claims while it is pending or active. Cooperative executors
@@ -323,11 +336,14 @@ pending for retry; a conflicting or indeterminate receipt enters reconciliation.
Every unresolved form blocks live activation and concurrent ownership.
An explicit live terminal trigger requeues paused recorded work.
ADR 0046 records this decision. The durable queue and identity contracts are
implemented; Worker claim transport, installation of the exact M4.9T5 executor
and wiring from the real K1 lifecycle to live-lease triggers remain pending.
Therefore a submitted M4.9T5 job may honestly wait in `queued` without implying
that Worker 006 can execute it yet.
ADR 0046 records this decision. Durable queue and identity contracts, the
authenticated Worker pull protocol and transport-agnostic Worker agent exist as
foundation. The production app hard-disables the Worker router even when a valid
credential is present until an expiring claim lease and verified result publisher
are accepted. Installation of the exact executors, Worker deployment and wiring
from the real K1 lifecycle to live-lease triggers remain pending. Therefore a
submitted M4.9T5 job may honestly wait in `queued` without implying that Worker
006 can execute it yet; portable LAB V1 cannot currently be submitted at all.
Worker telemetry remains secondary observation evidence. It does not replace the
authoritative queue ledger, result validation or common laboratory receipt. K1