# Template Document Brief
Rename or copy this file to match a real target document, then replace every bracketed placeholder.
## Mission
Draft `[replace: full document title]`.
This document is responsible for `[replace: the exact problem, protocol, model, or format this draft owns]`.
## Front matter
- Use the metadata defaults from `../draft-metadata.md`.
- Title: `[replace: exact title]`
- Intended status/category: `[replace: status]`
- Abstract anchor: `[replace: the one-sentence promise the abstract must make]`
- Special front-matter rule: `[replace: provenance sentence, naming convention, no special rule, or other constraint]`
## Exact scope
### In scope
- `[replace: the core protocol/model/format behavior this document must specify]`
- `[replace: the operations, messages, fields, or algorithms it must define]`
- `[replace: interoperability, parsing, validation, or generation behavior a clean-room reader must learn here]`
### Out of scope
- `[replace: topics owned by another document]`
- `[replace: implementation-internal details not meant for the public draft]`
- `[replace: deployment guidance, UI behavior, or local tooling workflow]`
## Required sections
Fill in the exact structure this document needs.
| Section | Must cover | Primary evidence source |
| --- | --- | --- |
| Introduction | `[replace: what the reader must understand first]` | `[replace: source]` |
| Terminology | `[replace: terms this document owns or imports]` | `[replace: source]` |
| Protocol / format / data model | `[replace: the normative heart of the document]` | `[replace: source]` |
| Validation / error handling | `[replace: failures, limits, or invariants]` | `[replace: source]` |
| Security considerations | `[replace: the concrete security topics the draft must address]` | `[replace: source]` |
| IANA considerations | `[replace: registrations or explicit no-action statement]` | `[replace: source]` |
| Examples / appendices | `[replace: what examples or collected grammar are required]` | `[replace: source]` |
## Required clean-room capabilities
After reading this document alone or with its named dependencies, a competent reader should be able to:
- `[replace: parse, validate, or interpret something]`
- `[replace: generate or send something interoperable]`
- `[replace: handle an error path or corner case correctly]`
- `[replace: understand the dependency on another document or external RFC]`
## Dependencies and cross-references
- Depends on `[replace: document or external RFC]` for `[replace: terminology or mechanism]`.
- Must not redefine `[replace: concept owned elsewhere]`.
- Should cross-reference `[replace: other document/section]` when discussing `[replace: topic]`.
## Evidence and example policy
- Primary evidence should come from `[replace: canonical code/spec/trace/artifact surface]`.
- Public examples should come from `[replace: observed output, packet capture, exported object, etc.]`.
- If the document includes byte-counted, grammar-sensitive, or binary examples, note the exact render traps here.
- Record any must-test hard cases: `[replace: separator byte, whitespace edge, malformed input, version boundary, etc.]`.
## High-risk review traps
Call out the mistakes reviewers should actively look for.
- `[replace: ambiguity that tends to cause duplicate wording or wrong ownership]`
- `[replace: subtle rule that renderers or authors often misstate]`
- `[replace: historical or compatibility behavior that must be preserved or explicitly excluded]`
- `[replace: example pitfall that only shows up after rendering]`
## Completion bar for this brief
The brief is ready when a drafter can answer all of these without guessing:
- What exactly does this document own?
- Which sections are mandatory?
- Which sources govern each major claim?
- Which topics belong in another document instead?
- Which example or review traps must be re-checked before publication?