# Template IETF Corpus Brief
Use this file to define the real evidence contract for a project pack. Replace every bracketed placeholder with project-specific facts.
## Purpose
This brief answers four questions for the project:
1. What source material is authoritative?
2. What material is only informative or orientation-only?
3. What evidence shapes are acceptable for normative claims?
4. Where should a drafter look first for each major section or topic?
## Authoritative sources
Record the surfaces that actually govern the document content.
| Source surface | Role in the pack | Notes |
| --- | --- | --- |
| `[replace: primary specification corpus or standards text]` | Primary authority | `[replace: why it governs]` |
| `[replace: reference implementation repo / module / code path]` | Primary or corroborating authority | `[replace: when implementation wins or when it only confirms]` |
| `[replace: protocol traces / observed bytes / fixtures / exported artifacts]` | Ground-truth evidence | `[replace: what it proves]` |
| `[replace: secondary implementation or validation tooling]` | Additional authority or corroboration | `[replace: where it is weaker or stronger]` |
### Authority rule when sources disagree
> [replace: explicit rule such as "implemented behavior wins over lagging prose" or "the standards corpus wins over convenience tooling output"]
If there is any hierarchy within the authoritative sources, spell it out here instead of forcing a later drafter to guess.
## Informative sources
These materials help orientation, history, or explanation but should not silently override the authoritative corpus.
- `[replace: design notes, wiki pages, architecture docs, historical drafts, issue threads, blog posts]`
- `[replace: explanatory papers, vendor docs, internal notes, presentations]`
For each informative source family, note whether it is likely to lag the implementation or canonical specification.
## Claim basis and acceptable evidence shapes
Normative claims in the project should resolve to one or more of these evidence forms:
- `[replace: file:function, section anchor, standards clause, or API definition]`
- `[replace: observed byte sequence, packet capture, exported artifact, sample repository object]`
- `[replace: a concrete command or validation tool invocation plus the verdict it demonstrates]`
- `[replace: a rendered public example that was re-validated from rendered text]`
Non-authoritative material can help locate evidence, but it is not the final claim basis.
## Runtime, observed-output, or fixture surfaces
List the concrete places where a drafter or reviewer can inspect live behavior.
- `[replace: CLI or API used to inspect raw artifacts or payloads]`
- `[replace: capture repository, fixture directory, packet dump, or sample export]`
- `[replace: validation tool or parser used to confirm edge cases]`
- `[replace: cautions about chatty commands, blocking stdin, network dependence, or transient output]`
## Section-to-source routing
Fill in this table so a reader knows where to look first instead of searching the whole project.
| Draft section or topic | Read here first | Why |
| --- | --- | --- |
| `[replace: terminology/model section]` | `[replace: canonical source]` | `[replace: reason]` |
| `[replace: wire format / schema / grammar]` | `[replace: canonical source]` | `[replace: reason]` |
| `[replace: validation / error handling]` | `[replace: canonical source]` | `[replace: reason]` |
| `[replace: examples / observed behavior]` | `[replace: canonical source]` | `[replace: reason]` |
| `[replace: security or operational considerations]` | `[replace: canonical source]` | `[replace: reason]` |
## Boundaries and exclusions
This corpus brief should explicitly exclude material that is easy to confuse with authority.
- `[replace: environment bootstrap commands]`
- `[replace: local build or packaging recipes]`
- `[replace: harness-specific controller behavior]`
- `[replace: speculative notes or future design ideas not yet implemented or standardized]`
## Maintenance rule
When a copied excerpt, exported bundle, or local staged note under `references/` becomes the only place where an important conclusion is recorded, promote that conclusion into this file or `references.md`. The canonical pack docs, not the staged support files, must carry the lasting project decisions.