Phase 1: Model Registry and Compatibility Infrastructure

Build the foundational model management layer for EMEP. Phase 1 delivers the ModelRegistry, ModelLoader, and ModelCompatibilityAnalyzer, plus API and CLI specifications for model operations.

Phase 1 transforms the architectural definitions from Phase 0 into working infrastructure for model management. You implement the canonical catalog, loading mechanisms, and compatibility analysis that every merge and evaluation operation depends on. Without a reliable registry and compatibility layer, later phases cannot safely combine or compare models.

Purpose

The purpose of Phase 1 is to create the operational backbone for model handling in EMEP. You need a system that can register model metadata, load checkpoints into memory, and determine whether two or more models are structurally and semantically compatible for merging. This phase also establishes the public interfaces (API and CLI) through which users and downstream components interact with the model layer.

Entry Criteria

• Phase 0 exit criteria satisfied, including consistency audit and architecture sign-off
• Model storage backend selected and provisioned (e.g., object store, file system, or artifact repository)
• Baseline model checkpoints available for initial registry population
• API framework and CLI framework chosen and scaffolded

Exit Criteria

• ModelRegistry persists and retrieves model metadata with full lineage tracking
• ModelLoader successfully loads supported checkpoint formats into the TensorEngine
• ModelCompatibilityAnalyzer returns deterministic compatibility verdicts for model pairs
• API specification covers model registration, retrieval, and compatibility checks
• CLI specification covers model listing, inspection, and compatibility commands
• Integration tests pass for all three primary components

Primary Components

Phase 1 implements the following canonical components, each defined in Phase 0:

• ModelRegistry: the canonical catalog for model metadata, versions, and lineage. It stores architecture identifiers, parameter counts, training configurations, and parent-child relationships.
• ModelLoader: the abstraction responsible for loading checkpoint files into memory. It handles format detection, weight extraction, and tensor placement.
• ModelCompatibilityAnalyzer: the service that evaluates whether two or more models share compatible architectures, layer shapes, and vocabulary spaces. It produces a structured compatibility report.

Supporting infrastructure includes:

• TensorEngine: the low-level tensor operation layer that ModelLoader uses for weight placement
• ArtifactStore: the persistent storage layer that ModelRegistry uses for metadata and ModelLoader uses for checkpoint retrieval

Deliverables

Deliverable	Path / Reference	Description
ModelRegistry	ModelRegistry	Operational model catalog with CRUD, search, and lineage APIs
ModelLoader	ModelLoader	Checkpoint loader with format adapters and memory mapping
ModelCompatibilityAnalyzer	ModelCompatibilityAnalyzer	Compatibility scoring and verdict engine
API Specification	/interfaces/api-specification	OpenAPI or equivalent spec for model endpoints
CLI Specification	/interfaces/cli-specification	Command reference for model commands

Dependencies

Phase 1 depends directly on Phase 0:

• Phase 0: Research + Architecture + Documentation: provides component definitions, ADRs, canonical terminology, and glossary

Key Tasks

Track Phase 1 work in the project task registry:

• Project Tasks

Typical Phase 1 tasks include:

1. Implement ModelRegistry schema and persistence layer
2. Build ModelLoader adapters for supported checkpoint formats (e.g., Safetensors, PyTorch, ONNX)
3. Implement ModelCompatibilityAnalyzer with architecture fingerprinting
4. Design and document REST API endpoints for model operations
5. Implement CLI commands for model listing, inspection, and compatibility checks
6. Write integration tests covering end-to-end model registration and loading
7. Populate registry with baseline models for Phase 2 merge experiments

Risks

• Checkpoint format proliferation: New model formats may appear during Phase 1. Mitigate by designing ModelLoader with an adapter pattern.
• Compatibility false positives: Models with identical shapes but incompatible tokenizers may pass structural checks. Mitigate by including vocabulary overlap analysis in ModelCompatibilityAnalyzer.
• Registry performance at scale: Large model catalogs may degrade query performance. Mitigate by indexing key metadata fields and benchmarking early.

See the full risk register for tracked items and mitigations:

• Risk Register

Quality Gate

Phase 1 is complete when the following checklist is fully satisfied:

• ModelRegistry can register, retrieve, and delete model metadata with full lineage
• ModelLoader loads all baseline checkpoint formats without data corruption
• ModelCompatibilityAnalyzer produces deterministic verdicts for 100% of model pairs in the test suite
• API specification is published and validated against a running endpoint
• CLI specification is published and all documented commands execute successfully
• Integration tests cover registry-to-loader-to-analyzer workflows
• Performance baseline established for registry queries and model loading latency

Roadmap Position

The diagram below shows Phase 1 following Phase 0. It is the first implementation phase and supplies the model layer to all subsequent merge and evaluation work.