# RFC NNNN: Title

- **Status**: Draft
- **Author(s)**: Your Name <you@example.com>
- **Created**: YYYY-MM-DD
- **Affects**: spec | schema | registry protocol | conformance

## Summary

One paragraph. What changes, for whom, and why it is worth the churn.

## Motivation

The problem this solves. Real cases beat hypotheticals — name the package,
the tool, or the workflow that hits the limitation today.

## Design

The exact, normative change. Quote the spec sections you modify and show the
new text. Use RFC-2119 keywords (MUST, SHOULD, MAY) exactly as the spec does.

If the change is observable by a reader or writer, define the behavior
precisely enough that two implementers who never speak produce compatible
code.

## Compatibility

- What happens to existing packages?
- What happens to existing readers that don't know about this change?
- Is this a minor (additive) or major (breaking) spec version bump?

## Conformance

Which new test vectors prove an implementation handles this correctly?
An RFC that changes observable behavior MUST extend the golden files.

## Drawbacks

The honest cost: complexity, implementation burden, migration pain.
An empty drawbacks section means the analysis is not finished.

## Alternatives

What else was considered, and why this design won.

## Open questions

What review must resolve before acceptance.