Fake News Detector

Help a user check one claim against a small, documented evidence collection. The system finds relevant passages and asks an AI API to explain whether the claim is supported, contradicted, or not established by those passages.

This selection remains a concept. On 10 October 2026, no matching claim-checking/fake-news repository was found in the accessible/public M2-King repository results. This does not establish that no private, differently named, or local project exists. No implementation was available for review, so data collection, the notebook, the proposed pipeline, and evaluation remain new work in this plan.

The webpage title is "Fake News Detector". The proposed core assesses individual claims against saved evidence; it does not claim universal or automatic detection of false news.

The handwritten idea obtains news through crawling or an API, gives a model checking rules, and explains results with correct information where available. It labels this option the easiest. This reference instead proposes a narrow, saved evidence collection with explicit Supported, Contradicted, and Insufficient evidence labels. Live news collection is deferred. The later third-choice ranking reflects anticipated evidence and evaluation work; it is not the original ranking or a benchmark. Confirm scope and ranking with the group.

• Problem: users struggle to compare a short claim with relevant source information.
• Target user: a student checking a public claim before sharing it.
• Input: one English claim and a local evidence CSV covering one narrow topic.
• Output: Supported, Contradicted, or Insufficient evidence, with an explanation and source references.
• Boundary: labels apply to the available evidence collection. They do not establish universal truth or accuse a person of deliberately lying.

Study Full Fact AI as a deployed application supporting fact-checking. Identify its real workflow and the role of human review. Do not assume our small prototype reproduces its performance or complete architecture.

Compare manual source checking with AI assistance. Examine information literacy, access to reliable information, source bias, errors, outdated evidence, accountability, and computational costs. SDG 16 can be relevant where the report explains the connection to reliable information and accountable institutions.

Primary starting point:

• Full Fact AI: Product and workflow

User claim
    -> NLP representation and similarity search
    -> Retrieve relevant evidence records
    -> Send claim and retrieved records to an AI API
    -> Supported / Contradicted / Insufficient evidence
    -> Display explanation, evidence IDs, URLs, and dates
    -> Save the result

The second stage must assess the supplied evidence. A prompt asking a model to "act as a detective" is not evidence retrieval and is not a separate AI technique.

Choose one narrow topic, such as public university announcements. Start with about 20-30 evidence records, with fields evidence_id, text, source_title, source_url, and publication_date. Keep saved source excerpts and verify them manually. Avoid restricted or private information.

1. Load and validate the evidence CSV.
2. Represent claims and evidence with NLP features and retrieve relevant passages.
3. Preserve dates, quantities, and negation such as "not"; these can change a claim's meaning.
4. Pass the claim and evidence to the API, requiring one of the three allowed labels and references to supplied records.
5. Validate the response structure and reference IDs, show sources, and save the assessment.

Similarity means wording overlap, not agreement or truth. The evidence-assessment stage must distinguish a supporting statement from a similar statement with a different date, quantity, or negation.

Create about 30 test claims, balanced across the three labels. Manually establish expected labels before running the system. Include paraphrases, changed numbers, changed dates, negation, absent evidence, and conflicting evidence.

Report label accuracy and a confusion matrix, inspect errors, and check whether explanations are supported by the cited records. Compare retrieval-only results, an API-only assessment without the collection, and the integrated approach. Do not treat the model's own judgement as the test answer.

Test invalid inputs and API failures. The system should not present an unsupported confident verdict when relevant evidence is missing.

Proposed success criterion: assessments are grounded in the supplied records, sources are traceable, and uncertainty is handled explicitly. The group should agree on a numerical target before testing and report whether it was reached.

Explain where evidence came from, how expected labels were established, how retrieval works, why similarity is not truth, how the API uses evidence, and what the three labels mean. Explain errors involving dates, numbers, missing context, and source quality.

Do not include unrestricted web searches, live social-media scraping, deepfake detection, full-article verification, or claims of universal truth detection. Do not include classroom summaries or spatial-audio features.

This has a clear social value and a transparent two-stage design, but it requires the most new data preparation. Choose it if the group is willing to build a trustworthy evidence set and spend substantial time examining wrong answers.