Architectural Decision Records
Decisions that shape the platform's architecture, recorded using the MADR format. See Contributing for when and how to write an ADR.
| ADR | Status | Decision |
|---|---|---|
| 0001 — Platform architecture and distribution | Proposed | Single package with extras, base images for client deployment, four platform layers, semver over an explicit public API |
| 0002 — API and access strategy | Proposed | Traefik + Zitadel at the edge, FastAPI as unified API, zero-trust internal model with a read/write split, audit logs on blob |
| 0003 — Data catalog, lineage, and observability | Proposed | DuckLake as mandatory IO wrapper, OpenLineage core with a pluggable backend (default PostgreSQL; optional Marquez), layered observability, failure-mode matrix and drift detection |
| 0004 — Data organization and ingestion | Proposed | Configurable medallion layers (landing/raw/curated), raw append-only invariant, governed erasure, landing-zone-first ingestion |
| 0005 — Authorization and data access | Proposed | API as the policy enforcement point, project-scoped RBAC, Zitadel for identity and grants, read/write split |
| 0006 — Deployment and project isolation model | Proposed | Deployment is the isolation unit; a project is its own DuckLake catalog (project/layer/entity) |
| 0007 — Compute, execution, and scaling | Proposed | In-process executor (k8s optional), tiered read paths, hybrid serve-vs-offload with async jobs, writes via Dagster |