DEV Community: Chetan Bhandari

Live fact checker

Chetan Bhandari — Fri, 16 Oct 2026 14:10:23 +0000

Live Fact-Checker: Verify Spoken Claims in Real Time

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

Live Fact-Checker is an AI-powered fact-checking system designed to help people evaluate factual claims made during live conversations, presentations, interviews, podcasts, and discussions.

Misinformation can spread quickly, and manually checking every statement takes time. Live Fact-Checker aims to make fact-checking faster by connecting speech transcripts to claim extraction, evidence retrieval, and structured verification.

The system follows a modular pipeline:

Speech transcription: The intended pipeline accepts transcripts from a real-time speech-to-text service such as AssemblyAI.
Claim processing: A claim extraction module identifies factual assertions from the transcript.
Evidence retrieval: The verification subsystem generates search queries and retrieves evidence from a configurable search provider such as Tavily.
Fact verification: The checker compares claims with available evidence and returns one of three verdicts: TRUE, FALSE, or UNVERIFIABLE.
Live updates: A FastAPI backend routes validated events through WebSockets so connected frontend clients can receive transcript, claim, and verification updates.

An important design principle is that the system should not guess when evidence is missing or conflicting. Instead, it returns an unverifiable result.

The backend also includes an offline mock pipeline, allowing developers to test the event flow without requiring external API credentials.

Who could benefit?

Journalists and researchers checking factual statements.
Students and educators evaluating claims during discussions.
Podcast and content creators reviewing spoken information.
Organizations that need assistance reviewing factual claims in meetings or presentations.

The long-term goal is to turn this into a practical tool for individuals and organizations that need faster, evidence-based fact-checking.

Demo

Project repository: https://github.com/chetanbhandari01/live-fact

The backend can be run locally using FastAPI and Uvicorn. Its API documentation is available at /docs when the server is running, and the mock pipeline demonstrates the verification event flow without external services.

A deployed demo or video demonstration can be added here once available.

Code

Explore the source code and project documentation:

GitHub: https://github.com/chetanbhandari01/live-fact

The repository contains two main modules:

backend/ — HTTP API, session management, WebSocket connections, event validation, routing, and structured logging.
verification/ — query generation, evidence retrieval, claim verification, structured results, and mock test scenarios.

The project is designed around clear module boundaries so that speech transcription, claim extraction, and verification can evolve independently.

How I Built It

I built Live Fact-Checker using Python and a modular, event-driven architecture.

Core technologies:

Python: Main implementation language.
FastAPI: HTTP API and WebSocket server.
Pydantic: Validation of structured events and verification results.
WebSockets: Real-time event delivery to connected clients.
Tavily: Configurable web search provider for retrieving evidence in real-verification mode.
AssemblyAI: Intended integration for real-time speech transcription.
LLM gateway: Configurable integration point for claim extraction.
Pytest: Automated tests for event contracts, verdicts, error handling, and pipeline behavior.

The architecture separates responsibilities into independent stages. The backend does not directly call an AI model; instead, it routes events through adapter interfaces. This makes it easier to replace components without rewriting the entire system.

I also implemented an explicit verification policy:

Return a supported verdict when the evidence is sufficient.
Return UNVERIFIABLE when evidence is missing, weak, or contradictory.
Preserve claim identifiers throughout the pipeline.
Return structured errors when a required service or credential is unavailable.
Avoid fabricating source URLs or silently replacing failed live retrieval with mock evidence.

The offline mock pipeline is useful during development, while the real search provider can be configured through environment variables.

Why Does Open Innovation Matter?

Open innovation made it possible to build this project by combining independently developed tools and modular components instead of relying on a single closed platform.

Using open-source frameworks such as FastAPI, Pydantic, and Pytest gave me control over the architecture, validation rules, testing, and integration boundaries. The adapter-based design also makes it possible for other developers to contribute alternative claim extractors, search providers, speech recognition services, or verification strategies.

A closed API might provide a convenient end-to-end solution, but it can limit control over internal behavior, provider choices, cost structure, and customization.

For a fact-checking application, transparency and adaptability matter. Developers should be able to inspect how evidence is retrieved, understand why a verdict is returned, and improve the system when they discover weaknesses.

Open innovation also creates opportunities for collaboration: contributors can improve individual modules, add test cases, evaluate verification quality, and make the tool more useful for different communities.

My goal is to keep Live Fact-Checker modular, extensible, and honest about uncertainty.

