Verification and Fact-Checking
Every TechDefused article passes through a multi-layered verification process before publication: a two-pass quality control architecture and a structured Knowledge Graph factfile that gives context-aware fact-checking its teeth. This page describes how that works in plain terms.
Last updated 13 May 2026
Why Verification Sits at the Centre
Coverage of fast-moving technology carries a higher cost of error than most beats. A misnamed model, a misstated parameter count, the wrong CVE severity, a confused product line, a fabricated quote — none of these are just editorial embarrassments. They can mislead a reader making a procurement call, an investment decision, or a patching decision that has security consequences.
Verification is the load-bearing piece of TechDefused's editorial operation, not an afterthought. It is the thing that lets an AI-assisted newsroom publish at scale without surrendering the accuracy commitments that make journalism worth reading.
Multi-Layered Verification
TechDefused verifies claims at multiple points, not just one. The structure mirrors the verification process documented on the authenticity page and is then extended with the two-pass QC architecture and factfile layer described below.
- Source selection. We aggregate from established, credible primary sources — vendor releases, S-1 / 10-K / 8-K filings, security advisories and CVE records, GitHub releases, model cards, official conference materials, on-record interviews — and from established news organisations with their own editorial standards.
- Cross-reference checking. Significant claims are verified against multiple authoritative sources where they exist.
- Technical accuracy review. AI, software, hardware, and semiconductor coverage undergoes specific technical fact-checking against primary documentation.
- Update monitoring. Breaking stories are monitored for corrections or updates from original sources, and our coverage is updated to match.
- Reader feedback integration. Reader-submitted corrections trigger immediate review — see the corrections policy for the full process.
The Two-Pass QC Architecture
Every article — AI-assisted Newsroom content and named-author contributor pieces alike — passes through a two-pass quality control architecture before publication.
Pass 1 — Editorial
The first pass is editorial: does this article stand up as a piece of journalism? Is the lede accurate? Is the framing fair? Is the headline supported by what the article says? Is the tone neutral? Is the structure right for the kind of news it is reporting?
Pass 1 also enforces the publication's editorial standards on attribution, fairness, and language — the standards documented on the ethics and editorial standards pages.
Pass 2 — Verification
The second pass is verification: are the claims in the article supported by the source material? Every claim has to be addressable to a specific span of source text. This is the structural check that catches:
- Fabricated quotes — quotes not present in the source
- Numerical drift — figures that don't match the underlying release (parameter counts, benchmark scores, funding-round sizes, user-count claims, process nodes)
- Misattribution — claims attributed to the wrong source
- Conflations — distinct products, models, or events combined into one
- Out-of-scope claims — assertions the source material doesn't make
- Timeline errors — releases, disclosures, or deal events placed in the wrong sequence or period
- Version-range drift — wrong affected-version ranges, wrong CVE identifiers, wrong severity ratings in security coverage
Pass 2 uses a combination of deterministic checks (does this number appear in the source? does this name appear in the source? does this version string appear in the advisory?) and AI-assisted review with explicit grounding requirements. The AI layer is not asked whether a claim is true in the abstract — it is asked whether the claim is supported by a specific, citable span of source text.
Unsupported claims are removed. Ambiguous claims — where the verification layer flags genuine uncertainty — are escalated to human review rather than published.
The Knowledge Graph Factfile Layer
Verification at the volume TechDefused operates at is only possible because we maintain a structured Knowledge Graph factfile on every covered entity — vendors, foundations, listed technology companies, and major open-source projects. The factfile layer is what makes context-aware fact-checking possible. Without it, Pass 2 can only verify a claim against the article's immediate source; with it, the pipeline can verify a claim against everything previously known and recorded about the entity.
What's in a Factfile
Each covered entity carries a structured factfile of seven facets, built and maintained from primary source material:
- Overview — what the entity does, what it ships, and how it positions itself in its market
- Management — founders, executives, board, and material personnel changes (CEO, CTO, head of research, key engineering leads)
- Assets — product lines, model families, IP portfolio, data-centre footprint, R&D position, and key infrastructure
- Timeline — material corporate and product events in chronological context: launches, funding rounds, acquisitions, major releases, security incidents, regulatory actions
- Strategy — stated direction, roadmap commitments, and capital allocation
- Finances — most recent reported figures, funding history, valuation, and balance-sheet position where disclosed
- Broker — sell-side and analyst-house coverage (Gartner, Forrester, IDC notes; equity research for listed names) and the consensus picture where one exists
The facets are deliberately broad. "Assets" for a model lab means model families and compute footprint; for a semiconductor company it means fabs, process nodes, and IP licences; for a SaaS vendor it means product surface area and enterprise customer base. "Broker" sits in the schema because some covered companies have material sell-side coverage that matters to readers; it also carries analyst-house notes for vendors where that is the more relevant external signal.
How the Factfile Feeds Verification
When a new article is being drafted on a covered entity, the factfile provides the structured context against which the verification layer compares the article's claims. This is how we catch, for example:
- An article that names the wrong CTO or head of research — the factfile knows who is in role and when they moved
- An article that misstates a recent product launch or model release date — the factfile carries the timeline
- An article that contradicts the previously-reported user count, ARR figure, or funding total — the factfile carries the most recent disclosed numbers
- An article that conflates two distinct model families, product lines, or open-source projects — the factfile distinguishes them by entity
- An article that attributes a security advisory to the wrong vendor, project, or affected version — the factfile carries the relevant CVE history and product surface area
The factfile is maintained continuously. New material — filings, releases, advisories, model cards, analyst notes, conference announcements — is checked into the factfile under the relevant facet, with the primary source preserved. The factfile is, in effect, the publication's institutional memory in a form the verification layer can actually use.
Primary Sources vs. Secondary Sources
Verification leans deliberately on primary sources over secondary ones. The hierarchy:
Primary (preferred):
- Vendor releases, official blog posts, and press kits
- S-1, 10-K, 10-Q, 8-K, and other regulatory filings
- Security advisories and CVE records from the issuing party
- GitHub releases, changelogs, and official release notes
- Model cards and benchmark publications
- Official conference materials and keynote recordings
- On-record interviews with named principals
Secondary (used with attribution and caution):
- Analyst commentary from Gartner, Forrester, IDC, and equity research
- Vendor PR and prepared spokesperson statements
- Trade press and other news organisations' reporting
- Industry surveys, league tables, and benchmarking studies
Secondary sources are useful for context and reaction but are not themselves the ground truth. The full sourcing standard sits on the sources page.
What Triggers Human Review
The QC layer is calibrated to escalate, not auto-reject, where uncertainty is genuine. Articles flagged for human review include:
- Claims where the source text is ambiguous between two plausible readings
- Material conflicts between an article's claim and the previously-known factfile position
- Coverage of complex or sensitive subjects — active security incidents and responsible-disclosure timelines, regulatory disputes, antitrust matters, personal-conduct issues affecting named executives
- Anything affecting individuals' reputation where right-of-reply considerations apply
- Anything the verification layer cannot resolve with high confidence
What Verification Doesn't Catch
Verification at this layer can confirm that an article's claims are supported by the source material it draws from. It is not omniscient. It cannot:
- Catch errors in the underlying source material itself. If a vendor announcement contains a wrong number, or an advisory carries an incorrect affected-version range, our coverage may inherit the error. When this surfaces, we correct on the same standards as any other error — see corrections.
- Replace the editorial judgment that decides whether a story is worth publishing at all.
- Replace the broader fairness and balance considerations that sit in the editorial layer — those are Pass 1's responsibility.
- Adjudicate genuinely contested questions where the facts are not yet known (an unverified vendor capability claim, a disputed benchmark result, an unresolved incident attribution). Where the position is contested, we report it as contested.
Honest framing matters here: the verification layer is a strong structural defence, not a guarantee. Errors that reach publication are corrected promptly when identified.
Reader-Submitted Corrections
The verification process is layered, but it is not perfect. Errors that reach publication are corrected promptly when identified — whether internally by the QC pipeline, by a coverage subject, or by a reader.
Reports go to corrections@newsdefused.com. The full process — what we correct, how corrections are formatted, response timeframes, and the corrections log — is on the corrections page.
Contact
Questions about our verification process, the two-pass QC architecture, or the factfile layer: corrections@newsdefused.com for reported errors; otherwise editorial@newsdefused.com for general editorial inquiries.