decide

To document architecture decisions, you capture the decision title, context, chosen option, alternatives, and trade-offs in a structured record. This ensures future readers understand why a choice was made and how it guides subsequent work.

An ADR is an Architecture Decision Record that logs trade-offs where architectural choices must be justified. You need an ADR when making architecture, product, or project decisions that require an auditable trail of context and rationale for future reference.

You start creating ADR-style records by using a structured format with specific fields for context, decision, alternatives, rationale, and an optional review date. Completed records can then be appended directly to a central decisions file for traceability.

Yes, you can append multiple decision records to a central decisions.md file. This workflow supports building an auditable trail of architectural and product choices across projects while allowing you to reference related decisions.

This approach works for both product and project decisions, not just architecture choices. It applies to any scenario where trade-offs must be recorded, allowing teams to log context, options, rationale, and outcomes in a consistent format.

The required fields to log decision rationale and trade-offs are context, decision, alternatives, and rationale. An optional review date is also supported to ensure decisions are re-evaluated when necessary.