radar-source-verify

name	radar-source-verify
description	Verify a signal or evidence candidate for the AI Radar ledger: open primary sources, pin exact dates and authors, check source independence, and classify the result as citable evidence or an unverified observation_queue item. Use whenever adding evidence to TRENDS.md, promoting a queue item, or fact-checking a claim found in search results.

Verify a source for the ledger

Goal: every evidence line in TRENDS.md has (a) a URL that was actually opened this session, (b) a real date, (c) one line of context.

Procedure

1. Find candidates with the tavily-search skill (--include-domains arxiv.org,github.com,huggingface.co for primary sources, --time-range for recency). Search snippets are never citable on their own.
2. Open each candidate with the tavily-extract skill. Opened = citable.
3. Pin dates — by source type:
   • Date by the NEWS EVENT: the evidence-line date is the date of whatever makes the item worth logging now — v1 for a new paper, the acceptance or latest-version date for an older paper that just got accepted/revised, the release date for software. Keep the other dates in the context line, e.g. "(v1 2025-11-12; accepted ACL 2026, v4 2026-04-16)" with the line dated 2026-04-16. This keeps the ledger's freshness machine-readable.
   • arXiv: curl -sL 'https://export.arxiv.org/api/query?id_list=ID1,ID2' gives exact v1/latest dates and the full author list (the abs page often hides them from extraction). Use https, not http.
   • GitHub: cite the latest release tag and its date, not the access date.
   • Hugging Face org pages: "updated X days ago" → compute the estimate and write "(date estimated from the org page)".
   • Undated pages: "(undated, accessed YYYY-MM-DD)".
4. Investigate the content and lineage — never judge by the surface. Do not accept or dismiss a signal on the first/oldest hit or a single date. Open the ACTUAL artifact the signal is about (not just the top search result), and trace the line: is there a newer version, a follow-up paper, a 2026 continuation? A research line can look "stale" only because your first hit is its oldest paper while a fresh one exists (e.g. a 2025 method with a 2026 follow-up). Judge freshness and relevance from the real, latest artifact, not from what the search surfaced first.
5. Independence check (for the ≥3-sources trend bar): sources must come from different orgs/author groups. Shared co-authors collapse two papers into one group — compare author lists before counting.
6. Classify:
   • Opened + dated + primary → evidence line: - YYYY-MM-DD — URL — one line of context
   • Not opened, or secondary-only → observation_queue line marked "unverified", stating exactly what is missing.

Red flags (queue or drop — never cite)

• SEO content farms, model comparators/aggregators, market-wire press syndication are never CITABLE — but they can POINT to a real primary artifact. Before discarding one, read what paper/repo/release it is actually about, verify that primary, and cite IT (never the SEO source). Don't let a clickbait wrapper hide a live underlying result.
• Releases claimed by aggregators but absent from the vendor's official channel (check the org's HF page or official blog index before believing them).
• Vendor-reported adoption numbers: citable, but label them "vendor-reported".