Skip to content
Code To Cloud

How we verify what we publish.

Technical writing about AI platforms goes stale quickly, and confident claims are easy to get wrong. This is what we check before we publish, and what to do if you find a mistake.

Last updated:

Our verification practices

  • Primary sources, not summaries

    Technical claims are checked against vendor documentation and, for open-source projects, repository metadata from the GitHub API. A search-result summary or a third-party write-up is a lead to follow up, never the source we cite.

  • Status stated plainly

    If a product is in preview, pre-1.0, or archived, we say so. We say "archived" only when the repository is archived, and "deprecated" only when the vendor says deprecated. Pre-1.0 dependencies are pinned and called out as pre-1.0.

  • Run it before we publish it

    Our open-source workshop was run end to end on a live subscription, on the date stated, with the tool versions recorded in its docs, including a clean redeploy from scratch. If we haven't run it, we don't present it as tested.

  • Results we can't share stay unpublished

    We don't publish client outcome numbers we can't share. A pattern drawn from the founder's own Microsoft-era experience is labelled that way, and is not presented as a client story. Where a page uses a composite example, it says it is a composite.

  • Credentials you can check

    Certifications, memberships and partner status are listed only where there is a source behind them, and we don't publish credential numbers. Claims we can't back with a checkable source stay off the site.

  • Structured data matches visible copy

    Every FAQ answer marked up for search engines also appears as readable text on the page. Marked-up answers that aren't visible are a structured-data violation, so the two are kept identical.

  • Dates you can see

    Blog posts carry a publish date, and the main service and guide pages show when they were last updated. Read a fast-moving product page with that date in mind.

  • Conversations are paraphrased

    When we describe a conversation with a practitioner at a real organization, we paraphrase it, drop identifying details, and check what was said against primary sources before treating it as fact.

Found something wrong?

Tell us which page and which claim. We correct the page and update its date rather than quietly editing it. Vendor products change quickly, so a claim that was true when written can age out.

Want this discipline on your platform?

The same standard applies to the work: evaluation gates you can read and rerun, and no claim we can't back.

Book a Discovery Call