EMEP Context: What the Platform Is and Is Not

The Evolutionary Model Engineering Platform (EMEP) is a documentation-first specification for a system that creates new high-performing large language models from existing open-weight models. EMEP does this through a closed primary loop: compatibility analysis identifies which models can be combined, tensor-level merging produces candidate models, evaluation measures performance, and evolutionary optimization iteratively improves the population of candidates. This page defines what EMEP is, what it is not, and the primary research loop that governs all platform behavior.

What EMEP Is

EMEP is a model engineering platform. Its sole purpose is to discover, import, validate, merge, evaluate, and evolve combinations of existing open-weight language models into new models that outperform their ancestors on specified benchmarks. The platform treats models as artifacts with full provenance tracking. Every merge operation, every evaluation run, and every evolutionary step produces hashed artifacts stored in an ArtifactStore. The system never operates on opaque binaries. Every candidate model carries a complete lineage graph back to its base models. EMEP is built around these core abstractions:

ModelRegistry: catalogs all discovered, imported, validated, and evolved models
ModelCompatibilityAnalyzer: determines whether two or more models can be merged
MergeEngine: executes tensor-level merge operations using strategies such as Linear Merge, SLERP, TIES, DARE, and Task Arithmetic
EvaluationEngine: runs benchmarks on the Optimization Set and Validation Set
EvolutionEngine: drives the search for better candidates through mutation, crossover, and selection
FitnessEngine: computes scalar or vector fitness scores from evaluation results

What EMEP Is Not

The following capabilities are explicitly outside EMEP scope. They may appear as downstream integrations or future work, but they are not part of the primary loop.

Capability	Status	Rationale
Chatbot / conversational interface	Out of scope	EMEP produces models, not applications
Retrieval-Augmented Generation (RAG)	Downstream only	RAG consumes models; it does not create them. See optional RAG architecture
Fine-tuning as primary method	Optional	Fine-tuning may produce specialist models for merging, but it is not the core mechanism. See optional fine-tuning
Autonomous agents	Out of scope	Agent orchestration is an application-layer concern
API wrapper / inference gateway	Out of scope	InferenceBackend serves merged models, but EMEP is not a generic API platform
Training from scratch	Out of scope	EMEP always starts from existing open-weight models

Any feature not listed in the primary loop or explicit side branches is out of scope for the current specification. Requests to add chat interfaces, agent frameworks, or training pipelines must be rejected or deferred to a downstream project.

The Primary Research Loop

The following diagram shows the closed loop that defines EMEP execution. No model reaches DEPLOYED status without traversing every step in this loop.

The Hidden Test Set is never used by the EvolutionEngine or FitnessEngine. It is evaluated exactly once per promoted model, after the candidate has been selected. This prevents benchmark contamination and overfitting. See ADR-0003 for the architectural decision.

Model Lifecycle States

Models progress through a strict lifecycle. Each state transition is logged in the ExperimentTracker and stored in the ArtifactStore.

State	Meaning	Entry Condition
DISCOVERED	Model identified in public or private catalog	Automated crawler or manual submission
IMPORTED	Weights and config downloaded	Import pipeline completes without hash mismatch
VALIDATED	Architecture and tokenizer checked	ModelCompatibilityAnalyzer confirms structural integrity
REGISTERED	Available for merging	Validation passes and model is indexed
CANDIDATE	Produced by a merge operation	MergeEngine outputs a new artifact
EVALUATED	Optimization and validation benchmarks complete	EvaluationEngine finishes without error
PROMOTED	Selected by fitness or Pareto criteria	EvolutionEngine or manual curator approves
RELEASED	Ready for quantization or deployment	Promotion confirmed and provenance audit passes
DEPLOYED	Active in an InferenceBackend	DeploymentManager confirms health check
DEPRECATED	Superseded by newer candidate	Manual decision or automated policy
ARCHIVED	Retained for provenance but not active	Deprecation confirmed and storage tier moved

Audience and Use Cases

Role	Primary Use
Research Engineer	Design merge strategies, define fitness functions, interpret Pareto fronts
ML Engineer	Execute merges, debug tensor shape mismatches, tune merge hyperparameters
MLOps Engineer	Operate the ModelRegistry, manage artifact storage, monitor GPU health
Backend Engineer	Implement ExperimentTracker, ArtifactStore, and provenance APIs
Evaluator	Define benchmarks, audit benchmark integrity, run hidden test set evaluations
PM	Track experiment states, review candidate status dashboards, plan phase milestones

Vision and Scope for scientific hypothesis and commercial objectives
Project Constitution for the 20 non-negotiable rules
Glossary for term definitions
Decisions for architecture decision records

Project Context

Research Foundation

System Maps

EMEP Context: What the Platform Is and Is Not

What EMEP Is

What EMEP Is Not

The Primary Research Loop

Model Lifecycle States

Audience and Use Cases

​What EMEP Is

​What EMEP Is Not

​The Primary Research Loop

​Model Lifecycle States

​Audience and Use Cases

​Related Pages

What EMEP Is

What EMEP Is Not

The Primary Research Loop

Model Lifecycle States

Audience and Use Cases

Related Pages