Skip to main content
EMEP is a documentation-first platform for creating new high-performing LLMs from existing open-weight models. This page defines the complete system architecture across three levels: Level 1 (Executive) presents the major functional blocks visible to stakeholders; Level 2 (Logical) groups all 17 internal abstractions by concern; Level 3 (Internal Component) exposes the internals of TensorEngine and EvolutionEngine. Each level refines the one above it and maps directly to implementation phases.
All component names are fixed EMEP terminology. See the Glossary for definitions.

​
Level 1: Executive Architecture

The executive view shows five to ten major blocks that a project sponsor or architect can reason about. Data flows from model sources on the left, through compatibility and merge, into evolution and evaluation, and finally to deployment and observability. Key flow:
  1. Models enter through Model Sources and are registered in ModelRegistry.
  2. ModelLoader loads weights into memory.
  3. ModelCompatibilityAnalyzer validates architecture, tokenizer, and tensor shapes.
  4. MergeEngine and TensorEngine produce merged candidates.
  5. EvolutionEngine drives iterative improvement via CandidateGenerator, EvaluationEngine, and FitnessEngine.
  6. Promoted models are handed to DeploymentManager and InferenceBackend.
  7. ExperimentTracker, ArtifactStore, and DatasetRegistry provide observability, storage, and dataset management.

​
Level 2: Logical Architecture

The logical view groups all 17 internal abstractions by architectural concern. Each group owns a cohesive set of responsibilities and exposes well-defined interfaces to other groups. Group responsibilities:

​
Level 3: Internal Component Architecture

Level 3 exposes the internal structure of TensorEngine and EvolutionEngine. These are the two most complex components and warrant detailed decomposition before implementation begins.

​
TensorEngine Internals

TensorEngine performs all numerical operations during merge. It must support multiple merge strategies at the tensor level. Responsibilities:
  • Load tensors from multiple model checkpoints into aligned memory layouts
  • Validate shape, dtype, and device compatibility before every operation
  • Execute SLERP (Shoemake 1985), Task Arithmetic (Ilharco et al. 2022), TIES-Merging (Yadav et al. 2023), DARE (Yu et al. 2023), and weighted mean kernels
  • Cache intermediate tensors to avoid redundant loads during evolutionary search
  • Report numerical stability diagnostics to MergeEngine

​
EvolutionEngine Internals

EvolutionEngine orchestrates the search loop. It maintains a population, applies genetic operators, and evaluates fitness. Responsibilities:
  • Initialize population from compatible model pairs or triples
  • Generate new candidates via mutation (parameter-space perturbation) and crossover (inter-model recombination)
  • Dispatch candidates to EvaluationEngine for benchmark scoring
  • Compute fitness using single-objective or multi-objective criteria (accuracy, perplexity, throughput, safety)
  • Apply NSGA-II (Deb et al. 2002) for Pareto-optimal selection when multiple objectives conflict
  • Enforce the rule that the Hidden Test Set is never used by EvolutionEngine
  • Terminate when fitness plateau, generation limit, or wall-clock budget is reached
This architecture is a design specification. Implementation has not started. Component boundaries may shift during Phase 1 prototyping.