# ADR-{{ rfc_number }}: {{ title }}

**Author:** {{ author }}
**Date:** {{ date }}
**Status:** {{ status }}
**Tags:** {{ tags | join(', ') }}

## Context

> Summarize the business and technical backdrop for this decision. Include constraints, assumptions, and relevant historical context.

### Problem Space
> Describe the problem to solve, including constraints (latency, compliance, dependencies).

### Stakeholders
> List teams, roles, or systems impacted by the decision.

## Decision

> State the decision in a single, unambiguous sentence.

### Rationale
> Explain why this option is preferred. Reference data, experiments, or guiding principles.

## Consequences

### Positive Consequences
- [ ] Benefit …
- [ ] Benefit …

### Negative Consequences
- [ ] Trade-off …
- [ ] Trade-off …

### Neutral Consequences
- [ ] Impact …
- [ ] Impact …

## Implementation

> Describe how this decision will be realized in code and infrastructure.

### Technical Approach
> Outline architectural changes, patterns introduced, and affected modules/services.

### Migration Path
> Explain how to move from current to future state, including sequencing, deprecation plans, and rollback approach.

## Alternatives Considered

### Option 1
**Description**
> Summarize the alternative.

**Pros**
- [ ] Advantage …

**Cons**
- [ ] Concern …

**Why not chosen**
> Provide the decisive reason this option was rejected.

### Option 2
**Description**
> Summarize the alternative.

**Pros**
- [ ] Advantage …

**Cons**
- [ ] Concern …

**Why not chosen**
> Provide the decisive reason this option was rejected.

## Compliance

> Detail impacts on security, privacy, regulatory, or audit requirements. Note any additional reviews needed.

## Risks and Mitigation

| Risk | Impact | Probability | Mitigation |
|------|--------|-------------|------------|
| … | High/Med/Low | High/Med/Low | … |
| … | High/Med/Low | High/Med/Low | … |

## Success Metrics

> Define how success will be measured (technical and business KPIs). Include baselines and targets.

- Metric: …
- Metric: …

## Review

> Specify when and why this decision should be revisited (time-bound and trigger-based).

**Review Date:** …

**Triggers for Re-evaluation**
- [ ] Trigger …
- [ ] Trigger …

## References

> Link to diagrams, RFCs, tickets, dashboards, or research used to inform this decision.

- Reference …
- Reference …

## Appendix

> Include supplemental material: diagrams, deep dives, spike results, or calculations.

## Changelog

| Date | Version | Changes | Author |
|------|---------|---------|--------|
| {{ date }} | 0.1 | Initial draft | {{ author }} |