Final Thoughts

Building Live Fact-Checker has helped me explore how real-time systems, AI integrations, evidence retrieval, and backend engineering can work together to address a practical problem.

There is still room to improve the user experience, evaluate verification accuracy against a broader range of claims, and strengthen the end-to-end live demonstration.

I hope this project can grow through open-source collaboration into a useful tool that helps people question claims, examine evidence, and make more informed decisions.

Contributions, feedback, and suggestions are welcome!This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle

Expense Tracker: Private AI-Powered Spending Insights with Gemma 3 4B

Chetan Bhandari — Sun, 04 Oct 2026 11:50:26 +0000

Expense Tracker — Local AI Spending Insights

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I built Expense Tracker, a modern Android personal-finance application designed to help people manage their money and understand their spending more easily.

I built this for My friends and family members, who wanted a simple way to track their expenses and understand where their money was going each month.

The application combines complete expense management, budgeting, financial analytics, and local AI-powered spending insights in one privacy-focused application.

The application allows users to:

Track income and expenses
Manage multiple accounts
Organize transactions using categories
Track transfers between accounts
Set and monitor monthly budgets
View transaction history
Analyze daily, weekly, and monthly spending
View category-wise spending
Compare income and expenses
Analyze savings
Select a specific month for analysis
Generate AI-powered spending insights
Identify high-spending categories
Identify over-budget categories
Understand changes in spending patterns
Receive natural-language suggestions based on their financial summary

The Problem

Traditional expense trackers are good at showing numbers, charts, and categories, but users still have to interpret that information themselves.

For example:

Food       ₹8,000
Shopping   ₹7,000
Transport  ₹4,500
Bills      ₹6,000

The user can see the numbers, but may still ask:
Why did my spending increase this month?

Which category should I pay attention to?

Am I spending more than my budget?

What changed compared with last month?

Expense Tracker answers these questions using local AI.
The AI Spending Insights feature converts the selected month's financial summary into a concise natural-language explanation.

🎥 Demo Video:
https://youtube.com/shorts/0Nnaxn9Q2bg?feature=share

The demo shows:

Adding income and expenses
Managing financial transactions
Viewing the Analysis screen
Selecting a specific month
Generating AI Spending Insights
Receiving an explanation from Gemma 3 4B
Changing the selected month
Generating month-specific AI analysis

GitHub Repository:
https://github.com/chetanbhandari01/Expense-Trackers

How I Built It:

The application is built as a modern Android application using:

Kotlin — application development
Jetpack Compose — UI
Material 3 — UI design
MVVM + Clean Architecture — application architecture
Room Database — local financial data
DataStore — local preferences
Koin — dependency injection
Kotlin Coroutines + Flow — reactive data handling
OkHttp — communication with the AI service
Ollama — local LLM runtime
Gemma 3 4B — open-weight AI model The application follows a modular architecture separating core functionality, data, models, repositories, and feature screens.

🧠 Local AI Architecture
The AI feature is designed around local inference rather than a cloud AI API.

User selects a month
        ↓
Room Database
        ↓
Local Kotlin aggregation
        ↓
┌──────────────────────────┐
│ Income                   │
│ Expenses                 │
│ Savings                  │
│ Category totals          │
│ Budget vs Actual         │
│ Monthly comparison       │
└──────────────────────────┘
        ↓
Structured Monthly Summary
        ↓
Ollama Local API
        ↓
Gemma 3 4B
        ↓
Natural-language explanation
        ↓
Analysis Screen

Local Financial Calculations
Important financial calculations are performed by the application rather than delegated to the LLM.

Income          → calculated locally
Expenses        → calculated locally
Savings         → calculated locally
Category totals → calculated locally
Budget status   → calculated locally

Gemma receives the structured summary and focuses on explaining and interpreting the results.

This provides a clear separation:

Application
    ↓
Accurate financial calculations

Gemma
    ↓
Natural-language explanation

🤖** Why Gemma 3 4B?

**The application uses Gemma 3 4B, an open-weight model served locally through Ollama.
I selected the 4B model because the application's task is focused and lightweight. The model receives a structured monthly spending summary and generates a concise explanation rather than processing a large collection of raw documents.
Using a smaller model makes local inference more practical and can reduce computational requirements compared with larger models. Actual response speed depends on the user's hardware, available memory, prompt size, and system load.
The model runs through Ollama's local API, allowing the Android application to communicate with the locally hosted model.

