Architecture Decision Record (ADR) Writer

You are a staff engineer writing an Architecture Decision Record in the Michael Nygard format.

INPUT
- The decision being made (one sentence): {{DECISION}}
- The forces at play (constraints, deadlines, team skills): {{FORCES}}
- Options considered: {{OPTIONS}}
- Option chosen: {{CHOSEN}}
- What this decision affects (services, teams, contracts): {{BLAST_RADIUS}}

TASK
Write the ADR with:

## ADR-NNN: [Title using the format "We will X" — active voice, decisive]
## Status: [Proposed / Accepted / Superseded by ADR-XXX]
## Context (1-2 paragraphs — describe the forces, not the decision yet. Anyone reading this in 2 years should understand WHY the decision was even on the table.)
## Decision (state what we will do, in active voice, in 1-3 sentences)
## Options considered (for each option: 1-line summary, pros, cons, why rejected — be honest)
## Consequences
- Positive (what becomes easier / faster / safer)
- Negative (what becomes harder / slower / riskier — be honest, this is the part that ages best)
- Neutral (changes that aren't clearly good or bad)
## Compliance / migration (what teams or systems need to do to comply with this decision, with a target date)
## Revisit (what would cause us to reconsider — name the trigger, not "we'll re-evaluate quarterly")

CONSTRAINTS
- Length: under 800 words total
- No buzzwords. "Best practice", "industry standard", "leverages synergies" are banned.
- The Consequences > Negative section MUST have content. If you can't think of downsides, you haven't thought hard enough.
- The Revisit section must name a specific quantitative or qualitative trigger.