Reference
Architecture decisions
How ADRs are used, how to read them, and where the full record lives.
Implemented Ledger class: shipped-local
Verified 2026-10-23
Architecture Decision Records explain why a boundary, contract, or tradeoff exists. They are not implementation evidence and they do not override the status ledger.
Full index
The canonical ADR directory is in the repository:
The repository currently contains ADRs 0002 through 0087; gaps in the sequence are intentional.
Start with these
| Area | Decisions |
|---|---|
| Identity | 0006 auth proto, 0007 token validation, 0009 permission bitmap, 0016 agent identity |
| Proxy | 0011 auth client, 0012 normalization, 0013 errors, 0081 fail-closed controls |
| Memory | 0054 PII, 0055 dedup, 0056 conflict, 0060 isolation |
| Context | 0038 assembly, 0068 relevance, 0069 packer, 0071 degradation |
| Evidence | 0084 G0 binding, 0085 relay |
| MCP | 0050 memory server, 0086 operator gateway |
Reading rules
- A proposed ADR has no runtime claim.
- An accepted ADR is a decision, not acceptance evidence.
- A superseded ADR remains useful history; follow the superseding record.
- An ADR can be correct while the implementation is incomplete.
- When an ADR and the status ledger disagree about what is running, the ledger wins.
Adding a decision
A new ADR is required when a change alters a cross-service contract, trust boundary, data lifecycle, security control, provider boundary, or deployment profile. Pair it with ledger evidence and a review/expiry date.