1 of 6

PROJECT INTRODUCTION

ProofLayer

Every claim, traced to its proof.

ProofLayer helps verify digital claims by organizing evidence and making source relationships transparent, designed for students, researchers, and journalists.

TEAM 404 Not Found

1 Keshov Dhanuka

2 Soumili Ghosh

3 Anupam Sahay

4 Shashwat Awasthi

2 of 6

Problem and Target Users

THE PROBLEM

Checking a claim is slow, manual, and opaque. Evidence is scattered across sources, often conflicting, and rarely labeled as support or contradiction.

WHO FACES IT

Students & researchers

Journalists & fact-checkers

Everyday internet users

Moderators & organisations

TODAY

Manual searches across many tabs. Fact-check sites help, but may not cover new or reworded claims.

WHAT IS MISSING

One workflow that links a claim to its evidence, separates support from contradiction, and shows uncertainty.

WHY IT IS WORTH SOLVING

58%

Concerned about distinguishing real from fake online news (2025) [1]

37%

Trust news overall; lowest level since tracking began in 2015 (2026) [2]

20%

Trust news from AI chatbots (2026) [2]

CASE IN POINT 11 Nov 2025: reports of actor Dharmendra’s death spread widely, even drawing a condolence post from a senior minister, until his family denied them. [3]

Sources: [1] Reuters Institute, Digital News Report 2025 · [2] Reuters Institute, Digital News Report 2026 · [3] Khaleej Times, 11 Nov 2025

3 of 6

What We Built

Evidence-First Claim Verification

1

User Input

A claim is submitted through the UI.

EXAMPLE CLAIM

“A new tax cut was announced for 2026.”

Submit

2

What the System Does

Retrieve

Google News, Wikipedia, DuckDuckGo

Classify

Qwen2.5-1.5B + LoRA labels each item

Uncertainty

Scores and rules flag unclear cases

Report

Sources, quotes, summary, graph (intended)

3

Intended Result

A report with classification, source evidence and uncertainty.

ILLUSTRATIVE OUTLINE

Classification

Source evidence

Uncertainty note

TECHNOLOGY STACK & INTEGRATIONS

React + Vite

Frontend UI

FastAPI

Python backend and API

SQLAlchemy + SQLite

Local database and persistence

PyTorch + PEFT

Model inference and fine-tuning

Qwen2.5-1.5B + LoRA

Evidence stance classifier

Retrieval sources

Google News, Wikipedia, DuckDuckGo

Pytest

Automated tests

Existing foundation

Frontend and backend structure

Retrieval / classification pipeline

Qwen adapter experiments

Automated tests

BUILD engineering work

Classifier tuning and evaluation

Class-balanced training data

API routes and provider logic

Connectivity and workflow audit

Future scope

Multimodal verification

Claim decomposition and dated evidence

Slide 3: What We Built. Walk left to right: input, system, intended result; then the stack; then status.

Flow: a claim is submitted through the UI; the system retrieves evidence (Google News, Wikipedia, DuckDuckGo, subject to working provider integrations); Qwen2.5-1.5B-Instruct with a LoRA adapter classifies each item as SUPPORTS, REFUTES or NOT ENOUGH INFORMATION; classification scores and decision rules help flag uncertain cases; the intended output is a report with classification, source evidence and an uncertainty explanation. The example claim and the result outline are illustrative, not real output.

Be clear: this is the intended end-to-end flow, not confirmation that every step currently works in the demo.

Stack: React + Vite, FastAPI, SQLAlchemy + SQLite, PyTorch + Hugging Face Transformers + PEFT/LoRA, Qwen2.5-1.5B-Instruct, Pytest. PostgreSQL/pgvector and the React Flow graph are not shown because they are not confirmed in the current build.

Status: ProofLayer was an existing project under continued development. Existing foundation: frontend, backend structure, retrieval/classification pipeline, adapter experiments and tests. BUILD engineering work: classifier fine-tuning and evaluation (Exp004: 85.60% accuracy, 76.66% macro F1 on a 500-example benchmark; a classifier result only, not end-to-end accuracy), class-balanced data, API routes and provider logic, connectivity and workflow audit. Future scope (on slide): multimodal verification; claim decomposition and dated evidence. Presenter caution (not on slide): connected claim submission, reliable live retrieval, provider fallback behaviour and final report and graph rendering still need verification, so do not call the workflow fully working until a real claim produces a report in the current build.

4 of 6

Working Demo & Results

Real screens from the current build: one claim, from submission to report

DEMO FLOW

Captured 2026-10-25 · one example claim

1

Submit a claim

Landing page with “Investigate a Claim”

2

Assessment

Sources disagree: 1 supports, 1 contradicts

3

Evidence graph

Supporting, contradicting and context sources

4

Research report

Original claim, atomic claim, rationale

Working in this demo

Claim sent; service result returned

Sources labelled supports, contradicts or context

Evidence graph and research report

Classifier training

11,205

training set

500

benchmark

Exp004 · Qwen2.5-1.5B + LoRA · classifier only

Slide 4: Working Demo and Results. These are real screenshots from the running frontend, captured 2026-10-25, for one example claim (Tata Electronics semiconductor factory in Assam).

Demo sequence: 1) Open ProofLayer and click Investigate a Claim. 2) Submit the claim; the Overview shows the assessment (Sources disagree: 1 source supports, 1 contradicts), tagged 'Data: Service result' and 'Judged by keyword heuristics', with the evidence list labelled Supports, Contradicts or Context and an Open source link for each. 3) Open the Evidence graph tab: supporting, contradicting and context sources arranged around the claim node. 4) Show the generated research report: original claim kept as submitted, atomic claim from decomposition, assessment and rationale.

