Editorial standards

The one rule above all others

Every factual claim has a primary source, a reproducible method, or it doesn't appear. Not softened, not hedged — removed. Numbers without provenance (“3x faster”, “most teams”, “60% of companies”) are deleted rather than rephrased. Where a claim survives, it carries an inline citation to the RFC, the official documentation, the post-mortem, or the paper — the primary source, not a blog post about it. The full source registry currently tracks 100+ sources, each classified by credibility tier.

No invented experience

We do not publish fabricated war stories. If an article says “we measured” or “we ran”, that claim must be backed by a published, reproducible artifact — otherwise the framing is explicit: “picture a service that…” for illustrative scenarios, documented behavior with citations for facts, and runnable harnesses so you can measure on your own hardware. This rule is machine-enforced: a build-time gate scans every article for unbacked first-person experience claims and fails the build if one appears.

Code that compiles, with failure paths

Every code sample is compiled through the production build pipeline before an article can ship — no pseudocode, no invented APIs. Meaningful examples show error handling and at least one realistic failure mode, because production code that only demonstrates the happy path is a tutorial, not a reference.

Benchmarks must be reproducible

We do not publish performance numbers we cannot show you how to reproduce. Benchmark content ships as a harness — hardware spec, workload profile, measurement tooling, and methodology disclosed — so the numbers that matter are the ones you measure on your own systems, not ours.

What the build enforces on every article

• Citation integrity — every inline citation must resolve to a registered source; a network check flags dead links and version-drift redirects (a “JUnit 5 guide” silently serving JUnit 6 docs is treated as a defect).
• Code compilation — all article code compiles through the real production pipeline.
• Provenance gate — unbacked first-person experience claims fail the build.
• Claim heuristics — unsourced percentages and multipliers are flagged for review.
• Link integrity — every internal reference must resolve.

Updates and corrections

The “Updated” date on an article marks the most recent substantive pass — a factual correction, a version refresh, or a re-verification against current sources. Articles are periodically re-verified because technical content rots: versions drift, APIs change, defaults move.

Found an error? Email [email protected] with the article URL and the claim. If you're right, we fix the article and bump its updated date; substantive corrections are acknowledged. Being corrected in public is cheaper than being wrong in public.

How AI is used

We use AI tooling to draft and edit. Every factual claim is then checked by a human against a primary source, and anything that can't be sourced is removed rather than softened. The standards on this page apply to every sentence regardless of how its first draft was produced — the accountability is human either way.

Sponsorship and independence

Sponsored work is disclosed in the first paragraph, always — readers never discover mid-article that a piece was paid for. The rigor does not drop for sponsors: same citation rules, same compile gates, same fact-verification. We write sponsored pieces ourselves (no vendor ghostwriting under our name), and we only promote products we'd recommend to our own readers. The full sponsorship terms are on Work With Us.

What we don't do

• No invented statistics, incident costs, or adoption numbers.
• No fabricated first-person incidents presented as ours.
• No “definitive guide to everything” titles that over-claim.
• No affiliate links disguised as recommendations.
• No publishing numbers we can't show you how to reproduce.

If you find this page and the site disagreeing, the site is wrong — tell us.