NODEDC_MISSION_CORE/docs/domain-model/observatory-domain-ontology-v1.md

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.