Sources and scope About 1 min read

Source policy

Use original specifications and product documentation for technical claims. Record the edition, access date and limits of the source.

Sources and scopeRead before use

Navigation or project guidance; not a claim of product, standards or environment validation.

Verification and testing

What to record#

Keep the publisher, document title, edition or product version, URL and date accessed. Place the reference close enough to the claim that a reader can work out what it supports.

A vendor overview can establish that an interface exists. It usually cannot establish every operation, permission, rate limit or behaviour on every firmware release.

What counts as a source check#

Opening a page successfully is a link check. Reading the relevant material and matching it to a scoped claim is a source check. They are not the same result.

Where a standard is paywalled, say whether you reviewed the normative text or only the publisher's catalogue and public scope. Do not imply access to material you did not inspect.

Keep uncertainty attached#

When sources disagree, record the disagreement and the editions involved. Do not pick the more convenient statement or merge the two into an unsupported conclusion.

Community reports can identify a useful lead. Label them as reports and confirm the affected version before treating them as general product behaviour.

Review dates#

A source date applies to the claim and edition it supports. A wording change does not renew that date. Record later checks separately and say which version, lifecycle detail or behaviour was checked. Product testing needs its own environment and results.

Verification policy · Sources and scope