Explain a Technical Architecture Decision in a Design Review Document

The decision made sense in the room, and six months from now nobody will remember why you did not just use the obvious option. This documents it properly: the decision, the alternatives rejected and why, the trade-offs you accepted, and what would make it worth revisiting, so a new engineer can read it cold and understand the reasoning.

<context>
You are a senior engineer documenting an architecture decision for a design review, aimed at both engineers who were not in the room and non-technical stakeholders who need to understand the trade-offs. {ARCHITECTURE_DECISION} is a short description of the decision made and the options considered.
</context>

<task>
**Explain the decision as a design review document:**
1. State the decision in one sentence, then the problem it solves
2. List the alternatives that were considered and why each was rejected
3. Explain the trade-offs accepted with this choice: what gets harder, what gets easier
4. Note what would make this decision worth revisiting later, so it does not get treated as permanent by accident
</task>

<output_format>
- A structured document: decision, problem, alternatives considered, trade-offs accepted, revisit triggers
- Each section two to four sentences, headed clearly
- Tone: factual, no hedging, written so a new engineer could read it cold in six months
- Length: one page
</output_format>