Skip to main content
QuantLab Logo
Fact-Checking Policy

How we verify every claim before publish

We try to write the kind of post we would want to read — opinions backed by sources, numbers with provenance, corrections when we get something wrong. This document is the working checklist a reviewer holds a draft against.

Last updated:

Source hierarchy

Tier 1 — Primary

Default tier for any technical claim, statistic, compliance requirement, or pricing range. Always cited inline when a specific number or rule is asserted.

  • ·Government agencies (.gov, .mil) — NIST, CISA, FTC, IRS, SEC
  • ·Standards bodies — OWASP, MITRE ATT&CK, ISO, PCI Security Standards Council
  • ·Academic — peer-reviewed journals, .edu publications
  • ·Official vendor documentation — Stripe Docs, AWS docs, Vercel docs
  • ·Public regulatory filings — SOC 2 audit reports, 10-Ks, SOS records

Tier 2 — Established secondary

Acceptable when no primary source exists, or to provide context. Always cited with publisher and date.

  • ·Recognized industry publications with editorial standards (e.g. The Verge, Ars Technica, IEEE Spectrum)
  • ·Research firms with disclosed methodology (Gartner, Forrester, Stack Overflow Developer Survey)
  • ·Open-source project maintainer notes and release announcements

Tier 3 — Lived engagement evidence

Used where the post is explicitly written from inside the work. We attribute as 'in our 2026 engagements' or 'across the quotes we have reviewed' so the reader knows the source is operational experience, not a published benchmark.

  • ·Quotes we issued or received during real RFPs
  • ·Production benchmarks from live systems we built
  • ·Pentest findings from completed engagements (always anonymized)

Avoided

If we cannot trace a claim back to a Tier 1 or Tier 2 source, we either omit it or rewrite the assertion as something we can stand behind from lived engagement (Tier 3).

  • ·Generic 'experts say' attributions without a named source
  • ·Marketing blog posts citing other marketing blog posts in a circle
  • ·Statistics whose original source cannot be located

The fact-checking checklist

  1. 1. Author source pass

    Before submitting for review, the author annotates every factual claim with the source candidate they used to write it.

  2. 2. Reviewer source verification

    The reviewer opens every cited URL, confirms the source supports the claim as stated, and validates the date and publisher attribution.

  3. 3. Numbers, ranges, and pricing

    Specific numbers (penetration test cost, SaaS prices, latency benchmarks) get extra scrutiny. We prefer ranges with a stated source over single point estimates with no source.

  4. 4. Names, titles, and entities

    Every proper noun (company names, product names, framework versions, people's titles) is verified against the entity's own current website or filing.

  5. 5. Compliance and regulatory claims

    Any claim about SOC 2, HIPAA, PCI DSS, GDPR, etc. is checked against the current standard text, not a summary. Where the standard is ambiguous, we say so.

Quoting clients and case studies

Client testimonials are only published after written sign-off. Until that sign-off arrives, the case study runs without a quote. We do not paraphrase a client's words and present the paraphrase as a quote.

Case-study outcomes (percentages, hours saved, revenue impact) are sourced from the client's own data or from our shipped instrumentation. Where we cannot verify a number, we either say so ("estimated") or leave it out.

Corrections & updates

When we get something wrong, the workflow is:

  1. Acknowledge the error to the reporter within 5 business days.
  2. Update the post in place with the corrected text.
  3. Add a dated "Correction" line at the bottom of the post describing what changed.
  4. Re-issue the article's dateModified in the JSON-LD schema.

If a post is materially wrong from premise to conclusion, we retract it — leave the URL live with a clear retraction note at the top, and remove the original copy. We do not silently delete URLs.

Report an error

Email beltz@quantlabusa.dev with the post URL, the specific claim, and (if available) a source that supports the correct version. Reports go to the founder; corrections are made by the editorial team within the timeline above.

Read the editorial policy

Full authorship, review, AI disclosure, and conflict-of-interest standards.