Be precise about what this proves: a claim was submitted and a service result, evidence list, graph and report were rendered for one example. It is not an accuracy test. The live assessment is explicitly judged by keyword heuristics, so do not present it as the Qwen + LoRA classifier output. Many sources show 'date not provided'.

Classifier card (on slide): trained on 11,205 class-balanced examples and checked on a 500-example benchmark (Exp004, Step-500 checkpoint, Qwen2.5-1.5B-Instruct + LoRA). The accuracy and macro F1 figures were removed from the slide; if asked, they are 85.60% accuracy (428 of 500) and 76.66% macro F1, which are classifier benchmark numbers only, not end-to-end verification accuracy on real-world claims.

If asked about limitations (not shown on slide): the live assessment uses keyword heuristics, source dates are often missing, and this is one example claim, not a benchmark. The Qwen + LoRA classifier inside the live assessment, end-to-end accuracy on real claims, provider fallback and saved history are not yet verified. Retest the full flow before presenting it live; earlier debugging found CORS and provider-parsing failures.

5 of 6

Ingenuity and Technical Decisions

Thoughtful design · Practical choices · Honest limits

1

What's Thoughtful

2

How It Differs from a Chatbot

3

Key Decision: Qwen2.5 + LoRA

4

Challenge & Solution

Evidence first

Sources before stance

Three-way labels

Supports · Refutes · NEI

Honest labelling

Source and method tagged

Modular design

Each layer tested alone

Chatbot

ProofLayer

Answer basis

Learned memory

Retrieved evidence

Support shown

Bare assertion

Sources & quotes

Uncertainty

Direct answer

Allows NEI verdict

Inspectability

Hidden internals

Inspectable pipeline

1.5B

Qwen2.5 base parameters

r = 16

LoRA rank (alpha 32)

6 GB

RTX 3050 laptop GPU, local

How the classifier is built

FEVEROUS-derived training data

Qwen2.5-1.5B + LoRA adapter

SUPPORTS

REFUTES

NEI

Cheaper than full fine-tuning; model errors still need evaluation.

Balanced data · 11,205 examples

11,205

SUPPORTS

4,482

REFUTES

4,482

NEI

2,241

Integration fixes (CORS, JSON replies) need a full retest

Challenges

Weak NEI handling

CORS / preflight errors

Replies missing JSON

Misleading loader text

Slide 5: Ingenuity and Technical Decisions. These are design choices, not claims that each component is novel compared with existing fact-checking systems.

Panel 1: evidence first (finding information is separated from deciding what it implies); three-way labels (SUPPORTS, REFUTES, NOT ENOUGH INFORMATION) rather than forcing true/false; honest labelling (the UI tags the data source, e.g. 'Data: Service result', and the method, e.g. 'Judged by keyword heuristics', and keeps the original claim exactly as submitted); modular design so retrieval, model inference, API logic and UI can be debugged separately.

Panel 2: a conceptual comparison with a conventional chatbot, not a benchmark and not a claim of superiority over existing products. ProofLayer's column describes the intended approach.

Panel 3: instead of training a language model from scratch, ProofLayer fine-tunes Qwen2.5-1.5B-Instruct (about 1.5B parameters) with a LoRA adapter (rank 16, alpha 32, dropout 0.05) on FEVEROUS-derived SUPPORTS / REFUTES / NOT ENOUGH INFO examples, trained on a Lenovo LOQ laptop with an RTX 3050 (6 GB VRAM) and served locally with PyTorch and Hugging Face/PEFT. This lowers training and deployment cost versus full fine-tuning; it does not remove the need to evaluate model errors.

Panel 4: the classifier first needed better handling of insufficient evidence, so Exp004 used a class-balanced set of 11,205 training examples (SUPPORTS 4,482; REFUTES 4,482; NEI 2,241). The Step-500 checkpoint reached 85.60% accuracy and 76.66% macro F1 on a 500-example benchmark (classifier only). Separately, the frontend/backend workflow hit CORS/preflight errors, provider responses without the expected JSON, and misleading hardcoded loading text; these were investigated, and the full fix still needs a successful retest on a real claim.

Note: the slide shows the training mix as a chart and the classifier pipeline as a diagram. Accuracy and macro F1 are intentionally not on the slide; quote them (85.60% / 76.66%, classifier-only) only if asked.

6 of 6

Potential & Next Steps

Users · Value · Future · Readiness

1

Target Users

2

Value Proposition

3

Future Improvements

4

Real-World Readiness

Students & researchers

Journalists & fact-checkers

Digital media platforms

ProofLayer

Faster

evidence-backed claim verification

Traceable

transparent source relationships

Lower risk

reduced misinformation risk

Multimodal verification

Claim decomposition

Confidence calibration and conflict detection

Claim

A

B

C

Reliable live retrieval

1

End-to-end testing

2

Secure deploy & persistence

3

Larger-scale evaluation

4

Working demo → deployable product

Slide 6: Potential and Next Steps. Walk the four panels. 1) Target users: students and researchers, journalists and fact-checkers, and digital media platforms all feed into one evidence workflow (ProofLayer). 2) Value: faster, evidence-backed claim verification; transparent, traceable source relationships; reduced misinformation risk. These are intended benefits, not measured results. 3) Future improvements: multimodal claim verification (text, image and video inputs); explicit claim decomposition (one claim split into atomic claims); confidence calibration and conflict detection. The diagrams are illustrative, not working features. 4) Real-world readiness, in order: reliable live evidence retrieval; end-to-end integration testing; secure deployment and data persistence; larger-scale accuracy evaluation. Frame this as the honest remaining work between a working demo and a deployable product.