Editorial integrity policy

What I stand behind, and what I don't

Every article is written from hands-on experience or primary sources, not paraphrased from other blog posts. But this is one person writing across a wide surface, and technology moves fast. So the honest position is: the mechanisms and the reasoning are what I stand behind; specific version numbers, prices, product names and vendor benchmarks are a snapshot that ages. The dating fields below exist so you can tell which is which at a glance.

Where a claim comes from a vendor's own benchmark or marketing, I say so and treat it as directional rather than settled. Where a number is illustrative rather than measured, I label it an estimate. Where I got something wrong, I fix it and leave a dated note rather than quietly editing — see corrections below.

The dating fields on each article

Technical articles carry a small provenance block with up to five fields:

• Published — when the article first went live. This never changes, and it anchors period-accuracy: a 2022 article describing 2022 tools is correct, not stale.
• Updated — the last time the content itself was materially revised (a new section, a corrected claim). Reflected in the article's structured-data dateModified and the sitemap lastmod.
• Last verified — the last time I checked the load-bearing claims against current sources, even if nothing changed. "Verified, still correct" is itself useful information.
• Sources — links to the primary references (vendor docs, standards bodies, regulators) a claim rests on.
• Corrections — None, or a dated list of what changed and why.

Sources

Claims about a product's behaviour are checked against that vendor's own documentation — Microsoft Learn, dbt Labs docs, the Apache project docs, and so on. Regulatory claims are checked against the regulator: FinCEN for SAR timelines, not a summary of FinCEN. Where a research result is cited, it links to the paper, not to coverage of the paper. If I can't find a primary source for something, I either cut the claim or mark it explicitly as my own inference.

Corrections

When a factual error is found — by me, a reader, or a reviewer — I correct the article and record it in the Corrections field with the date and a one-line description of what changed. I don't silently overwrite, because a correction that leaves no trace is indistinguishable from never having been wrong, and that's its own kind of dishonesty. If a correction is significant enough to change a conclusion, it also gets called out near the relevant claim, not just in the footer.

Spotted something wrong? Mail dmansh@gmail.com with the article and the specific claim. Corrections that hold up get made and credited unless you'd rather not be.

Case studies and anonymisation

Client work is described under NDA, so engagements are given by sector and shape rather than name, and figures are either ones I measured or ones the client has since published publicly — never estimates dressed as measurements. Some case studies are explicitly composites: patterns from several engagements combined so nothing identifies a client. Where that's the case, the article says so at the top. A composite is labelled a composite; it is never presented as a single real engagement.

AI assistance

Some drafting and research uses AI tools. Every published claim is my responsibility regardless — nothing ships that I haven't checked against a source or against my own experience. AI speeds up the writing; it does not get to decide what's true here.