Project Overview
CLARIX (Credibility, Legitimacy, and Authenticity Recognition & Intelligence eXtended) is an end-to-end misinformation detection platform. It combines LLM-powered claim extraction and fact-checking, HuggingFace-based fake-news classification, EfficientNet-B0 deepfake detection, and multi-signal credibility scoring into a single real-time pipeline. The platform does not just flag content as fake. It produces a detailed trust score from 0 to 100, explains why content is misleading, and cites reference sources so users can verify independently. A browser extension brings the entire verification engine directly into the browsing flow, eliminating the need to leave a page to check it.
Solution
CLARIX is organized as three cooperating services rather than one monolith: a Next.js 16 dashboard (port 3001) for deep analysis, an Express.js API server (port 3000) that orchestrates routing, validation, and orchestration, and a FastAPI Python engine (port 8000) that owns all ML inference. Incoming content flows through a unified /api/analyze endpoint; the Express layer routes text to the GPT-4.1 claim-verification pipeline, images to the EfficientNet-B0 deepfake detector, and URLs to an async queue processed with BullMQ. Every result passes through a credibility service that merges fact-check confidence, source credibility, and sentiment/bias signals into a single scored verdict with cited sources. The browser extension (Manifest V3) calls the same API, so the dashboard and extension share one verification engine.
Architecture
Core Features
Unified Text / Claim Analysis
Paste a claim or article and receive an instant credibility assessment. The pipeline extracts individual claims, verifies each against retrieved sources, and merges the results into one explainable verdict, not a binary 'fake or not', but a scored breakdown of why.
Deepfake Detection
A drag-and-drop image upload and URL input feed an EfficientNet-B0 classification model. The engine distinguishes manipulated and AI-generated imagery and folds the result into the same credibility report as text signals.
Full Page Scanning
Enter any URL and CLARIX scrapes and analyzes the entire page. Because page analysis is heavy, it runs asynchronously through a BullMQ-backed queue with a status endpoint the client polls, keeping the web tier responsive.
Multi-Signal Trust Score (0-100)
The flagship output. A scored ring visualization breaks down Fact-Check, Source Credibility, and Sentiment/Bias, each contributing to a single number a reader can act on in seconds.
Browser Extension (USP)
A Manifest V3 extension with three modes (text verification, image analysis, and full-page scanning) plus a 'Use Selection' action that verifies highlighted text in place. It is the product's differentiator: credibility checking as natural as clicking a bookmark.
Live Dashboard & RAG Pipeline
The dashboard surfaces quick stats from the database and a recent-activity feed, while the retrieval-augmented pipeline cross-references claims against trusted sources to ground every verdict in evidence.
Engineering Challenges
LLM reliability on structured output
Claim extraction, verification, and summarization all depend on GPT-4.1 returning well-formed JSON. We constrained output with explicit response schemas and validated every payload before it touched the database, so a malformed model response never became a malformed record.
Long-running page analysis without blocking
Scraping and analyzing a full web page can take tens of seconds, far beyond a reasonable HTTP timeout. The fix was a BullMQ queue with Redis persistence and a job-status endpoint, moving heavy work off the request path entirely.
Three services, one coherent product
Coordination between the Node API, the Python ML engine, and the extension introduced contract drift. Pydantic on the Python side and Joi validation on the Node side kept boundaries explicit, and a shared response shape meant one client contract across all inputs.
Model weight management
EfficientNet-B0 weights are large and should not live in git. We kept pre-trained weights under image_model/ and loaded them at engine startup, so inference stays in-process and fast rather than re-fetching per request.
Technical Decisions
Three services instead of one monolith
Node owns web orchestration; Python owns ML inference. Python's ML ecosystem (Transformers, PyTorch) would be hostile in a Node process, and Node's web ecosystem is the same for Python. Splitting lets each scale and deploy independently.
GPT-4.1 for the LLM pipeline
Claim extraction and verification need strong instruction-following and structured output. GPT-4.1's JSON mode with response schemas made the verification pipeline deterministic enough to persist directly.
pgvector + Neon over a standalone vector DB
Keeping relational data and embeddings in the same PostgreSQL instance (via pgvector) removes a second datastore from the architecture. Neon's serverless Postgres suits a project with bursty, low-frequency writes.
Redis + BullMQ for async work
In-memory queues die with the process. Redis-backed BullMQ persists jobs, survives restarts, and allows the worker to scale independently. This matters because page analysis is both slow and occasional.
API-key auth on the gateway
The extension and dashboard both hit the same API. A lightweight X-API-Key scheme protects the analyze endpoints while keeping health, stats, and result lookups public for the dashboard.
Performance Considerations
- Async URL analysis runs through a Redis-persisted queue, so the API never holds a connection open for a slow scrape.
- Redis caching reduces repeated OpenAI and ML calls for identical content.
- ML inference is colocated with model weights in the FastAPI engine, avoiding per-request weight loads.
- The RAG pipeline bounds retrieval with pgvector similarity search rather than scanning full tables.