In brief
How the guide labels claims so current behavior is not mixed with proposals, history, research, or local experience.
Purpose And Position In The Tree#
Status labels are one of the publication's safety rails. They stop the guide from turning a proposal into a current claim, a paper into deployed behavior, a local experiment into protocol authority, or an old testnet into present guidance.
Label Meanings#
| Label | Meaning | Evidence needed |
|---|---|---|
| current | Checked against current implementation, merged KIP, official release, or official docs. | Rusty Kaspa source, merged KIP, release notes, or official docs. |
| proposed | Described by an open PR, draft KIP, roadmap item, or unmerged design. | Draft KIP, PR, design document, or official proposal text. |
| historical | True for a past network, release, date, or project state. | Dated source, release note, timeline, archive, or historical page. |
| research | Described by a paper or research design without claiming deployment. | Paper or upstream research documentation. |
| local experience | Learned from this workspace or local project work and not protocol authority by itself. | Local artifact plus public cross-check before any general claim. |
| needs checking | Plausible or useful, but not directly verified yet. | The exact public source that would settle it. |
Expanded Label Guide#
Status labels are the guide's safety rail. Current means the claim has been checked against the type of source that can support it. Proposed means the material appears in a KIP, PR, draft, roadmap-like source, or design description but must not be treated as deployed behavior without stronger evidence. Historical means the claim is about a past release, past network, old testnet, archived page, or old project state. Research means a paper, proof system, or technical design explains the idea, but the page is not claiming that the network currently behaves that way. local experience means the local project taught a useful lesson, but the public guide still needs upstream evidence before generalizing it.
The label needs checking is not a weakness to hide. It is how the guide avoids inventing authority. If a high-risk claim is useful but not yet closed, it belongs in the Source Notes and Open Questions. That lets future readers see exactly what source needs to be read and what decision remains.
When a page combines Toccata, covenants, ZK, and tooling, expect more than one label on the same page. One paragraph may be current docs posture, another may be implementation source, another may be proposed KIP text, and another may be local experience from the dice project. The publication quality comes from keeping those lines visible.