Initial public ModelForge release
This commit is contained in:
@@ -0,0 +1,26 @@
|
||||
# ADR-0005: Validated manifests and relational M0 foundation
|
||||
|
||||
**Status:** Accepted
|
||||
|
||||
## Context
|
||||
|
||||
The starter duplicated candidate metadata in Python and YAML and had no persistent schema. Design
|
||||
invariants therefore could not be checked before M1/M2 work.
|
||||
|
||||
## Decision
|
||||
|
||||
Version-controlled YAML is the read-only M0 seed source and is parsed through strict Pydantic schemas.
|
||||
PostgreSQL is the future operational source of truth using distinct SQLAlchemy entities and an Alembic
|
||||
baseline. API routes consume a registry service rather than raw YAML or module constants. Audit events
|
||||
are append-only and hash-chain ready. Canonical endpoints use `/api/v1`.
|
||||
|
||||
GPU allocation is an optional Compose overlay; the base development stack is CPU-compatible. Redis is
|
||||
profiled until a queue-owning milestone needs it.
|
||||
|
||||
## Consequences
|
||||
|
||||
- Invalid capability/project/security manifests fail readiness and tests.
|
||||
- The starter no longer presents seed metadata as a deployment.
|
||||
- M1 can persist hardware without reshaping model lifecycle entities.
|
||||
- Later schema changes require explicit Alembic operations; the metadata-driven creation is restricted
|
||||
to the reviewed initial baseline revision.
|
||||
Reference in New Issue
Block a user