In brief
How to read public source IDs, claim status, and Open Questions without upgrading uncertainty.
First Contact#
A source ID is a pointer, not decoration. To use it, ask what class of claim it can support. Implementation source can support implementation behavior at the pinned/current context. A KIP can support a proposal or merged design depending on status. A paper can support research background. Tooling repos can support tooling behavior without proving base protocol readiness.
Working Model#
For each claim, read the claim, status label, source support, and notes together. If the label says needs checking, do not smooth it into current prose. If the claim is about Toccata, covenants, ZK, wallet signing, testnets, readiness, or source behavior, require direct source checking.
Expanded source checking Method#
Checking Source Claims starts by classifying the claim. A current protocol claim needs implementation, merged KIP, release, or official docs evidence. A proposed claim can be supported by draft KIP or PR text but should not be upgraded to current. A historical claim needs dates and past-version context. A research claim needs papers or upstream research docs. A local experience claim can guide review but cannot close a public protocol claim by itself.
Next, read the source ID as a pointer to a public location. Source IDs are not decorations and not guarantees. A broad repository source may show where to look, but a function-level claim needs the exact file, function, or test that supports it. A release note can support release status, but it may not prove all mechanism details. A tooling repo can support tool behavior, not base-layer readiness.
Finally, decide one outcome: verify and upgrade, rewrite to match the source, move to Open Questions, or remove. Anything else risks laundering uncertainty into confident prose.