# RFC Template

A structured format for technical proposals and design documents. Use what applies—skip sections that don't.

---

## Metadata

| Field | Description |
|-------|-------------|
| **Name** | Descriptive title |
| **Summary** | 2-3 sentences on what this proposes |
| **Status** | Draft → In Progress → Feedback Requested → Accepted/Rejected |
| **Author(s)** | Who's writing this |
| **RFC Sponsor** | Technical leadership representative supporting this |
| **Proposed Date** | When the RFC was created |
| **Feedback Due By** | Deadline for feedback |
| **Feedback Requested From** | Specific reviewers needed |

---

## Core Sections

### Context

What must be understood before thinking about this problem? Link relevant specs or prior art.

**Don't fill everything out.** The template exists to prompt thinking, not create busywork. A focused RFC with Context, Goals, and Design is better than a comprehensive one nobody reads.

**Write for your reviewers.** They're busy. Lead with what matters. Put details in appendices if needed.

### Goals / Non-Goals

#### Goals
* What you're trying to achieve.

#### Non-Goals
* What you're explicitly *not* addressing
* This scopes the RFC and prevents scope creep during review.

### Design

The actual solution. This is the meat of the document. Include enough detail that someone could implement it, but not so much that you're writing the code.

---

## Supporting Sections

Include these when relevant.

### Terminology

Define terms that aren't obvious. Skip if everything is well-known.

### Current System Use-Case

If replacing something, explain what exists and why it's insufficient.

### Assumptions

What you're assuming to be true. Multi-tenant? Data validity? User geography? Scale expectations?

### Limitations

Where this might break. Be honest about trade-offs—reviewers will find them anyway.

### Technology

**New** — Technologies being added and why.

**Deprecated** — Technologies being removed.

### APIs

New or modified APIs. Include request/response examples if helpful.

### Failure Scenarios

What happens when things go wrong? How does the system degrade?

### Alternatives Considered

Other approaches you evaluated and why you didn't pick them. Shows reviewers you've thought it through.

### Development/Complexity Estimate

Rough timeline or effort. T-shirt sizes are fine.

### Testing Strategy

How you'll verify it works: E2E, load testing, integration, etc.

### Monitoring

How you'll know it's working in production. KPIs, alerts, SLAs.

---

## Security and Compliance

If any of these apply, loop in your security/compliance team:

1. Modifies authentication or session management
2. Changes user roles or access rights
3. Could cause major system disruptions if it fails
4. Adds critical external dependencies
5. Changes how user data is collected, used, shared, or tracked
6. Requires new infrastructure (data centers, cloud providers)
7. Introduces new data exchange methods (webhooks, new API types)
8. Is a new standalone product or requires deep architecture changes

---

## Version History

Track significant changes to the RFC itself.

| Version | Date | Changes |
|---------|------|---------|
| 1.0 | [Date] | Initial draft |