Architecture Decision Records
Architecture decision records (ADRs) capture choices that change FDAI’s system boundaries, contracts, deployment topology, or long-lived operational obligations. The register makes the decision, alternatives, consequences, status, and replacement history reviewable in one place.
Scope: environment values such as a customer’s RPO/RTO, retention period, region, budget, or named owner are production evidence bindings, not upstream ADRs. A fork may add its own ADRs without rewriting the upstream records.
Register
Section titled “Register”| ADR | Status | Decision | Supersedes |
|---|---|---|---|
| ADR-0001 | Accepted | Azure day-zero platform baseline | lightweight OD entries in tech-stack.md and deployment drafts |
| ADR-0002 | Accepted | Independent runtime, identity, autonomy, and fork axes | local observation mode-only and production-fork coupling |
Status vocabulary
Section titled “Status vocabulary”| Status | Meaning |
|---|---|
| Proposed | under review; not an implementation authority |
| Accepted | current design authority |
| Deprecated | retained for history but not used for new work |
| Superseded | replaced by the named ADR |
| Rejected | considered and not selected |
Record contract
Section titled “Record contract”Every ADR contains:
- Context: the forces and constraints that require a decision.
- Decision: the selected behavior and its boundary.
- Alternatives: serious options considered and why they were not selected.
- Consequences: positive, negative, operational, security, and migration effects.
- Status and date: lifecycle state, decision date, and replacement relationship.
- Evidence: implementation and validation links when the decision has landed.
One ADR should answer one coherent decision. A platform-baseline ADR may bind several inseparable service choices when they form one deployment contract; later replacement of one choice receives a new ADR that explicitly supersedes the affected section.
Change process
Section titled “Change process”- Add a proposed ADR and its Korean translation in the same pull request.
- Link affected design docs and implementation paths.
- Record security, reliability, cost, and migration consequences.
- Obtain the architecture-owner approval and any specialist approval required by the change.
- Mark the ADR accepted only when the implementation plan and rollback path are reviewable.
- Update this register and the machine-readable ARB manifest when readiness changes.
Next steps
Section titled “Next steps”| To learn about | Read |
|---|---|
| Current ARB decision | Architecture Review Board Packet |
| Azure day-zero baseline | ADR-0001 |
| Runtime and customization axes | ADR-0002 |
| Technology selection detail | Technology Stack |