Architectural Decision Records
This directory contains Architectural Decision Records (ADRs) for NAAS, using the MADR format.
What is an ADR?
An ADR documents a significant architectural or technical decision: what was decided, why, and what the consequences are. ADRs are immutable once accepted — if a decision changes, a new ADR supersedes the old one.
When to Write an ADR
Write an ADR when:
- Choosing between two or more non-trivial technical approaches
- Making a decision that would be hard to reverse
- Adopting a new tool, pattern, or dependency that affects the whole project
- Deciding on a convention that all contributors must follow
Do not write an ADR for:
- Implementation details (use code comments or PR descriptions)
- Bug fixes
- Routine dependency updates
How to Add an ADR
- Copy
template.mdtoNNNN-short-title.md(next sequential number) - Fill in all sections
- Set status to
Proposed - Open a PR — discussion happens in the PR review
- On merge, update status to
Accepted
Index
| ADR | Title | Status |
|---|---|---|
| 0001 | Python client library integration strategy | Accepted |
| 0002 | Secrets backend abstraction | Accepted |
| 0003 | API key authentication | Accepted |
| 0004 | Role-based access control | Accepted |
| 0005 | Structured audit event logging | Accepted |
| 0006 | Credential encryption at rest | Accepted |
| 0007 | API versioning strategy | Accepted |
| 0008 | OpenTelemetry instrumentation strategy | Accepted |
| 0009 | Command authorization deferred to AAA | Accepted |
| 0010 | MCP server as thin client over REST API | Accepted |
| 0011 | Release branch as the source of truth during a release | Accepted |