You are a senior software architect writing an Architecture Decision Record (ADR) for an important technical decision. Your goal is to produce a document that helps both current team members and future developers understand not just *what* was decided, but *why* — including the trade-offs consciously accepted.

**Input:**
- ADR number: 0012
- Decision title: Use PostgreSQL instead of MongoDB for User and Order Data
- Project/system context: Mid-size e-commerce platform, ~100,000 MAU, team of 5 engineers, targeting production launch in Q3 2026
- Problem being solved: Need a primary database for users, orders, and inventory that supports multi-table ACID transactions and complex relational queries
- Options that were evaluated: 1. PostgreSQL — mature relational DB with JSONB support
2. MongoDB — document-oriented with flexible schema
3. MySQL — familiar relational option with weaker JSONB support
- Decision made: PostgreSQL
- Known consequences and trade-offs: Gains: full ACID guarantee across multi-table transactions, team already has SQL expertise, JSONB covers flexible product attributes. Trade-offs: schema migrations require planning and versioning with a tool like Flyway; horizontal read scaling needs read replicas configured separately

**Output — use this exact structure, no extra sections:**

---
# ADR-0012: [Decision Title]

**Date:** [today's date]
**Status:** Accepted
**Deciders:** Engineering Team

## Context
[2–4 sentences describing the situation, constraints, and why a decision was required. Be specific: mention scale, team size, or system boundaries where relevant.]

## Decision Drivers
- [Driver 1 — technical, business, or operational]
- [Driver 2]
- [Driver 3]

## Options Considered

### Option 1: [Name]
**Pros:** [specific advantages]
**Cons:** [specific disadvantages]

### Option 2: [Name]
**Pros:** ...
**Cons:** ...

[Repeat for all options provided]

## Decision
[2–3 sentences stating the chosen option and the primary reasoning. Reference the decision drivers explicitly. Do not use vague justifications like 'it's simpler' — explain *why* it is simpler in this specific context.]

## Consequences

### Positive
- [Concrete benefit 1]
- [Concrete benefit 2]

### Negative / Trade-offs Accepted
- [Trade-off 1 — be honest and specific]
- [Trade-off 2]

### Risks & Mitigations
| Risk | Mitigation |
|------|------------|
| [Risk 1] | [Concrete action to address it] |
| [Risk 2] | [Concrete action to address it] |

## Links & References
- [Related ADRs, tickets, RFCs, or documentation]
---

**Constraints:**
- Write entirely in English. ADRs are engineering documents intended for long-term archival; English maximises readability across future team members.
- Do NOT omit the "Negative / Trade-offs Accepted" section. Honest documentation of trade-offs is the most valuable part of an ADR.
- Do NOT use vague qualitative claims. Every advantage or disadvantage must reference a specific technical property, constraint, or measurable outcome.
- Keep tone neutral and factual. Do not retroactively advocate for the decision — document it objectively.
- Do not add sections beyond those listed in the format above.

You are a senior software architect writing an Architecture Decision Record (ADR) for an important technical decision.1 Your goal is to produce a document that helps both current team members and future developers understand not just *what* was decided, but *why* — including the trade-offs consciously accepted.

**Input:**
- ADR number: {{adr_number}}
- Decision title: {{decision_title}}
- Project/system context: {{project_context}}
- Problem being solved: {{problem_statement}}
- Options that were evaluated: {{options_considered}}
- Decision made: {{chosen_option}}
- Known consequences and trade-offs: {{consequences}}

**Output — use this exact structure, no extra sections2:**

---
# ADR-{{adr_number}}: [Decision Title]

**Date:** [today's date]
**Status:** Accepted
**Deciders:** Engineering Team

## Context
[2–4 sentences describing the situation, constraints, and why a decision was required. Be specific: mention scale, team size, or system boundaries where relevant.]

## Decision Drivers
- [Driver 1 — technical, business, or operational]
- [Driver 2]
- [Driver 3]

## Options Considered

### Option 1: [Name]
**Pros:** [specific advantages]
**Cons:** [specific disadvantages]

### Option 2: [Name]
**Pros:** ...
**Cons:** ...

[Repeat for all options provided]

## Decision
[2–3 sentences stating the chosen option and the primary reasoning. Reference the decision drivers explicitly. Do not use vague justifications like 'it's simpler' — explain *why* it is simpler in this specific context.5]

## Consequences

### Positive
- [Concrete benefit 1]
- [Concrete benefit 2]

### Negative / Trade-offs Accepted
- [Trade-off 1 — be honest and specific]
- [Trade-off 2]

### Risks & Mitigations
| Risk | Mitigation |
|------|------------|
| [Risk 1] | [Concrete action to address it] |
| [Risk 2] | [Concrete action to address it] |

## Links & References
- [Related ADRs, tickets, RFCs, or documentation]
---

**Constraints:**
- Write entirely in English. ADRs are engineering documents intended for long-term archival; English maximises readability across future team members.
- Do NOT omit the "Negative / Trade-offs Accepted" section. Honest documentation of trade-offs is the most valuable part of an ADR.3
- Do NOT use vague qualitative claims. Every advantage or disadvantage must reference a specific technical property, constraint, or measurable outcome.4
- Keep tone neutral and factual. Do not retroactively advocate for the decision — document it objectively.
- Do not add sections beyond those listed in the format above.