Connect with us

Fact-Checking Policy

The discipline, stated once

At WinAddons, verification has one meaning: the primary document. A claim counts as checked when we have read the material it rests on ourselves, not when we have found it repeated somewhere convincing. On this beat the primary material is unusually rich, because Microsoft documents nearly everything it does, and unusually easy to misread, because it documents the same thing in several places that do not always agree. This page describes how the discipline is applied to each kind of material our sections run on, and what happens when it fails.

What counts as a source

Sources sit in a hierarchy, and a claim’s weight depends on where its source sits. Highest are Microsoft’s own primary documents and what we observe ourselves: release notes and KB articles, build numbers read off the machine, MSRC advisories and the CVE records they cite, the Azure status page and its incident history, service level agreements, lifecycle and end-of-support pages, Microsoft Learn documentation, message center and roadmap entries with their identifiers, store listings, official blog posts, earnings releases and the filings Microsoft makes with securities regulators. Next are statements made on the record by people placed to know, identified by name and role. Beneath those are press releases, partner announcements and spokesperson statements, which prove what an organisation claims and nothing more. Lowest are hearsay, social media posts and anonymous claims: enough to send us looking, never enough to publish on.

One source will do for a fact that the source alone is placed to know and has no motive to misstate. A disputed or consequential claim needs either a document or a second source independent of the first. Two posts repeating one announcement are one source.

Windows updates and builds

  • Every update story names the KB number and the build number, and both are checked against the release notes as published, not against a summary. Where we can, we install the update and read the build number from the machine.
  • The known issues section of the KB article is read in full before publication and again before the story is updated, because that section changes after release more often than any other.
  • Servicing channel and version are stated precisely. A fix in one channel or one version is reported for that channel or version, not for Windows in general.
  • A reported failure becomes a failure when it is reproduced on a machine we control or confirmed by multiple independent reports with the same error on the same build. Until then it is reported as reports of a failure, with their number and source.

Xbox

  • Release dates, prices and editions are checked against the store listing in the market and currency named, and against the official announcement, and the story says which market it is quoting.
  • Subscription catalogue additions and removals come from official posts and the catalogue itself, with the date checked, because titles move in and out on a schedule that leaks and rumours regularly get wrong.
  • Hardware specifications come from the specification sheet or our own measurement. Sales and player figures are reported only from earnings materials, filings or official statements, with the period and the definition attached, and estimates are labelled as estimates.

Azure and cloud services

  • Outages are reported from the status page and the incident history, with start and end times as Microsoft records them and, where they differ, as customers report them, labelled accordingly. A post-incident review is quoted from the review itself.
  • Availability, retirement and pricing claims are checked against the service documentation, the retirement notice and the pricing pages for the tier and location in question. A service level agreement is quoted from the SLA document, including its exclusions.
  • A preview feature is reported as a preview, with what that status means for support and pricing.

Microsoft 365, Teams, OneDrive and Outlook

  • Feature stories carry the roadmap or message center identifier where one exists, and the status as documented: in development, rolling out, launched, or, where it applies, delayed or cancelled. Rolling out is not generally available, and a feature reaching some tenants is reported that way.
  • Licensing and eligibility are checked against the licensing documentation and service descriptions, and the story names which plans and which audience, consumer or commercial, a change applies to.
  • End-of-support and retirement dates come from the lifecycle pages and the official retirement notice, quoted exactly as published.
  • Storage quotas, sync behaviour and client changes are tested where we can test them and reported as documented where we cannot, with the distinction stated.

Security, business and numbers

  • A vulnerability story is checked against the MSRC advisory and the CVE record: identifier, severity, affected products and versions, whether exploitation has been observed, and the available mitigation. A vendor’s blog post about a flaw is a lead, not the advisory. Nothing that could help an attacker is published before a fix exists, as our editorial standards require.
  • Financial figures are checked against the earnings release and the filing for the period, and where they differ the filing wins. Segment names, reporting periods, constant-currency adjustments and the difference between guidance and results are stated. Percentages are checked against their base, movements are given with the before and after figures, and orders of magnitude are checked twice, since a billion mistaken for a million is the error that spreads fastest.
  • A figure that sounds astonishing is presumed wrong until it is confirmed; astonishing numbers are, more often than not, mistakes.

Screenshots, quotations and the process on every story

A quotation is verified against the recording, the transcript or the statement as written; cuts within it are marked, and its meaning is never changed. A screenshot is verified for the build, channel and settings behind it, and images that circulate on social media during a launch, an outage or a leak are held until their origin is established. The writer records the source of each factual assertion as the story is written. Before it is published, a second person goes through the story against that record, paying closest attention to build and KB numbers, dates, prices, version scope, security guidance and anything a reader might act upon. Stories that carry serious allegations, name private individuals, describe data-loss risks or give security guidance receive a further review, and a story that fails at this stage is held. Verification beats speed whenever the two collide.

Uncertainty, and what happens after publication

Not everything can be verified by deadline. In descending order of preference, we wait; we publish what is verified and say plainly what is not yet known; or, when the unverified claim is itself the news, we report that the claim exists, where it came from and which checks are still open. We never dress up uncertainty in phrases like it is understood. Nor does checking end at publication. A developing story is rechecked as new material arrives, errors that slip through are repaired under our corrections policy, and the correction log is combed for patterns that become new rules on this page. Anyone who spots an error, or who wants the source behind a factual claim we have made, can write to support@winaddons.com. Showing our sources is part of the job, not a concession.