Dependency and artifact flow

The ecosystem combines three kinds of relationship: Python dependencies, trained artifacts, and orchestration. Treating them as one package graph hides important ownership boundaries.

ssm-simulators ──> LANfactory ──> trained networks ──> artifact store
       │                                                   │
       │                                                   v
       └───────────────────────────────────────────────> HSSM

LAN_pipeline_minimal orchestrates generation, training, validation,
staging, and promotion with ssm-simulators and LANfactory.

Python dependency edges

ssm-simulators is the producer for simulation behavior and result contracts. LANfactory consumes it to create training data and HSSM consumes it for simulation-backed workflows. A change to simulator shapes, names, or metadata therefore requires downstream contract checks even when import versions still resolve.

LANfactory owns training and export behavior. It produces likelihood-network artifacts; HSSM does not import LANfactory as part of ordinary inference. Package-specific minimum versions live in each repository's project metadata, not on this page.

Artifact edges

Trained networks cross repositories as versioned artifacts plus metadata. LAN_pipeline_minimal owns the validated promotion path. The artifact store serves approved outputs, and HSSM owns consumer-side loading and validation. Changing an exporter requires checking both artifact validation and HSSM's consumer contract.

Orchestration is not a package dependency

LAN_pipeline_minimal coordinates ssm-simulators and LANfactory but is not a runtime dependency of HSSM. HSSMSpine coordinates repository work but is not a runtime dependency of any package. HSSMCortex supplies optional knowledge and capability content; it likewise sits outside the package dependency graph.

Release consequences

Release producers before consumers: ssm-simulators, then LANfactory when needed, then validated artifacts, and HSSM last. Feedstock updates follow the corresponding PyPI releases. The release procedure turns this graph into an operational checklist.

For reader-facing repository roles and destinations, see the ecosystem map. For exact source boundaries, see source ownership.