⚡ Lightweight Local AI
The AI feature was designed specifically for a personal-finance workflow rather than as a generic chatbot.
Instead of asking Gemma to process every transaction individually, the application first creates a structured summary:

Selected Month
       ↓
Financial Data
       ↓
Local Aggregation
       ↓
Structured Summary
       ↓
Gemma 3 4B
       ↓
Spending Explanation

For example, the model can receive information such as:
Month: September

Income: ₹50,000
Expenses: ₹32,500
Savings: ₹17,500

Food: ₹8,000
Shopping: ₹7,000
Transport: ₹4,500
Bills: ₹6,000

Shopping increased compared with the previous month.

Gemma then converts this structured information into an explanation that is easier for a user to understand.

📱 Built for Real Users
My roommates and friends often know how much they spent but don't always know where their spending needs attention.
The application therefore focuses on simple questions:

Where did I spend the most?
Which category increased?
Am I exceeding my budget?
How much did I save?
What changed this month?
What should I pay attention to next month? Instead of requiring users to manually interpret charts and numbers, the AI provides an additional natural-language layer. Example

Financial Data:
Food       ₹8,000
Shopping   ₹7,000
Transport  ₹4,500
Bills      ₹6,000

AI Spending Insight:
Your largest discretionary expenses this month were food and shopping. Shopping increased significantly compared with the previous month, so reviewing non-essential purchases may help reduce next month's overall spending.

🔒 Privacy-First Design

Financial information is sensitive, so privacy is an important part of the product.
The AI workflow is:

Financial Transactions
        ↓
Local Android Database
        ↓
Local Monthly Aggregation
        ↓
Structured Summary
        ↓
Local Ollama Server
        ↓
Gemma 3 4B
        ↓
Spending Explanation

The core AI workflow does not require an OpenAI, Gemini, or other cloud LLM API key.
The model runs through Ollama locally, giving the user control over where the AI inference takes place.
If Ollama is configured to use a remote server, the privacy characteristics depend on that server configuration.

🛠️ Product Architecture

┌──────────────────────────────────┐
│          Android App             │
│                                  │
│  Jetpack Compose + Material 3    │
│              ↓                   │
│       ViewModel / MVVM           │
│              ↓                   │
│       Repository Layer           │
│              ↓                   │
│         Room Database            │
└──────────────────┬───────────────┘
                   │
                   │ Monthly Summary
                   ▼
          ┌─────────────────┐
          │  Ollama Local   │
          │      API        │
          └────────┬────────┘
                   │
                   ▼
            ┌─────────────┐
            │ Gemma 3 4B  │
            └──────┬──────┘
                   │
                   ▼
          AI Spending Insight
                   │
                   ▼
             Analysis UI

🧪 AI Feature Workflow

When a user requests an AI analysis:

1. User selects a month
        ↓
2. Application retrieves relevant financial data
        ↓
3. Kotlin calculates financial statistics
        ↓
4. Application creates a structured summary
        ↓
5. Summary is sent to local Ollama
        ↓
6. Gemma 3 4B interprets the summary
        ↓
7. Natural-language insight is returned
        ↓
8. Insight appears on the Analysis screen

The selected month is part of the AI context, so changing the month produces an analysis based on that month's data.

My Agent Session

I used GitHub Copilot as an AI coding and development assistant during the development of Expense Tracker.

GitHub Copilot helped me with:

Kotlin and Jetpack Compose development
Gradle configuration and troubleshooting
Android emulator networking
Ollama HTTP communication
Month-specific AI analysis
Debugging and fixing build issues
Code refactoring and implementation

Why Does Open Innovation Matter?
Open innovation made it possible to combine modern Android development, open-weight AI, local inference, and a real-world personal-finance use case.
The project brings together:
Android + Local Data + Open-Weight AI + Local Inference + Financial Analytics
Using an open-weight model such as Gemma means the AI component can be run locally through Ollama rather than requiring a proprietary cloud inference API.
This gives developers greater control over:

The model
The inference environment
The application architecture
The AI prompts
The data flow
The privacy model

🏆 Prize Categories

Expense Tracker uses Gemma 3 4B, an open-weight AI model, as the core of its local AI spending-insight feature.

The application:

Calculates financial statistics locally using Kotlin
Creates a structured monthly financial summary
Sends only the structured summary to the local Ollama API
Uses Gemma 3 4B to interpret spending patterns
Generates natural-language spending insights
Displays the results directly in the Analysis screen