ADR017 - Consequences Structure
In MADR format, the Consequences section should distinguish good and bad outcomes.
Why This Rule Exists
Structured consequences:
- Clarify trade-offs explicitly
- Help teams anticipate challenges
- Make positive and negative impacts visible
- Support informed decision-making
Formats
Option 1: Good/Bad Markers
Use "Good, because..." and "Bad, because..." format:
### Consequences
* Good, because it provides ACID compliance
* Good, because team has SQL experience
* Bad, because requires more operational overhead
* Neutral, because licensing costs are similar
Option 2: Separate Sections
Use separate positive/negative sections:
### Positive Consequences
* ACID compliance for data integrity
* Team familiarity reduces learning curve
### Negative Consequences
* Higher operational overhead
* More complex deployment
Examples
Incorrect
### Consequences
* Provides ACID compliance
* Team has SQL experience
* Requires more operational overhead
No distinction between good and bad outcomes.
Correct
### Consequences
* Good, because it provides ACID compliance
* Good, because team has SQL experience
* Bad, because requires more operational overhead
Or:
### Positive Consequences
* ACID compliance
* Team familiarity
### Negative Consequences
* Operational overhead
Rule Details
- Rule ID: ADR017
- Name: adr-consequences-structure
- Category: Content
- Severity: Info
- Applies to: MADR format only
- Automatic Fix: Not available