Rumor → Reality Launch Radar

Leadership layer

Decision Tradeoffs

Use a small, explicit company set instead of pretending to cover the entire market
Require an official evidence path for confirmed status
Let one slow source degrade independently rather than fail the complete scan

Governance Model

Keep the classification rubric visible in the interface
Link each confirmed result to the supporting evidence
Cap each scan and prevent overlapping runs

Architecture evolution

Before

Rumor-level chatter and official announcements lived in separate feeds.
A reader had to compare timestamps and sources manually.
Confidence judgments were difficult to inspect or reproduce.

After

Signals are grouped into Watching, Likely, and Confirmed states.
Official newsroom evidence is kept distinct from social chatter.
Each result exposes the evidence path behind its classification.

Rumor → Reality Launch Radar asks a narrow question: has a startup rumor actually been confirmed yet?

The build

The prototype gathers rumor-level chatter, compares it with official company signals, and returns one of three states: Watching, Likely, or Confirmed. Each result keeps its confidence and supporting evidence visible instead of presenting an unexplained score.

Why it works as a portfolio proof

The interesting part is the operating loop: collect, normalize, retrieve, classify, and explain. The interface makes the evidence boundary legible while the backend handles source failures and overlapping scans without collapsing the full workflow.

Public truth boundary

This is a live hackathon prototype, not a production market-intelligence service. It covers a deliberately small target set, and its classifications are only as current as the latest completed scan. The public code and live build are linked above.

Stack

Node.js, Express, Apify, Elasticsearch Serverless, hybrid retrieval, ES|QL, and server-sent events.