How We Test

Technical writing is full of commands that have never been run. This page says exactly what our testing claims mean, so you can calibrate how much to trust any given page.

Three levels, stated on every page

Every technical resource carries one of these states, shown in its metadata rather than left for you to infer.

Tested

The procedure was executed end to end in a stated environment, and the output shown was captured from that run. The page lists the exact versions of everything involved. A tested page shows a Tested procedure badge and a Tested with block naming versions.

Reviewed

The commands and configuration were checked by an engineer who works with the system, against primary documentation, but the procedure was not executed end to end for this page. Command output shown in a reviewed page is marked illustrative where it was not captured from a run.

Awaiting review

The resource is live and readable but has not yet completed technical or editorial review. It carries a banner saying so and is excluded from search indexes until review is complete.

There is no fourth state where we imply testing without doing it. If a page does not claim to be tested, it was not tested.

What gets recorded

For a tested procedure we record the versions that were actually in use — for example the operating system, container runtime, orchestrator, and the specific project release. A version list is only present when the run happened; it is not a statement of what the procedure “should” work with.

We also record three separate dates, because they mean different things:

Published — when the resource first went live
Updated — when its content last changed
Verified — when a human last confirmed it still holds

A resource with an old verified date is not necessarily wrong, but you should treat it with more suspicion, which is why the date is on the page rather than hidden.

Commands are treated as if you will run them

Every command on this site is written on the assumption that somebody will paste it into a production terminal, because eventually somebody will.

Destructive operations are marked before the command, not after it, and state what they affect.
Any procedure with a destructive step includes its rollback, and the rollback is written before the step is executed rather than left as an exercise.
Where a command’s effect depends on context — which host you are on, which tenant is selected — the context is stated explicitly rather than assumed.
We do not include a dangerous command as an illustration of what not to do without making that unmistakable.

Automated checks

Before publishing, an automated pass checks what a machine can check: that fenced JSON parses, that YAML parses, that shell blocks are syntactically valid, and that code blocks have not picked up copy-paste artifacts such as shell prompts inside a block meant to be copied whole.

These checks catch mechanical errors. They cannot tell whether a command is the right command, which is why they do not replace the human technical review.

What we cannot test

We are honest about the limits. We do not have a multi-rack GPU cluster, a large-scale production OpenStack deployment of every topology, or every cloud provider account. Where a claim comes from architecture and documentation rather than from a run in our own environment, the page says so and cites the primary source.

Where a number comes from a measurement, it appears in Research with its methodology and its data, not as an unsourced figure in a guide.

Editorial policy — what has to be true before we publish at all
AI use policy — where AI assists, and where a human is required