Skip to main content
The EMEP platform is composed of 17 internal abstractions, each with a defined interface, responsibility, and dependency set. This page documents which components call which, which components produce data consumed by others, and which are leaf nodes with no downstream dependents within the platform.

The 17 Components

Dependency Rules

  1. Acyclic: The component graph must remain a directed acyclic graph (DAG) at all times. No component may directly or indirectly call itself.
  2. Interface-based: All dependencies are through defined interfaces, not concrete implementations. This enables substitution and testing.
  3. Eventual consistency: Components that write to shared stores (ModelRegistry, ArtifactStore) do not require synchronous confirmation from readers.
  4. Failure isolation: A failure in one component must not cascade to unrelated components. The ExperimentTracker logs all failures independently.

Dependency Graph

Dependency Matrix

The following table shows direct dependencies. A checkmark indicates that the row component directly calls or reads from the column component.

Leaf Nodes

The following components have no downstream dependents within the EMEP platform. They are terminal nodes in the dependency graph.
  • TensorEngine: Leaf computation node. All merge strategies depend on it, but it has no internal EMEP dependents.
  • ArtifactStore: Leaf storage node. Many components write to it; none read from it for further platform computation.
  • DatasetRegistry: Leaf catalog node. BenchmarkEngine reads from it; no component depends on DatasetRegistry outputs for further processing.
The interfaces between these 17 components are defined in API Specification and Configuration Specification. Any change to an interface requires an ADR and updates to all dependent components.