Architecture Decision Records
An ADR captures a significant design decision, the context that drove it, and its known tradeoffs - so it doesn't get silently relitigated or "fixed" by someone who wasn't there for the original reasoning. These are short and status-tracked, not a design essay; see Architecture for how the pieces they describe fit into the system as a whole, and the Features page for current behavior.
Index
| # | Title | Status |
|---|---|---|
| 0001 | ThunderID as the sole identity provider | Accepted |
| 0002 | In-app position/hierarchy layer instead of new IDP roles | Accepted |
| 0003 | Single school, single current academic year per deployment | Accepted |
| 0004 | In-app-only notifications (no email/SMS channel) | Accepted |
| 0005 | Hand-rolled password lifecycle (no IDP primitive) | Accepted, known weakness |
Adding a new ADR
Copy the format of an existing one: Status, Context, Decision,
Consequences. Number sequentially, never renumber or delete a
superseded record - mark its status Superseded by NNNN instead and add
the new one.