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.