Architecture Decision Records

Architecture Decision Records (ADRs) capture why a significant structural or cross-cutting choice was made, the trade-offs it accepts, and how compliance is checked. They complement code and API documentation rather than repeating implementation details.

Statuses are Proposed, Accepted, Superseded, or Rejected. Do not edit an accepted decision to reverse its meaning; a later ADR supersedes it and links back to the old record. Keep records concise and commit them with the change that makes the decision effective.

Use ADR template when proposing a decision. Number accepted and proposed records sequentially.

• ADR 0001: Retain a modular monolith with service adapters
• ADR 0002: Keep synchronous public APIs over async internals
• ADR 0003: Direct dependencies toward stable policy
• ADR 0004: Use typed failures and bounded recovery
• ADR 0005: Quarantine and retire legacy NWIS
• ADR 0006: Use a service-neutral transport layer
• ADR 0007: Organize service adapters behind stable facades
• ADR 0008: Separate fan-out execution from chunk planning
• ADR template