Bollocks Radar dossier

Product summary

Fact: Bollocks Radar is a local-first claim search and fact-check source ingestion platform.

Fact: The project dossier describes it as in-development, in mvp-build, with a public search UI, protected admin console, Cloud Run source worker, Postgres state, Cloud Tasks, and bounded Google Fact Check ingestion.

Intended users

• People who want to search a claim before sharing it.
• Journalists, researchers, and fact-check readers looking for source attribution.
• Operators managing fact-check source ingestion and publisher sweeps.
• Future users of public trust-signal widgets or APIs.

Problem being solved

Fact-check metadata exists across publishers and APIs, but ordinary users need a fast, cautious way to search claims and see source evidence. Bollocks Radar is designed to show what fact-checkers have reviewed without claiming that no match means a claim is true.

Current status

Fact: The current docs describe an MVP architecture with Cloudflare public/admin apps, a Cloud Run source worker, Google Cloud Scheduler/Tasks, Postgres summaries/state, Cloud Storage raw payloads, and optional BigQuery append-only analytics.

Fact: Google Fact Check Tools API is the primary MVP source.

Known aims and strategic intent

• Provide a slick visual claim intelligence dashboard rather than a dry misinformation database.
• Show clear source attribution, conservative verdicts, and methodology notes.
• Support search, claim details, topic/country filters, publisher sweeps, and scheduled source refreshes.
• Avoid wording that implies the product is an oracle.

Built functionality

Fact: Source docs describe:

• Verdict enum and conservative verdict mapping.
• Google Fact Check request parameter mapping and normalisation.
• Source client boundary split between cloud-agnostic core and worker-specific HTTP/runtime code.
• Cloud Run worker that validates payloads, claims jobs, paginates, stores raw pages, records fetch attempts, and persists summaries through Postgres.
• Postgres tables for reviews, clusters, publishers, trend signals, ingestion runs, fetch attempts, job states, and admin audit/refresh state.
• Publisher discovery and scheduled publisher sweeps.
• Broad query sweeps and user search refresh flow.

Key apps, workers, packages, and services

Surface	Role
apps/websites/web	Public search/report UI and safe public API routes.
apps/websites/admin	Operational admin summaries and diagnostics.
apps/workers/source-worker	Cloud Run worker for Google Fact Check ingestion and queued work.
packages/works/core	Domain types, schemas, normalisers, scoring, public view models.
packages/works/gcp	Postgres, Cloud Storage, Cloud Tasks, Secret Manager, logging, worker runtime adapters.

Data sources and integrations

Fact: MVP source is Google Fact Check Tools API.

Fact: Near-term enrichment ideas include GDELT DOC 2.0, DataForSEO Trends, YouTube Data API, Wikidata SPARQL, Google Cloud Vision Web Detection, and possible fact-check image search.

Fact: Runtime providers include Cloudflare Workers, Google Cloud Run, Cloud Tasks, Cloud Scheduler, Cloud Storage, Postgres/Neon, Google Secret Manager, and optional BigQuery.

Deployment and runtime assumptions

• Public web and admin web are separate Cloudflare Worker surfaces.
• Admin production exposure requires Cloudflare Access.
• Source work belongs in Cloud Run, not public/admin request handlers.
• Cloud Tasks dispatch bounded jobs.
• Postgres stores summaries, state, and raw object pointers only.
• Raw payloads belong in Cloud Storage.
• Google Fact Check API calls require FACT_CHECK_API_KEY; fixtures remain for local fallback.

Reusable capabilities

Capability	Reuse potential	Notes
Source ingestion boundary	High	Pure normalisation in core, HTTP/runtime in worker. Useful for many provider integrations.
Task claim and fetch attempt model	High	Similar to SiteIntel task locks and DataStitcher run state.
Publisher cadence and sweep logic	Medium	Reusable for feed/provider source monitoring, but source semantics differ.
Verdict normalisation	Medium	Product-specific, but trust-signal products need this style of conservative mapping.
Claim clustering and source attribution	Medium	Could feed public-good or trust widgets if evidence wording remains careful.

Notable design patterns

• Public API returns local results first and may queue refresh without blocking.
• No public request should block on slow enrichment.
• Fact-check no-match must not be presented as proof of truth.
• Raw external payloads never surface through UI routes.
• API fetch attempts record safe metadata but not keys, headers, raw payloads, or unhashed IP addresses.

Dependencies on other products or Meridian tooling

Fact: Bollocks Radar follows Meridian deployment/config conventions and generated operations docs.

Inference: The ingestion/run-state pattern can inform a shared Works ingestion model, while claim and verdict domain logic should stay local.

Risks and unknowns

• Google Fact Check API is a search API, not a complete feed.
• Query-family design can bias what appears "on the radar".
• Trend, topic, publisher, and country filters need cautious interpretation.
• Any future media verification or AI layer needs very careful confidence wording.
• Public claim products carry reputational and legal risk if wording is sloppy.

Near-term next steps

• Finish the MVP public flow: radar overview, search, claim detail, filters, local save/hide, and source attribution.
• Keep the "no match means unknown" rule prominent in UI and generated copy.
• Add generated capability/reuse metadata once the ingestion and clustering model stabilises.
• Revisit whether source-client normalisation belongs in a shared pattern after another provider integration repeats the same shape.

Longer-term product potential

Opportunity: Bollocks Radar can be a public-good tool, a lightweight public search product, a widget/API for trust signals, or a specialised claim monitoring product for journalists and communicators.

Opportunity: The evidence-first source model can combine with SiteIntel trust/reference feeds or DataStitcher public audit source work, as long as claims remain carefully worded.

AI notes

• Do not describe the product as a truth oracle.
• Do not infer truth from no match.
• Do not expose raw source payloads or keys.
• Keep verdict mapping conservative and source-attributed.
• Promote shared code only after another product needs the exact same ingestion boundary.

Source coverage

Coverage is strong for MVP architecture, Google Fact Check ingestion, Postgres model, and deployable units. Product Compass did not inspect implementation source files beyond docs in this pass.

Sources consulted

• projects/bollocks-radar/README.md
• projects/bollocks-radar/apps/websites/docs/metadata/project-dossier.json
• projects/bollocks-radar/docs/overview/product/product-vision.mdx
• projects/bollocks-radar/docs/architecture/system-overview.mdx
• projects/bollocks-radar/docs/architecture/service-boundaries.mdx
• projects/bollocks-radar/docs/codebase/apps-workers-packages.mdx
• projects/bollocks-radar/docs/reference/technical/google-fact-check-ingestion.mdx
• projects/bollocks-radar/docs/reference/technical/postgres-data-model.mdx
• projects/bollocks-radar/docs/operations/deployable-units.mdx