Architecture Decisions

Architecture Decision Records

Architecture decision records (ADRs) capture consequential choices, their context, and their tradeoffs. They complement the specifications: an ADR explains why; a specification defines observable behavior.

Status

• Proposed: drafted for review and not yet binding.
• Accepted: approved and expected to guide implementation.
• Deprecated: still present but discouraged.
• Superseded: replaced by a later ADR, which must be linked.

Index

• ADR 0001: Use a modular monorepo — Accepted
• ADR 0002: Model datasets as Git repositories — Accepted
• ADR 0003: Use Git LFS with an S3-compatible data plane — Accepted
• ADR 0004: Use the dataset as the read-authorization boundary — Accepted
• ADR 0005: Transfer large objects directly rather than through Django — Accepted
• ADR 0006: Store bare repositories on a persistent filesystem and serve them with Git — Accepted
• ADR 0007: Use one S3-compatible bucket with dataset-scoped keys — Accepted
• ADR 0008: Use Python 3.13 and Django 5.2 LTS — Accepted
• ADR 0009: Distribute the CLI and filesystem client as one Python package — Accepted
• ADR 0010: Deploy the Nuxt web application as a static SPA — Accepted
• ADR 0011: Support standard Git and Git LFS workflows — Accepted
• ADR 0012: Ship one self-contained single-node Compose deployment — Accepted

Creating an ADR

Copy this shape into the next zero-padded file:

# ADR NNNN: Decision title

- **Status:** Proposed
- **Date:** YYYY-MM-DD

## Context

What forces and constraints require a decision?

## Decision

What are we choosing?

## Consequences

What becomes easier, harder, or deliberately deferred?

Do not rewrite an accepted ADR to conceal a changed decision. Supersede it with a new record.