The 20 Rules
Rule 1: Open-Weight Only
EMEP operates exclusively on open-weight models with inspectable parameter tensors. Closed-weight APIs and opaque model binaries are permanently excluded. Rationale: Merge operations require direct tensor access. Without weight inspectability, compatibility analysis and task vector extraction are impossible. Violation consequence: MergeEngine cannot execute. ModelRegistry must reject the import.Rule 2: Full Provenance for Every Artifact
Every model, every merge output, every evaluation result, and every experiment run must carry a complete, cryptographically verifiable lineage graph back to its original base models and data sources. Rationale: Reproducibility and auditability depend on knowing exactly what was combined, when, and how. See ArtifactStore and Model Provenance. Violation consequence: Experiment is invalid. Result cannot be published or deployed.Rule 3: Compatibility States Are Trinary
Every pairwise model comparison must produce exactly one of three states: COMPATIBLE, CONDITIONALLY_COMPATIBLE, or INCOMPATIBLE. No fourth state exists. Rationale: Ambiguity in compatibility leads to undefined merge behavior. The trinary state forces explicit handling of edge cases. See ADR-0009. Violation consequence: MergeEngine must refuse to execute.Rule 4: Hidden Test Set Is Never Used for Optimization
The Hidden Test Set may be evaluated exactly once per promoted model, after all evolutionary selection and hyperparameter tuning are complete. Rationale: Any use of the hidden set for model selection contaminates the benchmark and invalidates generalization claims. See ADR-0003. Violation consequence: Candidate status is forced to INVALID. Model cannot be promoted.Rule 5: Every Merge Strategy Is Deterministic
Given identical inputs, identical parameters, and identical random seeds, a MergeStrategy must produce bitwise-identical outputs. Rationale: Reproducibility of merge experiments requires deterministic execution. Nondeterminism must be explicitly seeded and logged. Violation consequence: Experiment is marked INCOMPLETE until determinism is verified.Rule 6: Candidate Status Is Quinary
Every candidate produced by the system must carry exactly one of five statuses: PASS, FAIL, REGRESSION, INVALID, or INCOMPLETE. Rationale: Five states cover all operational outcomes without ambiguity. See Candidate Status definitions. Violation consequence: FitnessEngine cannot compute a score. EvolutionEngine cannot select the candidate.Rule 7: Evolution Is the Primary Search Mechanism
The EvolutionEngine is the default and preferred method for discovering superior model combinations. Exhaustive search and random search are fallback methods only, to be used when evolutionary search is infeasible. Rationale: Evolutionary search scales better than exhaustive enumeration as the model population grows. It also enables multi-objective optimization. Violation consequence: Any claim of “optimal” combination without evolutionary search must be tagged as Unsupported.Rule 8: Fine-Tuning Is Optional, Never Required
Fine-tuning may be used to produce specialist models for merging, but no primary loop step depends on it. Rationale: The core hypothesis is that merging alone can produce superior models. Fine-tuning is an auxiliary input, not a core mechanism. See ADR-0004. Violation consequence: Any pipeline that requires fine-tuning to produce a candidate is out of spec.Rule 9: RAG Is Downstream Only
Retrieval-Augmented Generation may consume EMEP-produced models, but it is never part of the model creation loop. Rationale: RAG is an application-layer technique. It does not create new parameter tensors. See ADR-0005. Violation consequence: Any experiment that includes RAG in the primary loop is invalid.Rule 10: Agents Are Out of Scope
Autonomous agent frameworks, tool use orchestration, and multi-agent systems are permanently excluded. Rationale: Agents are applications built on top of models. EMEP produces models, not applications. See ADR-0006. Violation consequence: Feature request rejected.Rule 11: Modular Architecture, Not MergeKit-Coupled
EMEP components are independent abstractions with defined interfaces. The platform may interoperate with MergeKit or similar tools, but no component is hard-coded to a single external library. Rationale: Vendor or library lock-in prevents substitution, testing, and evolution of individual components. See ADR-0001. Violation consequence: Component fails architecture review.Rule 12: Documentation-First Execution
No implementation begins before its specification is written, reviewed, and ratified as an ADR or algorithm document. Rationale: The platform is a specification. Code is the secondary artifact. See ADR-0002. Violation consequence: Pull request rejected. Implementation deleted.Rule 13: Hard Phase Gates
No phase begins until the previous phase has passed all acceptance criteria. Skipping phases is prohibited. Rationale: Each phase builds infrastructure that later phases depend on. Skipping creates hidden technical debt. Violation consequence: Project manager must halt work and return to previous phase.Rule 14: Mermaid Is the Primary Diagram Format
All architecture, algorithm, data flow, and state diagrams are specified in Mermaid syntax. No other diagram format is required for conformance. Rationale: Mermaid is text-based, version-controllable, and renderable in documentation tools. See ADR-0007. Violation consequence: Diagram is not accepted into the specification.Rule 15: Every Artifact Is Hashed
Every file, model checkpoint, configuration, and log produced by the platform must be hashed at creation and the hash stored in the provenance record. Rationale: Integrity verification requires a cryptographic anchor. See ADR-0008. Violation consequence: Artifact is rejected by ArtifactStore.Rule 16: Multi-Objective Optimization via Pareto
When multiple benchmark metrics conflict, the platform selects candidates using Pareto dominance, not scalar aggregation, unless an explicit scalarization function is ratified by ADR. Rationale: Scalar aggregation hides trade-offs. Pareto fronts make them explicit and auditable. See ADR-0010. Violation consequence: Selection result is tagged as Engineering Assumption, not Established Research.Rule 17: Benchmark Contamination Is a First-Class Risk
The platform must detect, log, and mitigate benchmark contamination at every stage. Contaminated results are automatically invalidated. Rationale: Contaminated benchmarks produce false performance claims. See Benchmark Integrity. Violation consequence: Candidate status forced to INVALID.Rule 18: GPU Health Is Monitored Continuously
Every GPU participating in merge, evaluation, or evolution must have its temperature, memory errors, and numerical correctness checked before and after each job. Rationale: Silent GPU errors corrupt merge outputs and evaluation scores. See GPU Health. Violation consequence: Job result is marked SUSPECT and must be re-run.Rule 19: Offline Deployment Is a First-Class Mode
The platform must support full operation, including model deployment, in air-gapped environments without internet connectivity. Rationale: Enterprise and government users require offline operation. See Offline Deployment. Violation consequence: DeploymentManager refuses to certify the release.Rule 20: Security Is Layered
Model supply chain, license compliance, artifact signing, dependency safety, and offline security are mandatory, not optional. Rationale: A platform that produces models must guarantee their integrity and legal usability. See Security Requirements. Violation consequence: Model cannot be promoted to RELEASED.The Primary Research Loop
The following diagram illustrates how the rules govern the core EMEP execution flow.Related Pages
- Context for what EMEP is and is not
- Vision and Scope for phase boundaries and exclusions
- Decisions for the Architecture Decision Records behind these rules
- Glossary for term definitions