# How RustPrint verifies code and technical claims

> What SOURCE-BACKED and CI-CHECKED mean, what RustPrint actually validates, and which claims the verification system does not make.

HTML: https://rustprint.com/methodology/

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:

```text
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](/blueprints/axum-rest-api/index.md), 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.

## Related RustPrint guides

- [Production-oriented REST API with Axum](/blueprints/axum-rest-api/index.md): A checked Axum 0.8 service skeleton with typed state, JSON handlers, HTTP error responses, in-process tests, structured tracing, and graceful shutdown.
- [Rust formatting reference](/reference/rust-formatting/index.md): A practical map of Rust format strings, formatting traits, width, alignment, precision, number bases, output macros, and the pages that explain each rule.