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

feat(observatory): ship modular AI inference labs

Browse Source
This commit is contained in:
DCCONSTRUCTIONS
2026-09-04 17:59:05 +03:00
parent eff60e490a
commit cada687173
145 changed files with 17651 additions and 1667 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/domain-model/observatory-domain-ontology-v1.md
+68
View File
@@ -0,0 +1,68 @@
# Missing Core Observatory domain ontology v1
Status: local runtime canonical. Owner: NODE.DC Mission Core.
The Observatory now has four independent consumers of the same relationships:
composition validation, Worker job dispatch, LAB/result projection and replay
controls. The previous typed-contract-only approach lost the relation between a
multi-module submission and its member results. This satisfies the local
ontology admission gate in `docs/18_APPLICATION_COMPONENT_ARCHITECTURE.md`.
The executable source is `config/observatory-domain-ontology.json`. It defines
transport and equipment units, time-bounded equipment mounts, capture profiles,
recorded sessions, module versions, immutable compositions, append-only
composition runs, container images, worker nodes, jobs, portable results, LAB
projections, viewer panes and viewer layers. These are peer subjects with independent identities and
lifecycles. A per-result LAB view profile owns the operator's mutable SLAM
display choices. The entities follow the NODE.DC Platform ontology architecture without making
Platform a dependency. Its named queries are recording capture context,
configuration label, member results, viewer layers and ready state.
A recorded session binds to the transport, equipment units, equipment mounts
and exact capture profile that produced it. A composition run points to that
session and never substitutes its own identity for transport or equipment. This
keeps future vehicle and sensor changes separate from model configuration and
from the published evidence.
A module version is implemented by an immutable container image. Installation
of that image on a worker and execution of a recorded job on a worker are
separate relationships, so Worker 006 is not encoded inside the module identity.
The replay layer remains a capability of the module version and can therefore be
derived through the module-to-image relationship without coupling UI controls to
a Docker runtime instance.
One saved composition is opened by one Rerun viewer and one shared recording
clock. Camera, LiDAR, depth and future sensor views are panes inside that viewer's
blueprint. Every pane owns its layer controls; the overlay follows the pane bounds
when a separator moves. A second Rerun viewer is reserved for a genuinely
independent recording or clock, because duplicating a viewer per pane would also
duplicate the recording transport, memory and synchronization work.
Pane construction is projected from module capabilities. DDRNet and EoMT create
only the camera pane with their independent segmentation layer. RF-DETR creates
the camera pane with object frames. TRAVEL TGS creates only the spatial pane with
source points, local SLAM and TGS. Object distance composes the camera detections
and spatial LiDAR panes it needs. Combining modules takes the ordered union of
these pane layers, so a configuration cannot invent an unrelated camera or point
cloud viewport.
Operator SLAM display settings belong to the published LAB result identity. They
are mutable presentation state, stored atomically in the Mission Core runtime,
and are loaded again after browser storage is cleared. They do not modify the
immutable calculation result, module configuration or recorded evidence.
Identity and lifecycle remain owned by the existing stores. The ontology does
not replace their contracts and does not contain executable commands, mutable
container instances, paths or resource grants. Image digests and worker
identities remain facts supplied by their owning registries. The ontology
projects their exact identities into one shared relationship model.
Version 1 uses additive migration for existing single-module results. A recorded
composition run may reference an already published exact module result; this is
recorded as reuse, not a new inference. Failed attempts remain audit evidence and
do not satisfy the ready-state query.
There is no runtime dependency or write path to NODE.DC Platform Ontology. The
Platform repository supplied the package architecture only. Synchronization is
`none` until a meaning becomes stable across products and receives a separate
owner-approved migration.