Architecture Decisions (ADRs)
Architecture Decisions
Architecture Decision Records (ADRs) for the Alexandria project.
Architecture Decision Records (ADRs)
Architecture Decision Records capture decisions that were architecturally significant, expensive to make, and would be expensive to reverse. Rather than being changelogs or design documents, each record documents:
- Context: Why the decision was needed.
- Decision: What was decided and how it is structured.
- Consequences: Trade-offs, benefits, and operational implications.
- What would change this: Conditions that would invalidate or require revising the decision.
Records
| ID | Decision | Status | Date |
|---|---|---|---|
| 0001 | Bounded contexts are in-process modules, not services | Accepted | 2026-08-29 |
| 0002 | One configuration document, overridden from the environment | Accepted | 2026-08-29 |
| 0003 | Key material lives in an external wallet | Accepted | 2026-08-31 |
| 0004 | Authentication is terminated at the node, not at the client | Accepted | 2026-09-01 |
| 0005 | TLS is terminated by a proxy, in development too | Accepted | 2026-09-02 |
| 0006 | One image, three deployment shapes | Accepted | 2026-09-02 |
| 0007 | Unified wallet port and pluggable IdentityHub adapter | Accepted | 2026-09-07 |
Managing ADRs
- ADRs are immutable once Accepted. They are never edited to describe a different state later; instead, they are superseded by a new ADR.
- New proposals should copy the ADR template, receive the next sequential number, and initially carry
Status: Proposed.