How RustPrint verifies code and technical claims

RustPrint does not treat generated code as correct because it looks plausible. Examples and technical claims have separate evidence paths, and the labels on a page describe which path applies.

SOURCE-BACKED

SOURCE-BACKED means the page is grounded in primary technical documentation linked on the page.

For the Rust standard library, that means official Rust documentation. For ecosystem crates used by a blueprint or recipe, RustPrint accepts the crate’s published Rustdoc on docs.rs and project documentation such as Tokio’s official site.

The label does not mean that every sentence is copied from documentation. It means the factual API and behavior claims have a primary source that can be checked.

CI-CHECKED

CI-CHECKED applies to a specific code region, not automatically to an entire article.

The rendered snippet is extracted from a real Rust source file under examples/. A registry connects the page region to that source file and records whether the example is only compiled or also asserted by a test.

The CI pipeline runs the example crates with the current stable Rust toolchain and checks:

cargo check
cargo test
cargo clippy -- -D warnings
cargo fmt --check

The documentation build also rejects a CheckedRustExample if its source region is missing, duplicated, outside a registered example crate, or claims a test that does not actually assert the region or explicitly validate it.

Expected compiler failures are checked too

Some error pages need code that is supposed to fail.

Those examples live separately under examples/compile-fail/. CI invokes rustc, requires compilation to fail, and checks that stderr contains the expected diagnostic fragments.

That prevents an error page from silently becoming wrong because a later compiler version starts accepting the example or reports a materially different failure.

Stable Rust is a moving target

The Rust example job installs the current stable toolchain on each run. A scheduled CI run repeats the Rust validation every week.

That catches one important class of content decay: code that used to compile but no longer does under the current stable ecosystem.

Dependency-based example crates also pin the versions they are documenting. A version update should therefore be an explicit change followed by CI, not an accidental result of a loose dependency range.

What the checks prove

A passing checked example can support claims such as:

this code compiles with the validated toolchain and dependency set
this asserted result matched during the test
the code passes the repository’s Clippy warning policy
the snippet displayed on the page comes from the checked source region

That is stronger than pasting code into Markdown and assuming it works.

What the checks do not prove

Compilation is not a security audit.

A green CI run does not prove that an example is:

secure for every threat model
the fastest possible implementation
appropriate for every scale or deployment model
free of operating-system-specific behavior outside the tested scope
compatible with future major dependency versions
a complete production architecture by itself

RustPrint should say when a sample is intentionally incomplete. The Axum REST API blueprint, for example, does not pretend that an in-memory store is a database layer or that graceful HTTP shutdown automatically cancels unrelated background workers.

Why the distinction matters

Technical content gets stale in several different ways. An API can change. A snippet can stop compiling. A diagnostic can change. A recommendation can remain syntactically valid while its operational assumptions become wrong.

One badge cannot cover all of those problems.

RustPrint therefore keeps the claims narrow:

source links support API and behavior explanations
CI supports executable examples
tests support specific observed results
explicit limitations describe what remains outside the verification boundary

If a page cannot say what supports a claim, the claim should be softened, sourced, tested, or removed.