27 lines
1.2 KiB
Markdown
27 lines
1.2 KiB
Markdown
# 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.
|