This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

Receipts, Not Rumors is a research workspace for when the internet is arguing about something and you just want to know what's actually sourced.

You dump in the mess: screenshots, copied posts, links, your own notes. It turns that into an organized evidence trail:

• Screenshots are read with OCR, so the text inside is searchable.
• Links are fetched and their content is pulled in.
• A local AI model builds a chronological timeline, flags what is direct evidence vs. a reported claim vs. someone's interpretation, and lists what remains unknown.
• A visual timeline shows each event as a dot on a horizontal line. Hover for a one-line summary and confidence level, click to jump to the source it came from.

The AI is told to never invent dates, quotes, or URLs, to treat search snippets as leads rather than proof, and to avoid inferring private relationships from ambiguous posts. Its "bottom line" is deliberately cautious.

Who gets to be lazier? Anyone who has spent an evening with 40 tabs and a pile of screenshots trying to work out "wait, who posted first?"

Demo

There's also a Try demo button that loads a clearly fictional scenario, so you can see the whole flow without using real people's posts.

Code

[GitHub repo here:

stargalax / receipts-not-rumors-web

Receipts, Not Rumors

Drop the mess. Get the evidence trail.

A local-first research workspace for when the internet is arguing and you just want to know what's actually sourced. Paste screenshots, links, copied posts, and notes, and it organizes them into a sourced, chronological timeline, with the uncertainty left in.

Features

• Screenshot OCR: text inside images is extracted in the browser with Tesseract.js.
• Link fetching: pasted URLs are fetched server-side and their readable text and publish date are extracted.
• Web search: the model writes up to three search queries, and SerpAPI returns public results as extra sources.
• AI timeline: a local Qwen model separates direct evidence, reported claims, and interpretations, and lists what remains unknown.
• Visual timeline: events appear as dots on a horizontal line. Color shows confidence, hover shows a one-line summary, and click opens the source.
• Guardrails: the model must not invent…

View on GitHub

]

How I Built It

• Qwen2.5-1.5B-Instruct (open weights) runs entirely in the browser through WebLLM and WebGPU. No inference server and no API bill.
• Tesseract.js does OCR on screenshots, also in the browser.
• React + Vite for the frontend.
• A small Express backend with two jobs:
  • /api/search calls SerpAPI. Qwen first writes up to three search queries from the evidence, and the backend runs them so the API key never reaches the browser.
  • /api/fetch-page fetches pasted links and extracts readable text with Cheerio. A browser can't do this itself because of CORS. It refuses private/local addresses and checks every redirect.

The flow is: collect evidence, let Qwen plan searches, add the public results as new sources, then have Qwen build the timeline using only the supplied source IDs. After the model replies, the code validates its output. Any source ID the model made up is stripped or labeled "Unknown source", so the model can't cite something that doesn't exist.

Search results are tagged as unverified snippets, and a page that failed to load says so on its source card instead of quietly counting as evidence.

Why Does Open Innovation Matter?

This tool handles screenshots of people's posts and half-formed theories about them. Sending all of that to a closed API felt wrong, so the analysis stays on the user's machine. The evidence and the reasoning never leave the browser. Only the short search queries and pasted links go through my backend.

Open weights made that possible. A small open model that runs locally through WebLLM means no per-request cost, no usage logs on someone else's server, and nothing that disappears if an API changes its terms. The tradeoff is real: a 1.5B model is small, so it sometimes leaves dates empty or writes generic explanations. I handled that by validating its output and falling back to dates from the sources themselves. For this use case, a modest model I can trust with private material beats a stronger one I can't.

(Honest note: web search still uses SerpAPI, which isn't open. That's the one closed piece, and it's easy to swap for a self-hosted search option.)

Partner Category used

- Best Use of SerpApi : I used SerpApi to help the model get more insights regarding the question asked by allowing it to surf the web