Editorial Policy

Last updated: May 11, 2026

This page describes how RackNotes writes, researches, edits, and corrects articles. It exists because in 2026, “tech blog” can mean anything from a careful publication to an AI-generated content farm — and the difference matters to readers. The standards below are stated openly rather than left to guesswork.

How articles get written

Most articles on RackNotes follow this workflow:

  1. Topic selection. Driven by what is genuinely useful — questions practitioners actually have, gaps in existing coverage, things that would have helped earlier in our own learning. Not by keyword volume alone.
  2. Research. Vendor documentation, peer-reviewed benchmarks where they exist, technical forums (Reddit r/Proxmox, mailing lists, GitHub issues), official changelogs, and primary sources. Building articles on top of other articles is avoided where possible.
  3. Drafting. Articles are typically drafted with AI assistance — large language models (LLMs) for structure, initial wording, and helping organize complex topics. This is disclosed because (a) it’s true, (b) the alternative is hiding it, and (c) the editorial layer that follows is what determines whether the article is worth reading — not whether an LLM touched a draft.
  4. Editorial review. Every article is read end-to-end by a human editor before publication. This is where claims get verified, vague statements get tightened, version numbers get checked, and anything that smells like AI hallucination gets cut.
  5. Fact-checking. Specific technical claims (version numbers, pricing, feature availability, configuration details) are verified against current vendor sources. When something cannot be verified definitively, it’s either stated as such or removed.
  6. Publication. Articles are published only after the editorial pass. Unsupervised AI output is not published.

What we test vs. what we research

Articles fall into one of two categories, and the difference is made clear in the article itself:

  • Lab-tested. Based on actual deployments in our test environment. Includes screenshots, specific hardware/software versions, and real failure modes encountered. These articles are explicitly labeled and identify the test setup.
  • Research-grounded. Based on documented sources, vendor specifications, and community-reported experience — not personal testing. These articles are framed as analysis and decision-support, not as “I deployed this and here’s what happened.”

Research-grounded articles are not framed as first-person experience. Fabricating “in my 15 years of deploying X” when this hasn’t happened is something other publications do. RackNotes does not.

Source standards

Sources treated as reliable:

  • Vendor official documentation and changelogs
  • Peer-reviewed or methodologically transparent benchmarks (e.g., Phoronix, Blockbridge, Anandtech-style testing)
  • Government, academic, and standards-body publications (NIST, IETF, RFC documents)
  • Primary news sources (The Register, Ars Technica, ServeTheHome) for industry events
  • Active community forums where claims can be cross-checked (Reddit subreddits with high engagement, official mailing lists, GitHub issues)

Sources avoided or used with skepticism:

  • AI-generated summaries of other articles (the “summary of summaries” problem)
  • Content farms, low-engagement listicles, SEO-driven aggregator sites
  • Vendor marketing pages presented as objective analysis
  • Unverifiable single-anecdote forum comments without corroboration
  • Outdated documentation (dates are checked)

Fact-checking process

For specific technical claims, at least two sources are cross-referenced where possible. Version-specific behavior is verified against the actual version mentioned. When information is contested or unclear, it’s flagged explicitly rather than picking the convenient answer.

If a claim depends on assumption rather than verifiable fact, it’s either removed or labeled as our analysis rather than established fact.

Corrections policy

When something is wrong, corrections are visible:

  • Articles include a “Last updated” date that’s revised when meaningful changes are made
  • Significant corrections are noted with a brief explanation of what changed and why
  • Factual errors are fixed, not silently rewritten
  • If a correction changes the article’s conclusion, this is stated clearly

If you spot an error, tell us. Getting it right matters more than winning an argument.

What we don’t do

  • No keyword stuffing. Articles are written for readers, not for search engine density metrics. If an SEO tool says we need to repeat “proxmox vs esxi” eight more times, that suggestion is ignored.
  • No clickbait headlines. “ULTIMATE GUIDE,” “You Won’t Believe,” and similar formulas are off the table. The headline should accurately describe the article.
  • No fabricated experience. When something hasn’t been personally deployed, RackNotes doesn’t pretend it has. Articles are framed honestly as either tested or researched.
  • No vendor-pleasing reviews. If a product is mediocre, RackNotes says so — even when there’s a commission attached (in the future, when affiliate relationships become active). If a vendor with an affiliate relationship does something bad, it’s covered like any other vendor.
  • No undisclosed sponsored content. RackNotes does not currently publish sponsored articles. If sponsored content is ever published, it will be labeled clearly at the top, not buried in a footer.
  • No filler listicles. “10 Best X” articles get written when there’s a genuine reason for that format, not as generic SEO bait.
  • No content outside competence. Topics where there’s neither deployment experience nor strong reference material are avoided. There’s enough confident-sounding nonsense online already.

Affiliate independence

RackNotes does not currently have active affiliate relationships. No articles on the Site contain affiliate links as of the date above. See our Affiliate Disclosure for the current state of monetization.

When affiliate links are introduced in future articles, the following principle applies: editorial decisions are made before commercial relationships are considered. If a product is bad, RackNotes says so — even with a commission attached. Affiliate articles will include an inline disclosure at the top.

Reader feedback

If you spot a factual error, have a question about how something was sourced, or want to push back on a claim — please do. Use the contact form. Reader corrections are how publications get better, and they’re treated seriously.

For business inquiries (sponsorships, partnerships, content licensing), use the same form with “Business” in the subject.

Changes to this policy

This Editorial Policy is updated as practices evolve. The “Last updated” date at the top reflects the most recent revision. Significant policy changes are summarized here so readers can see what changed.