Skip to main content
This glossary defines all terms used in the EMEP specification. Definitions are organized alphabetically within category groupings. Cross-references link to the primary pages where each term is defined in context.

​
Platform Concepts

Artifact Any file, model checkpoint, configuration, log, or evaluation result produced by the EMEP platform. Every artifact is hashed at creation and stored in the ArtifactStore. See Project Constitution Rule 15. ArtifactStore The component responsible for persistent storage, retrieval, and integrity verification of all artifacts. Stores hashes alongside content. See Artifact Registry. Candidate A model produced by a merge operation and submitted for evaluation. Every candidate has a status (PASS, FAIL, REGRESSION, INVALID, INCOMPLETE) and a complete lineage graph. See Candidate Status. Candidate Status The operational outcome of a candidate evaluation. Valid states are PASS (meets all criteria), FAIL (does not meet criteria), REGRESSION (performs worse than ancestors), INVALID (produced under invalid conditions), and INCOMPLETE (evaluation or merge did not finish). See Project Constitution Rule 6. DatasetRegistry The component that catalogs all datasets used for training, evaluation, and benchmarking. Tracks versions, licenses, and contamination status. See Dataset Registry. EMEP (Evolutionary Model Engineering Platform) The platform specified by this documentation. EMEP creates new high-performing LLMs from existing open-weight models via compatibility analysis, tensor-level merging, evaluation, and evolutionary optimization. Experiment A single execution run with defined inputs, parameters, and outputs. Experiments progress through states: CREATED, PREPARING, RUNNING, EVALUATING, COMPLETED, FAILED, CANCELLED, ARCHIVED. See Experiment Lifecycle. ExperimentTracker The component that logs all experiment state transitions, parameters, and results. Provides querying and audit interfaces. See Experiment Tracking. ModelRegistry The central catalog of all models known to EMEP. Tracks model lifecycle states, metadata, compatibility reports, and provenance. See Model Registry. Provenance The complete, verifiable history of an artifact or model, including all ancestors, operations, parameters, and timestamps. Provenance records are immutable and cryptographically anchored. See Model Provenance.

​
Model Lifecycle

ARCHIVED A model state indicating the model is retained for provenance but is no longer active or loadable for merge or inference. See Model Lifecycle. CANDIDATE A model state indicating the model was produced by a merge operation and is awaiting or undergoing evaluation. See Model Lifecycle. DEPLOYED A model state indicating the model is active in an InferenceBackend and serving requests. See Model Lifecycle. DEPRECATED A model state indicating the model has been superseded by a newer candidate but remains in the registry for reference. See Model Lifecycle. DISCOVERED A model state indicating the model has been identified in a public or private catalog but not yet imported. See Model Lifecycle. EVALUATED A model state indicating the model has completed evaluation on the Optimization Set and Validation Set. See Model Lifecycle. IMPORTED A model state indicating the model weights and configuration have been downloaded and verified. See Model Lifecycle. PROMOTED A model state indicating the model has been selected by the EvolutionEngine or a manual curator as superior to its population. See Model Lifecycle. REGISTERED A model state indicating the model has passed validation and is available for merge operations. See Model Lifecycle. RELEASED A model state indicating the model is ready for quantization or deployment and has passed a provenance audit. See Model Lifecycle. VALIDATED A model state indicating the model architecture and tokenizer have been checked for structural integrity. See Model Lifecycle.

​
Compatibility

Architecture Compatibility The analysis of whether two models share the same layer topology, activation functions, and structural hyperparameters. See Architecture Compatibility. Compatibility State The result of pairwise model comparison. Valid states are COMPATIBLE (merge can proceed without modification), CONDITIONALLY_COMPATIBLE (merge possible with shims or parameter adjustment), and INCOMPATIBLE (merge must not proceed). See Project Constitution Rule 3. ModelCompatibilityAnalyzer The component that determines compatibility states between models. See Model Compatibility. Tensor Shape Validation The verification that corresponding parameter tensors in two models have identical or broadcastable shapes. See Tensor Shape Validation. Tokenizer Compatibility The analysis of whether two models use the same vocabulary, special tokens, and tokenization algorithm. See Tokenizer Compatibility.

​
Merging

Delta The difference between a fine-tuned model and its base model, typically computed as a parameter-wise subtraction. Deltas are the inputs to task arithmetic and many merge strategies. See Task Arithmetic. DARE A merge strategy that drops and rescales parameters to reduce interference between task vectors. DARE: Yu et al. 2023. See DARE Math. Franken-Merge (Structural) A merge strategy that combines layers from different models by stacking or interleaving them, rather than blending parameters within a layer. See Merge Strategies. Linear Merge The simplest merge strategy: a parameter-wise weighted average of two or more models. See Merge Strategies. MergeEngine The component that executes merge operations. Accepts a MergeStrategy, input models, and parameters, and produces a candidate model. See Merge Engine. MergeStrategy An abstraction representing a specific tensor-level merge algorithm. Implementations include Linear Merge, SLERP, TIES, DARE, DARE + TIES, Task Arithmetic, Franken-Merge, and Passthrough. See Merge Strategies. ModelLoader The component that loads model weights and configurations into memory for analysis or merge. See Model Import. Passthrough A merge strategy that copies a layer or tensor unchanged from one model into the merged output, typically used in Franken-Merge configurations. See Merge Strategies. SLERP Spherical Linear Interpolation. A merge strategy that interpolates between models along the geodesic on a hypersphere, preserving vector magnitudes better than linear interpolation. SLERP: Shoemake 1985. See SLERP Math. Task Arithmetic A merge strategy that adds or subtracts task vectors (deltas) to a base model to combine or remove capabilities. Task Arithmetic: Ilharco et al. 2022. See Task Arithmetic. Task Vector The parameter delta between a fine-tuned model and its base model, representing the direction and magnitude of capability acquisition for a specific task. See Task Arithmetic. TensorEngine The low-level component that performs tensor operations such as addition, scaling, interpolation, masking, and shape manipulation. See Tensor Operations. TIES Trim, Elect Sign, and Merge. A merge strategy that reduces interference between task vectors by trimming redundant parameters, resolving sign conflicts, and disjointly merging. TIES-Merging: Yadav et al. 2023. See TIES Math.

