RFD NNN: TITLE

• Status: Draft
• Category: Design
• Authors: AUTHOR
• Date: DATE

Summary

One to three sentences describing what this RFD proposes. A reader should be able to understand the gist without reading further.

Motivation

Why is this change needed? What problem does it solve? What happens if we do nothing? Start with "why" before "how."

Design

The core of the RFD. Describe the proposed solution in enough detail that someone familiar with the codebase could implement it. Use diagrams, code snippets, and examples where they help.

Start with what the user or caller sees — the external behavior, API, or experience — before describing internals.

Structure this section however makes sense for the topic. Common subsections include: Overview, Design Goals, Architecture, Data Flow, API Changes, Configuration Changes.

Every section can be brief. A one-sentence Alternatives section is better than no Alternatives section.

Drawbacks

What are the known costs of this approach? What does the project give up by adopting it? Argue honestly against your own proposal.

Alternatives

What other approaches were considered? Why were they rejected? This section is important — it shows the reader that the solution space was explored and gives future readers context for the decision.

Non-Goals

What this RFD explicitly does not aim to achieve, even though a reader might expect it to. This keeps the discussion focused and signals awareness of the broader picture.

Risks and Open Questions

What could go wrong? What don't we know yet? What needs to be validated during implementation? It's better to surface uncertainty explicitly than to pretend it doesn't exist.

Implementation Plan

How will this be implemented? Break the work into phases or steps. This section bridges the gap between design and execution.

For each phase, briefly describe:

• What it includes
• What it depends on
• Whether it can be reviewed and merged independently

References

Links to related RFDs, issues, documentation, or external resources.