​
Evolution

Crossover An evolutionary operator that combines genetic information from two parent genomes to produce one or more offspring. In EMEP, crossover may combine merge strategies, model selections, or hyperparameters. See Crossover. EvolutionEngine The component that drives the search for superior model combinations through mutation, crossover, and selection. See Evolution Engine. Fitness A scalar or vector measure of candidate quality derived from evaluation results. The FitnessEngine computes fitness scores. See Fitness. FitnessEngine The component that transforms evaluation metrics into fitness scores for evolutionary selection. See Fitness. Generation One complete iteration of the evolutionary loop: population evaluation, fitness computation, selection, and reproduction. See Population. Genome The encoding of a candidate model’s ancestry, merge strategy, and hyperparameters. Genomes are the units of mutation and crossover. See Genome. Multi-Objective Optimization The simultaneous optimization of multiple conflicting objectives, typically handled via Pareto dominance rather than scalar aggregation. See Multi-Objective Optimization. Mutation An evolutionary operator that randomly modifies a genome, for example by changing merge weights, switching strategies, or adding or removing models from the ancestry. See Mutation. Pareto Front The set of candidate models that are not dominated by any other candidate on all objectives. The Pareto front makes trade-offs explicit. See Multi-Objective Optimization. Population The set of candidate models under active evaluation in a given generation. See Population. Selection The process of choosing which candidates survive to the next generation or reproduce. Selection may be tournament-based, rank-based, or Pareto-driven. See Selection.

​
Evaluation

Benchmark Catalog The complete list of benchmarks available to the EvaluationEngine, including their splits, metrics, and contamination status. See Benchmark Catalog. Benchmark Contamination The presence of test-set data in training data or in the model’s pre-training corpus. Contaminated benchmarks produce invalid generalization claims. See Benchmark Integrity. BenchmarkEngine The component that executes individual benchmark tasks and collects raw metrics. See Evaluation Framework. Benchmark Split The division of a benchmark into subsets used at different stages. EMEP defines three splits: Optimization Set (used for model selection), Validation Set (used for intermediate assessment), and Hidden Test Set (used once per promoted model). See Benchmark Specification. CandidateGenerator The component that produces new candidate models from merge outputs, assigning initial status and lineage. See Merge Engine. EvaluationEngine The component that orchestrates benchmark execution, metric aggregation, and result storage. See Evaluation Framework. Hidden Test Set The subset of benchmark data that is never used by the EvolutionEngine or FitnessEngine. It is evaluated exactly once per promoted model. See Project Constitution Rule 4. Optimization Set The subset of benchmark data used for model selection and hyperparameter tuning during evolution. See Benchmark Specification. Regression Evaluation The assessment of whether a candidate performs worse than its ancestors on any benchmark metric. See Regression Evaluation. Safety Evaluation The assessment of a candidate model’s propensity to generate harmful, biased, or policy-violating outputs. See Safety Evaluation. Validation Set The subset of benchmark data used for intermediate assessment after a candidate passes the Optimization Set. See Benchmark Specification.

​
Deployment and Operations

DeploymentManager The component that manages model deployment to inference backends, including health checks, rollback, and update protocols. See Deployment Specification. InferenceBackend The component that serves model inference requests. May be vLLM, TGI, llama.cpp, or a custom runtime. See Inference. Offline Deployment Deployment of a model to an air-gapped environment with no internet connectivity. See Offline Deployment. QuantizationEngine The component that reduces model precision for deployment, supporting methods such as GPTQ, AWQ, and GGUF. See Quantization. Secure Model Packaging The process of bundling a model, its provenance record, license metadata, and dependency manifest into a signed, verifiable package. See Secure Model Packaging. Catastrophic Forgetting The loss of previously learned capabilities when a model is fine-tuned on new data. EMEP mitigates forgetting through merge-based preservation and optional control mechanisms. See Catastrophic Forgetting Controls. LoRA Low-Rank Adaptation. A parameter-efficient fine-tuning method that trains low-rank matrices instead of full weights. LoRA: Hu et al. 2021. See LoRA. PEFT Parameter-Efficient Fine-Tuning. The class of methods including LoRA, QLoRA, and adapters that reduce trainable parameters. See PEFT. QLoRA Quantized Low-Rank Adaptation. A method that fine-tunes LoRA adapters on a quantized base model to reduce memory requirements. QLoRA: Dettmers et al. 2023. See QLoRA.