DEV Community: Tejas Rawool

I Built Autonomiq: A Local AI Research Agent That Lets You Walk Away

Tejas Rawool — Sun, 11 Oct 2026 18:33:03 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass

What I Built

Research can turn into hours of switching between browser tabs, collecting sources, extracting information, comparing findings, and writing reports. I wanted to explore a different workflow: what if I could delegate that process to an AI agent, leave my desk, and return when the work was ready?

That idea became Autonomiq, a local-first autonomous AI research workspace built for students, developers, and researchers who want to automate repetitive knowledge work without constantly watching a chat window.

Autonomiq takes a research objective, prepares a plan, searches for sources, extracts content, indexes evidence for retrieval, analyzes the collected material with a local language model, and generates a structured Markdown report. It can also generate an audio digest so the user can listen to the summary away from the screen.

I designed the experience around three principles:

Delegate, don't babysit. A task should have a lifecycle independent of the browser interface.
Keep the AI replaceable. Local model inference should not depend on a single proprietary LLM API.
Make the work inspectable. Users should be able to see execution stages, sources, and generated artifacts.

The goal is not to create another chatbot that encourages longer conversations. It is to make the time spent supervising repetitive research shorter.

Code

TejasRawool186 / Autonomiq

Autonomiq is a local-first autonomous AI workspace designed to execute digital tasks on a user's computer while minimizing the need for continuous human supervision.

Autonomiq

A Local-First Autonomous AI Workspace
"Your AI works. You live."

Built for Hacktoberfest 2026 Open-Source AI Challenge.

🌟 Overview

Autonomiq executes long-running digital research tasks on your computer while minimizing continuous screen time. Users submit tasks in natural language, review an execution plan, and the system autonomously conducts web research, document parsing, RAG embeddings, analysis, and report generation in the background.

With Away Mode and durable execution (via Temporal), you can submit a task, close your browser, leave your desk, and return to completed source-backed reports and an audio digest.

🏗️ Architecture & Modules

Autonomiq/
├── backend/                       # FastAPI Server & AI Execution Engine
│   ├── app/
│   │   ├── api/                   # REST Endpoints (Tasks, Documents, Health)
│   │   ├── models/                # SQLite State & Entity Models
│   │   ├── schemas/               # Request/Response Data Contracts
│   │   ├── agent/                 # LangGraph Multi-Node Workflow
│   │   │   └── nodes/             #

…

View on GitHub

The repository contains a React and TypeScript frontend, a FastAPI backend, task and artifact storage, research workflow modules, local vector retrieval, and integrations for search, model inference, tracing, and audio generation.

The implementation and setup notes are available in the repository, including the environment configuration example and the software requirements specification.

The Problem

Imagine researching open-weight AI models for a project. You need to find relevant pages, compare model capabilities, extract hardware requirements, organize the evidence, and turn everything into a report.

A conventional workflow requires repeated manual steps. A chat-based AI workflow can help with individual steps, but the user may still need to collect sources, provide documents, move information between tools, and assemble the final output.

Autonomiq approaches the problem as a workflow rather than a single prompt. The user describes the desired result, and the application coordinates a sequence of research and processing stages.

There is also a privacy consideration. Research material and local documents are not always suitable for uploading to a third-party LLM service. Running the language-model inference locally gives the user more control over where that processing happens.

That does not eliminate every external dependency. Live web search still requires a search provider, and the optional audio integration uses an external service. The distinction matters: local inference and online research are separate parts of the system.

The Idea

The central idea behind Autonomiq is simple: give an AI agent a task that takes time, let the computer perform the work in the background, and return to the result instead of watching every step.

The application is built around a task-oriented interface rather than an open-ended chat. A task has an objective, an execution plan, a sequence of processing stages, sources, and generated artifacts.

The user-facing experience includes Away Mode, task monitoring, source attribution, and an audio digest. The backend keeps task execution separate from the frontend so that closing the browser does not inherently cancel the work, provided the backend worker remains active.

This is my interpretation of the Touch Grass theme. The application does not need to identify a bird or plan a hike to encourage time away from the screen. It can address another source of screen time: supervising repetitive computer work.

How It Works

The research workflow is organized into six primary stages.

Plan: The planner uses the configured local model to create a structured research plan and search queries.
Search: The researcher calls SerpApi to collect candidate web results.
Extract: The extraction stage uses BeautifulSoup-based tooling to retrieve and normalize webpage content.
Index: The indexer chunks collected content, creates embeddings, stores them in Qdrant, and retrieves relevant passages.
Analyze: The analyst sends the retrieved evidence to the local model for synthesis.
Report: The reporter assembles the analysis and source references into a Markdown report.

An audio digest can then be generated from the analysis through the ElevenLabs integration.

The relevant workflow code lives under backend/app/agent/ and backend/app/workflows/. The primary orchestration module calls the workflow stages in sequence, while the Temporal workflow and activity modules provide a separate path intended for durable background execution.

flowchart TD
    A[Research objective] --> B[Local AI planner]
    B --> C[Web search]
    C --> D[Extract page content]
    D --> E[Chunk and embed]
    E --> F[Qdrant retrieval]
    F --> G[Local model analysis]
    G --> H[Markdown report]
    H --> I[Optional audio digest]
    I --> J[Save artifacts]

The retrieval step is important because the analyst should work from collected evidence rather than relying exclusively on the model's existing knowledge. The report also records source URLs so that readers can inspect the material behind the findings.

Technical Architecture

Layer	Technology	Why it is used
Frontend	React, Vite, TypeScript	Task creation, monitoring, and results
Backend	Python, FastAPI	API endpoints and application services
Task persistence	SQLite, SQLAlchemy	Store task state and related records
Workflow modules	Python async workflow orchestration	Coordinate planning, research, indexing, analysis, and reporting
Local inference	Ollama with compatible Gemma or Qwen models	Generate plans and synthesize evidence locally
Web search	SerpApi	Retrieve current web search results
Web extraction	BeautifulSoup	Extract readable webpage content
Embeddings and retrieval	FastEmbed, Qdrant	Index text chunks and retrieve relevant passages
Document processing	pypdf, Markdown tooling	Extract and process supported documents
Workflow durability	Temporal integration	Provide a path for durable workflow execution
Observability	Sentry SDK integration	Capture configured telemetry and execution metadata
Audio digest	ElevenLabs	Convert the research summary into speech

The stack is deliberately modular. The local model communicates through an Ollama client, source collection is separated from extraction, and retrieval is isolated behind vector-store tooling.

That separation makes it easier to debug a failed search independently of a model-inference problem. It also makes future changes to the model or retrieval implementation less disruptive.

The presence of an integration in the repository does not, by itself, mean that every deployment has it enabled. Services such as SerpApi, ElevenLabs, Sentry, and Temporal require the relevant configuration and runtime dependencies.

How I Used Open-Source AI

The local-model component is central to Autonomiq. The backend's OllamaClient communicates with Ollama's generation endpoint, and the planner and analyst use that client to generate plans and synthesize retrieved evidence.

The configuration supports compatible Gemma and Qwen model names. For this project, Gemma through Ollama is the intended open-weight model path.

This approach gives the application control over the model runtime and makes it possible to perform the core language-model inference locally, without requiring a proprietary cloud LLM API for every planning or analysis step.

Open innovation also makes the system easier to experiment with. A developer can change the configured model, inspect the workflow, modify the prompts, or replace a tool without rebuilding the entire application around one hosted AI provider.

There are tradeoffs. Local inference consumes the user's own CPU, memory, and possibly GPU resources. Smaller models can produce weaker summaries, and performance depends on the model, quantization, and hardware. Live search and external speech synthesis also introduce network dependencies.

Consideration	Local model through Ollama	Hosted LLM API
Model inference	Runs on the configured local runtime	Runs on a provider's infrastructure
Data control	Prompts can remain local during inference	Prompts are sent to the selected provider
Cost model	Local hardware and electricity	Usually usage-based or subscription-based
Hardware	Limited by local resources	Uses provider-side compute
Model choice	Depends on locally available compatible models	Depends on the provider's offerings

The important distinction is not that local AI is always better. It is that the user gets a meaningful choice about where inference happens.

Real Example

A useful task for Autonomiq is a research request such as:

Research ten useful open-weight AI models, compare their capabilities and hardware requirements, and generate a report.

The intended processing path is to create a plan, search for relevant pages, extract available content, index the collected evidence, analyze retrieved passages with the local model, and save the final Markdown report. If configured, the workflow can also generate an audio digest.

The current interface also displays a task called "Verification Test" as completed, with six sources processed and two artifacts listed: report.md and digest.mp3. This is the state shown in the application interface, not a claim that I independently benchmarked the research quality or verified every citation.

A second use case is document research. A user can supply supported documents, have their text extracted and indexed, and use retrieval to provide relevant passages for subsequent analysis. This is useful when the information already exists in a collection of PDFs or notes.

A third use case is listening to the final summary instead of reading the entire report. The audio digest turns the report into a speech artifact, although its availability depends on the audio service being configured and the generation step succeeding.

What Makes It Different

Most AI research tools focus on the answer. Autonomiq models the process. Its workflow separates planning, searching, extracting, indexing, analysis, and reporting, making each stage easier to inspect.

Most chat interfaces assume the user remains present. Autonomiq separates task execution from the browser. The background-execution design is intended to let users leave the interface while the worker continues.

Many research workflows depend on hosted language models. Autonomiq supports local inference. The Ollama integration lets compatible open-weight models handle planning and synthesis on the user's machine.

A summary without evidence is difficult to verify. Autonomiq preserves source references. The indexer attaches source metadata to chunks, and the report includes source URLs and excerpts where available.

A report does not have to mean another screen session. The optional audio digest gives users another way to consume the result after the research task finishes.

These are architectural and product-design distinctions, not claims that every feature has been validated under every runtime configuration.

Build Process

I organized the implementation into phases so that the application could develop from a backend foundation into an end-to-end research workspace.

First, I established the project structure, environment configuration, API layer, database models, and request and response schemas. The task, step, source, and artifact entities provide the foundation for tracking research work.

Next, I implemented document parsing, file management, text chunking, and the Qdrant vector-store integration. These components provide the retrieval layer used by the research analyst.

I then built the workflow modules for planning, web search, extraction, indexing, analysis, and report generation. The local Ollama client keeps model communication separate from the individual stages.

After that, I added the Temporal workflow and activity modules, Sentry tracing support, and the ElevenLabs audio-digest integration. Finally, I built the React interface around task creation, Away Mode, task monitoring, and generated results.

The repository's progress.md, task_plan.md, and findings.md document the development process and decisions.

One important implementation decision was to keep the stages modular instead of placing the entire research pipeline in a single large function. Another was to make the local model runtime configurable rather than hardwiring a single model throughout the application.

Challenges and Lessons

1. Separating live search from content extraction. Search results provide candidate URLs and snippets, but snippets are not equivalent to full page content. The extractor attempts to retrieve page content separately. A failed extraction should remain distinguishable from a successful one.

2. Grounding analysis in retrieved material. The indexer connects chunks to source metadata before retrieval. This creates a path for evidence-backed analysis, but source attribution alone does not prove that every generated claim is correct.

3. Handling local inference failures. Ollama can be unavailable or unable to load the selected model. The application needs to distinguish model-runtime failure from an ordinary empty research result, rather than presenting both as successful analysis.

4. Making long-running work understandable. A task-oriented interface needs more than a spinner. Status, execution stages, errors, and artifacts help users understand what happened without reading backend logs.

5. Keeping the integrations honest. A configured integration is not the same as a successfully completed operation. Optional services need explicit availability and error states, and a task should not be presented as fully successful when a required stage fails.

Limitations

Autonomiq is an evolving project, and several limitations are important to state clearly.

Search fallback behavior: The current researcher module includes fallback source records when live search returns no sources. These records are placeholders, not verified search results. They must be clearly marked or removed before treating every generated report as evidence-grounded.
Extraction quality: Some websites may block automated access, return incomplete content, or provide pages that cannot be parsed reliably. Search snippets may remain insufficient for detailed analysis.
Model availability: Local inference requires a compatible model runtime and sufficient hardware. The application does not make every model suitable for every machine.
Fallback analysis: The analyst contains fallback behavior when model generation fails. Such output should be clearly labeled as fallback output rather than presented as equivalent to a successful model-generated synthesis.
Workflow durability: Temporal workflow and activity modules exist, but the presence of those modules alone does not establish that crash recovery and retry behavior have been verified end to end.
External services: Live search and audio synthesis depend on their respective service configurations. Local model inference does not make the entire application fully offline.
Validation: I am not publishing performance or accuracy numbers because I do not have independently verified measurements for this write-up.

These are useful areas for continued development because a trustworthy research agent must make failures and evidence quality visible, not hide them behind a polished report.

Future Improvements

The next improvements I would prioritize are:

Evidence quality controls: Remove unverified placeholder sources from successful research results, clearly mark missing evidence, and validate that cited URLs correspond to retrieved material.
Durable execution testing: Verify actual worker interruption, restart, retry, cancellation, and task recovery behavior with integration tests.
Improved report exports: Add a structured PDF export with readable headings, source links, page numbers, and consistent typography.
Better model and resource management: Detect available models, provide clearer hardware guidance, and surface inference errors in the interface.
More transparent execution telemetry: Connect the task timeline to real stage events and expose meaningful latency, retry, and failure information.

I would prioritize source integrity and workflow recovery before adding more tools. A research agent should be able to explain what it did, which sources it used, and where its process failed.

Run It

The repository documents a local development setup using Python, Node.js, Ollama, and optional external integrations.

Clone the repository:

git clone https://github.com/TejasRawool186/Autonomiq.git
cd Autonomiq

Create the environment configuration:

cp .env.example .env

Configure the local model and any external services you intend to use. Install the backend requirements:

python -m venv .venv

Activate the environment, then run:

pip install -r backend/requirements.txt
python scripts/run_backend.py

In a second terminal, start the frontend:

cd frontend
npm install
npm run dev

Open http://localhost:5173. The backend API documentation is available at http://localhost:8000/docs when the backend is running with the documented local configuration.

For local inference, install Ollama and pull a model compatible with the configured model name. Live research and audio generation require the relevant API credentials. Check the repository's current setup instructions before running the optional workflow integrations.

Required project details

Project: Autonomiq
Repository: https://github.com/TejasRawool186/Autonomiq
Challenge: Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass
Model runtime: Ollama
Intended open-weight model path: Gemma
Search integration: SerpApi
Audio integration: ElevenLabs
Agent tracing integration: Sentry, when configured

No dataset is required for the basic research workflow. The system collects sources for each research objective.

My Agent Session

I have not included an agent-session embed because I do not have a verified public DevRelay or other agent-session URL to share. The repository contains project planning and progress documents that describe the implementation phases.

Prize Categories

The integrations most directly represented in the code are:

Best Use of Gemma: The local inference path uses Ollama with compatible Gemma model configurations.
Best Use of SerpApi: The researcher calls SerpApi to retrieve web search results.
Best Use of ElevenLabs: The audio-digest workflow calls the ElevenLabs integration to generate speech from the research summary.

Sentry tracing support is also present in the code, but I would only enter the Sentry category after verifying that the relevant execution spans are recorded and visible in a real run.

I am not claiming the Render, Temporal, or any other partner category solely because a configuration file or dependency exists. Those integrations need meaningful, verified execution before they should be presented as a completed partner-category entry.

Final Takeaway

Building Autonomiq made me think about AI productivity differently. The objective is not to maximize the time someone spends interacting with a model, but to reduce the supervision needed to complete useful work. Local inference gives users more control over where their documents and prompts are processed, while source attribution and execution visibility provide a foundation for trust. The next step is to make evidence handling and durable execution as reliable as the user experience is intended to be.

FolderPilot: A Local AI Folder Organizer That Is Built Never to Delete a File

Tejas Rawool — Sun, 04 Oct 2026 17:34:47 +0000

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

What I Built

FolderPilot is a local web app that scans any folder, reads what is inside the files, and proposes a cleaner structure. It shows the result as an interactive, color-coded map. You review the plan, edit it, and approve it. Nothing changes on disk until you do.

I built it for a friend whose folders hold exactly the kind of files you do not want to upload anywhere: ID scans, marksheets, resumes, offer letters, and assignments, all mixed together with installers and screenshots. Cloud organizers want those documents on someone else's server. Cleanup scripts delete things. I wanted a tool that does neither.

Three rules shaped the whole project:

Everything runs on 127.0.0.1 with an open-weight model served by Ollama.
The code has no delete, unlink, remove, or truncate path, so there is nothing to bypass.
Every change is journaled before it happens, so any operation, batch, or the whole workspace can be undone.

Demo

The video walks through scanning a real folder, exploring the treemap and sunburst views, reviewing the before and after plan, applying it, and rolling it back. It also shows the folder chat refusing a request to delete files.

Code

TejasRawool186 / FolderPilot

A local, privacy-first web app that analyzes any folder, shows it visually with color-coded suggested sorting, lets you customize and approve the plan, and lets you chat with the folder. It can never delete anything.

FolderPilot

Organize anything. Delete nothing.

Privacy-first, local folder organizer with interactive visual analytics,
append-only rollback journaling, and on-device AI.

Overview · How it works · Features · Safety model · Quick start

Why this exists

Personal directories such as Downloads, Desktop, and work folders routinely accumulate sensitive files—including tax returns, identity cards, college transcripts, and resumes. Most of these files remain disorganized because manual sorting is slow and tedious.

Typical cloud organizers require uploading private documents to external servers. Other utility scripts use aggressive delete operations that risk permanent data loss.

FolderPilot runs entirely on local hardware, inspects documents privately on 127.0.0.1, and guarantees that no file can ever be deleted.

Why open-source, local AI

Running open-weight language models locally on consumer hardware changes the economics and security of desktop file management:

Dimension	Local Open-Source AI (FolderPilot)	Cloud AI APIs
Privacy	Local-only. File contents, extracted text, and metadata never

…

View on GitHub

The repository has a FastAPI backend, a Next.js frontend, a pytest suite for the safety guarantees, and docs covering the architecture, the AI integration, and the API.

The Problem

A Downloads folder is where files go to pile up. After a year it holds duplicate resumes (resume_final, resume_final2), screenshots named IMG_2938.png, installers you already ran, and a few documents you would be uncomfortable seeing leaked.

Existing options each fail in a different way:

Cloud organizers need your documents uploaded, including identity cards and transcripts.
Cleanup scripts sort by extension, which cannot tell an assignment from a bank statement, and some delete aggressively.
Doing it by hand is slow enough that nobody finishes.

The Idea

Make the AI the last resort, and make the file system layer safe by construction.

Most files do not need a language model. An extension, a hash, or a keyword count settles them. So FolderPilot runs cheap checks first and only sends the genuinely ambiguous files to a small local model. That keeps it usable on a laptop with 8 GB of RAM and no GPU, which is the machine I developed it on.

On the safety side, I did not add a "confirm delete" dialog. I removed deletion from the program. The file operations module only exposes mkdir, move, and rename.

How It Works

The scanner walks the chosen folder and streams progress to the UI. Each file then goes through four tiers, stopping at the first one that is confident.

flowchart TD
    A["Select any folder"] --> B["Background scan"]
    B --> C["Tier 1: extension and filename rules"]
    C --> D["Tier 2: SHA-256 duplicate detection"]
    D --> E["Tier 3: keyword prototypes on extracted text"]
    E --> F["Tier 4: local LLM, JSON schema output"]
    F --> G["Draft plan, unapproved"]
    G --> H["User reviews, edits, approves"]
    H --> I["Journal entry written"]
    I --> J["mkdir / move / rename"]
    J --> K["Undo: single op, batch, or full workspace"]

Tier	Mechanism	Handles
1. Rules	Extension taxonomy and filename regex	Code, archives, media, installers, screenshots
2. Hashes	Lazy SHA-256 on files with equal sizes	Exact duplicates and repeated downloads
3. Prototypes	Keyword frequency in the first ~500 extracted tokens	Assignments, invoices, offer letters
4. Local LLM	Ollama with constrained JSON output	Ambiguous PDFs and poorly named files

Every file gets a category and a reason, so the review screen can show why it was placed where it was.

Technical Architecture

Layer	Technology	Why
Frontend	Next.js 16, React 19, Tailwind, D3.js	D3 gives full control over the treemap, sunburst, and tree comparison
Backend	Python 3.11, FastAPI	Async routes and server-sent events for live scan progress
Storage	SQLite in WAL mode	File index, plans, and the journal in one local file
Extraction	PyMuPDF, python-docx, python-pptx	Reads text from PDFs, Word, and PowerPoint files
Local AI	Ollama with Gemma 3 1B (default), Qwen 2.5 1.5B	Small enough for CPU-only machines

The frontend never talks to anything but the local backend, which binds to 127.0.0.1.

The interface has these views:

Treemap with drill-down zoom and a spotlight filter.
Sunburst view of size by depth.
Before and after tree showing the proposed structure next to the current one.
Duplicate clusters with keep-original and keep-newest suggestions.
Chaos score from 0 to 100, based on root-level clutter, nesting imbalance, and duplicate ratio, with a slider that simulates cleanup.
In-app previewer for images, audio, video, PDFs, Office documents, spreadsheets, and a hex view for binaries.

How I Used Open-Source AI

The default model is Gemma 3 1B (gemma3:1b, Q4_K_M, roughly 1.2 GB of RAM), served through Ollama. Qwen 2.5 1.5B is supported as an alternative. The model can be switched from the navigation bar at runtime, through the POST /api/ai/model endpoint, or with the FOLDERPILOT_OLLAMA_LLM_MODEL environment variable.

The model does two jobs:

Fallback classification. For files the first three tiers cannot place, it returns JSON matching a fixed schema. Constraining the output keeps replies short and parseable.
Folder chat and summaries. Counts and size questions are answered from SQLite, and the model handles wording and short document summaries.

Why open weights mattered here:

	Local open model	Cloud API
Privacy	File text and metadata stay on the machine	Excerpts of private documents leave the machine
Cost	No per-file cost	Metered by volume
Offline	Works once weights are cached	Needs a connection
Model choice	Swap models in one setting	Tied to one provider

The tradeoff is accuracy. A 1B model will misclassify some ambiguous files, especially ones with little extractable text. That is why low-confidence files are surfaced in a review queue and why nothing is applied without approval. A user's manual category overrides are stored in local SQLite to guide later scans.

Real Example

Example 1: classification

A file named assignment_final.pdf sits next to assignment.pdf. The extension alone says "document". Tier 2 notices the sizes differ, so they are not exact duplicates. Tier 3 reads the first page, finds terms common to coursework, and places both under a college category. The plan shows the reason on the card, and the user can drag them elsewhere if it is wrong.

Example 2: a destructive request

In the folder chat, I typed a request to delete all the duplicate files. The chat router intercepts deletion and removal requests before they reach the model. The reply explains that FolderPilot never deletes, and offers to move the duplicates into a _Review_Later/ folder instead. A test (test_chat_delete_refusal) covers this behavior.

Example 3: undo

After applying a plan, the Journal view lists every operation. One click on a single operation restores that file. One click on the batch restores everything the plan touched. Because the journal entry is written before each operation, an interrupted run leaves a consistent record.

What Makes It Different

Most organizers confirm before they delete. This one cannot delete.

Safety by absence. safe_ops.py has no delete, unlink, remove, or truncate path. test_no_delete_functions_exist checks that this stays true.
No overwrites. Name collisions get a suffix, as in Document (1).pdf.
Journal before action. The undo log is not an afterthought. Entries exist before the file system changes.
Protected paths. Folder browsing rejects system locations such as C:\Windows and C:\Program Files, and has tests for path traversal and symlink escapes.
LLM as the last tier. The model sees only the files the cheaper checks could not settle, which is what makes a 1B model enough.

Build Process

I started by writing a requirements document before any code, because the safety rules had to be requirements and not afterthoughts. The repo's docs/ folder keeps that specification along with architecture notes and a development log.

The backend came first: scanner, safe file operations, journal, and undo. I built the visual layer after that, once the plan and journal data was reliable. The default model started as Qwen 2.5 1.5B and moved to Gemma 3 1B after I tuned for memory use and speed on an 8 GB machine, with Qwen kept as a switchable option.

The tests were written around the guarantees, not the features. If a safety claim appears in the README, there is a named test behind it.

Challenges and Lessons

Treemap readability. One large video file can swallow the whole canvas. Size scaling, translucent tiles, and label rules for small tiles fixed most of it.
Making a small model useful. A 1B model is unreliable as a first resort and good as a fallback. Constrained JSON output and short text excerpts made it consistent.
Cheap work first. Lazy hashing, caching, and limiting text extraction kept scans manageable on CPU.
Claims need evidence. Rewriting the README forced me to check each safety statement against the code, and to soften wording where the code did not fully back it up.

Limitations

Small models can misclassify files with little or no extractable text. The approval queue exists for this reason.
OCR and keyword prototypes are tuned for English. Hindi, Marathi, and other Indic-script documents need more work.
Folders with tens of thousands of files take longer to scan.
The launcher script targets Windows. Other platforms use the manual setup.

Future Improvements

Local semantic search using ONNX embeddings.
Multi-language OCR for regional documents and identity cards.
An in-app taxonomy editor for custom categories and subfolder rules.
A packaged desktop build with an embedded Python runtime.

Run It

Requirements: Python 3.11+, Node.js 20+, and Ollama.

ollama pull gemma3:1b
cd backend && python -m pip install -r requirements.txt
python -m uvicorn app.main:app --host 127.0.0.1 --port 8000

In a second terminal:

cd frontend && npm install && npm run dev -- -p 3000

Then open http://127.0.0.1:3000. On Windows, run.bat starts both.

Final Takeaway

I wanted a tool I would be comfortable pointing at a folder full of someone's private documents. Keeping the model local made the privacy story simple, and removing deletion from the code made the safety story simple. A small open model turned out to be enough once it was the last step in the pipeline instead of the first.

Building a Knowledge Integrity Platform with Sanity and AI

Tejas Rawool — Sun, 04 Oct 2026 15:29:05 +0000

This is a submission for the Sanity Challenge, Path Two: Vibe-Code Something Strange

What I Built

ATLAS: AI Knowledge Integrity Auditor

AI can generate an answer in seconds.

The harder question is whether that answer can actually be trusted.

That question led me to build ATLAS, an AI-powered knowledge integrity platform that transforms unstructured content into structured, interconnected knowledge and then investigates factual claims against that knowledge.

Instead of treating an article as one large block of text, ATLAS transforms it into:

Source → Entity → Claim → Relationship → Conflict → Verdict

A user provides a real article or documentation URL. ATLAS extracts entities, atomic claims, relationships and provenance, then stores them as structured documents inside the Sanity Content Lake.

The user can then investigate a specific factual claim instead of simply asking an AI model to summarize the article.

The result is an inspectable investigation containing:

Evidence
Sources
Claims
Relationships
Conflicts
Verdict
Evidence graph
Adversarial audit results
Cryptographic certificate

Don't just trust the answer. Inspect the evidence.

Demo Video

Watch the complete ATLAS workflow:

The demonstration covers:

Ingest Article
      ↓
Extract Structured Knowledge
      ↓
Store Knowledge in Sanity
      ↓
Investigate Claim
      ↓
Generate Verdict
      ↓
Inspect Evidence Graph
      ↓
Run Adversarial Audit
      ↓
Generate Certificate
      ↓
Verify Investigation

The demo uses a real-world article concerning NVIDIA and India's AI infrastructure investment and investigates specific factual claims from that content.

Code

The complete source code is available on GitHub:

TejasRawool186 / Atlas

ATLAS is an autonomous knowledge-integrity platform that investigates factual questions by querying a Sanity-backed Content Lake and Knowledge Base, running adversarial audit probes, and producing tamper-evident cryptographic certificates.

ATLAS

Audit factual claims against structured knowledge with cryptographic verification.

ATLAS is an epistemic integrity auditor that validates factual assertions against relational schemas in Sanity, evaluates contradictions across sources, and seals the evidence into tamper-evident Merkle certificates.

Overview • How it works • Tech stack • Getting started • Testing

Overview

ATLAS validates factual claims against structured source documents and generates an auditable cryptographic proof for every verdict. The system is designed for engineering, compliance, and research teams that require autonomous agents to produce citations linked to structured schemas rather than ungrounded completions. Standard retrieval engines pass unstructured text chunks to an LLM, making temporal conflicts and subtle hallucinations difficult to isolate. ATLAS replaces this pattern by structuring sources into entities, claims, and relations within the Sanity Content Lake, evaluating conflicts with explicit authority rules, and executing a 10-probe audit suite before issuing a verdict. Every completed investigation produces a…

View on GitHub

The repository contains:

Investigation agent
Sanity integration layer
Sanity Studio schemas
GROQ queries
Evidence graph
Conflict detection
Adversarial audit system
Cryptographic certificate generation
Certificate verification
Subsystem documentation

Why I Built It

Traditional RAG systems are very good at finding text that looks relevant.

But similarity is not the same thing as evidence.

If two sources disagree, a typical retrieval pipeline can return both pieces of text and leave the model to decide what sounds correct.

I wanted to explore a different approach.

What if the underlying knowledge itself was structured?

What if an AI system could understand that:

Entity
   ↓
Claim
   ↓
Source
   ↓
Relationship
   ↓
Conflict

is not just stored data, but part of the reasoning process?

That became the foundation of ATLAS.

How ATLAS Works

The application follows a structured investigation pipeline.

Article / Documentation
        ↓
Structured Knowledge Extraction
        ↓
Sanity Content Lake
        ↓
Entity Resolution
        ↓
Claim Retrieval
        ↓
Evidence Comparison
        ↓
Conflict Detection
        ↓
AI Investigation
        ↓
Epistemic Verdict
        ↓
Evidence Graph
        ↓
Adversarial Audit
        ↓
Cryptographic Certificate
        ↓
Verification

Each stage has a specific responsibility.

The AI model is not simply given an article and asked to produce an answer.

Instead, the system first builds structured knowledge and then retrieves the evidence required for the investigation.

The Knowledge Model

ATLAS uses Sanity to represent knowledge as interconnected documents.

The primary document types are:

entity
claim
source
relationship
conflict
knowledge_doc

A claim contains structured information such as:

Subject
Predicate
Object
Source
Confidence
Status
Validity Window

This allows the system to reason about individual claims rather than treating an entire article as one piece of text.

For example:

Source
   ↓
Entity: India
   ↓
Claim: AI investment = $1.2B
   ↓
Source: Article
   ↓
Relationship: supported_by

The same structure can also represent conflicting evidence.

How Sanity Fits Into the Application

Sanity is not being used as a simple CMS or secondary database.

It is the structured knowledge layer behind ATLAS.

The Content Lake stores the entities, claims, sources, relationships, conflicts and knowledge documents used by the investigation system.

This means the application can query individual pieces of knowledge and follow their relationships.

The underlying flow is:

User Question
      ↓
Relevant Entities
      ↓
Related Claims
      ↓
Supporting Sources
      ↓
Relationships
      ↓
Conflicts
      ↓
Evidence Set

This structure is what allows ATLAS to investigate relationships rather than simply perform keyword matching.

GROQ Retrieval

The application uses GROQ to retrieve structured knowledge from Sanity.

The investigation first resolves relevant entities.

It then retrieves claims associated with those entities and follows related documents.

The retrieval layer can access:

Entities
Claims
Sources
Relationships
Conflicts
Knowledge documents

This allows the investigation agent to construct an evidence set before generating its conclusion.

The Investigation Agent

Once the relevant knowledge has been retrieved, the investigation agent takes over.

The agent:

Analyzes the question
Plans the investigation
Resolves relevant entities
Retrieves related claims
Retrieves supporting sources
Traverses relationships
Detects competing claims
Applies source authority and recency rules
Generates a citation-backed conclusion
Audits the generated answer
Produces the final verdict

The AI therefore operates on structured evidence rather than an arbitrary collection of text chunks.

Epistemic Verdicts

ATLAS does not force every investigation into a simple yes or no.

It produces four possible outcomes:

SUPPORTED

PARTIALLY_SUPPORTED

CONTRADICTED

INSUFFICIENT_EVIDENCE

The last state is especially important.

If the structured knowledge does not provide enough evidence, ATLAS can return:

INSUFFICIENT_EVIDENCE

instead of inventing an answer.

Conflict Detection

One of the central parts of ATLAS is its contradiction engine.

The system compares structured claims using factors such as:

Subject
Predicate
Object
Source
Validity Interval
Source Authority
Recency

Source authority is also considered when competing claims are discovered.

This allows ATLAS to distinguish between:

Different information
        ↓
Newer information
        ↓
More authoritative information
        ↓
Actual contradiction

This would be much harder to implement reliably when all evidence is stored as raw text.

Adversarial Audit

Generating an answer is not the final step.

ATLAS runs a 10-probe adversarial audit against the generated investigation.

The audit examines areas such as:

Grounding
Unsupported Claims
Citation Coverage
Entity Drift
Evidence Consistency
Temporal Ordering
Counterfactual Source Removal
Retrieval Completeness
Contradictory Evidence
Answer Resilience

The objective is to actively search for weaknesses in the conclusion.

If a statement cannot be connected to the retrieved evidence, the audit can identify the problem instead of silently accepting it.

Evidence Graph

Because the underlying knowledge is represented as connected documents, ATLAS can construct a live evidence graph.

The graph connects:

Entities
   ↓
Claims
   ↓
Sources
   ↓
Relationships
   ↓
Conflicts

This provides a visual explanation of how the final verdict was reached.

Instead of seeing only:

Answer: SUPPORTED

the user can inspect the evidence that led to that result.

Cryptographic Certificate

ATLAS also adds an integrity layer to the investigation.

The evidence used during an investigation can be sealed into a cryptographic certificate using:

HMAC-SHA256
+
Merkle Tree

The certificate commits the investigation to the evidence used at that point in time.

The process is:

Evidence
   ↓
Hash Evidence
   ↓
Build Merkle Tree
   ↓
Generate Certificate
   ↓
Verify Later

If the underlying evidence is modified, verification can detect that the investigation no longer matches the original evidence state.

Demo Investigation

For the demonstration, I used a real-world article concerning NVIDIA and India's AI infrastructure investment.

Rather than asking ATLAS to simply summarize the article, I used the article as the starting point for structured knowledge extraction and then investigated specific factual claims.

Claim 1

"India's current AI investment is $1.2B."

ATLAS returned:

SUPPORTED

The result was connected to the extracted claim and its supporting source through the evidence graph.

Claim 2

"The Union Budget provides a 10-year tax holiday."

ATLAS returned:

CONTRADICTED

The investigation found that although the article contained the AI investment figure, the evidence associated with the tax holiday indicated a 20-year period rather than 10 years.

This demonstrates the central idea behind ATLAS.

The agent is not simply repeating what an article says.

It is decomposing the content into structured claims and investigating those claims against their available evidence.

Technology Stack

Frontend
React 19
Vite
TypeScript
Tailwind CSS

Backend
Node.js
Express
Server-Sent Events

Knowledge Layer
Sanity
Sanity Content Lake
GROQ
Sanity Studio

AI
Gemini 2.5 Flash

Integrity
HMAC-SHA256
Merkle Trees

The application uses AI for interpretation-heavy tasks such as extraction, planning and answer synthesis.

Deterministic code handles retrieval, relationship traversal, source weighting, auditing and certificate verification.

This separation makes the system easier to reason about and debug.

Project Architecture

                         ATLAS
                           |
          +----------------+----------------+
          |                                 |
          v                                 v
      React 19                         Node.js
      Vite                             Express
          |                                 |
          +---------------+-----------------+
                          |
                          v
                  Investigation Agent
                          |
             +------------+------------+
             |                         |
             v                         v
          Gemini                    Sanity
        AI Layer                  Content Lake
                                      |
                           +----------+----------+
                           |          |          |
                           v          v          v
                        Claims    Entities   Sources
                           |          |          |
                           +----------+----------+
                                      |
                                      v
                                Relationships
                                      |
                                      v
                                   Conflicts
                                      |
                                      v
                              Evidence Graph
                                      |
                                      v
                              Adversarial Audit
                                      |
                                      v
                             Cryptographic Proof

My Build Process

The project started with a simple question:

What would an AI system look like if its answer had to be investigated rather than simply generated?

The first step was designing the knowledge model.

Instead of storing an article as a single document, I modeled the application around relationships between:

Sources
Entities
Claims
Relationships
Conflicts
Knowledge Documents

Once that structure existed, I built the ingestion pipeline.

The application takes a URL, extracts the relevant content and uses the AI layer to identify structured entities and atomic claims.

Those objects are then stored in Sanity.

The next challenge was retrieval.

Rather than sending the entire article to the model, the agent first resolves entities and retrieves the relevant structured documents using GROQ.

This made the investigation process more controlled and explainable.

The next stage was contradiction detection.

I introduced explicit rules for comparing claims, evaluating source authority and handling recency.

After that came the adversarial audit.

The audit was designed around one principle:

The system should try to break its own answer.

Finally, I added the cryptographic certificate so that the evidence used by an investigation could be verified after the investigation was complete.

What Worked

The biggest success was using Sanity as a structured knowledge layer rather than treating it as a conventional content backend.

Once claims, entities and relationships became first-class documents, many capabilities became easier to implement.

GROQ also made it possible to express retrieval around the structure of the knowledge instead of relying entirely on semantic similarity.

The evidence graph naturally followed from the relationships already stored in Sanity.

What Did Not Work

The first approach was too close to a traditional RAG system.

It was tempting to retrieve relevant text and immediately ask the model for an answer.

That worked for simple questions, but it did not provide enough visibility into why the answer was correct.

The application therefore evolved toward structured claims and explicit provenance.

Another challenge was avoiding excessive dependence on the AI model.

The final architecture separates AI-assisted tasks from deterministic operations.

AI handles interpretation.

Deterministic code handles retrieval, relationship traversal, source weighting, auditing and verification.

Why Sanity Was Important

The project would have been much harder to build if the article remained one large block of text.

Sanity provided the structure needed to turn content into interconnected knowledge.

The application can reason about:

Who made the claim?
What exactly was claimed?
Where did it come from?
What other claims are related?
Does another source disagree?
When was the claim valid?
How strong is the evidence?

That is where structured content becomes part of the application's reasoning model rather than simply being storage.

Sanity Project Details

Project ID

hrexnsmi

Dataset

production

Sanity Project

https://www.sanity.io/organizations/ofyfft9qh/project/hrexnsmi

Document Types

entity
claim
source
relationship
conflict
knowledge_doc

Studio Schemas

https://github.com/TejasRawool186/Atlas/tree/main/sanity-studio/schemaTypes

Agent Session

An agent session can be included here if available.

The session should be made public before publishing so that judges can access it.

Final Thought

ATLAS started with a simple question:

Can we build an AI system that does not ask users to blindly trust its answer?

The result is an application where the answer is only one part of the investigation.

The evidence, sources, relationships, conflicts, audit results and cryptographic certificate are part of the result too.

The goal is not to make AI appear infallible.

The goal is to make its evidence easier to inspect.

Don't just trust the answer. Inspect the evidence.

ATLAS: An AI Knowledge Integrity Auditor That Investigates Claims with Sanity

Tejas Rawool — Sun, 04 Oct 2026 14:34:09 +0000

This is a submission for the Sanity Challenge, Path One: Ship an Agent That Queries Real Content*

What I Built

ATLAS - AI Knowledge Integrity Auditor

AI can answer almost any question in seconds.

The harder question is:

Can you trust the answer?

A traditional RAG system retrieves similar chunks of text, gives them to an LLM, and generates an answer.

But when an answer actually matters, similarity alone is not enough.

You need to know:

Which claim supports the answer?
Where did that claim come from?
Do different sources disagree?
Which source should be trusted?
Is the evidence still valid?
Can someone independently inspect the reasoning later?

That is the problem I wanted to solve with ATLAS.

ATLAS is an AI-powered knowledge integrity auditor that turns unstructured content into structured, interconnected knowledge and then investigates individual claims against that knowledge.

Instead of treating an article as one large block of text, ATLAS transforms it into:

Source → Entity → Claim → Relationship → Conflict → Verdict

The structured knowledge is stored in Sanity's Content Lake, allowing the investigation agent to query individual entities, claims, relationships, sources, and conflicts rather than relying only on semantic similarity.

How ATLAS Works

The workflow starts with a real article or documentation URL.

ATLAS processes the content and extracts:

Entities
Atomic claims
Sources
Relationships
Knowledge documents
Provenance information

These are stored as structured documents in Sanity.

Once the knowledge is available, a user can submit a specific factual claim for investigation.

The investigation agent then:

Analyzes the question and plans the investigation.
Resolves relevant entities using GROQ.
Retrieves claims connected to those entities.
Retrieves the corresponding sources and relationships.
Searches for competing or contradictory claims.
Applies explicit source-authority and recency rules.
Generates a citation-backed answer.
Runs adversarial audit probes against the generated answer.
Produces an epistemic verdict.
Builds an evidence graph showing how the evidence is connected.
Generates a cryptographic certificate that can be verified later.

The possible verdicts are:

SUPPORTED
PARTIALLY_SUPPORTED
CONTRADICTED
INSUFFICIENT_EVIDENCE

The result is therefore not simply an AI-generated "yes" or "no".

It is an inspectable investigation containing the verdict, evidence, sources, relationships, conflicts, audit results, evidence graph, and cryptographic certificate.

Don't just trust the answer. Inspect the evidence.

Demo

For the demonstration, I used a real-world article about NVIDIA and India's AI infrastructure investment.

Instead of asking ATLAS to summarize the article, I extracted individual factual claims and investigated them independently.

Claim 1

"India's current AI investment is $1.2B."

ATLAS returns:

SUPPORTED

The system retrieves the relevant structured claim, resolves its associated entities and sources, and verifies that the evidence supports the assertion.

The investigation result is connected back to the underlying evidence through the evidence graph.

Claim 2

"The Union Budget provides a 10-year tax holiday."

ATLAS returns:

CONTRADICTED

The investigation finds that although the article contains the AI investment figure, the tax-holiday claim does not match the evidence stored in the knowledge base.

The evidence indicates a 20-year holiday rather than 10 years.

This demonstrates the core idea behind ATLAS.

The agent is not simply repeating what an article says.

It decomposes the content into structured claims and investigates those claims against their evidence.

Complete Investigation Flow

The complete workflow demonstrated in the video is:

Watch the Demo

The demo walks through the complete ATLAS workflow, including article ingestion, claim investigation, evidence retrieval, verdict generation, the evidence graph, and certificate verification.

Code

TejasRawool186 / Atlas

ATLAS is an autonomous knowledge-integrity platform that investigates factual questions by querying a Sanity-backed Content Lake and Knowledge Base, running adversarial audit probes, and producing tamper-evident cryptographic certificates.

ATLAS

Audit factual claims against structured knowledge with cryptographic verification.

Overview • How it works • Tech stack • Getting started • Testing

Overview

View on GitHub

Repository:

https://github.com/TejasRawool186/Atlas

ATLAS is built with:

Node.js + Express for the backend API and Server-Sent Events
React 19 + Vite for the frontend
TypeScript throughout the application
Sanity as the structured knowledge layer
GROQ for structured retrieval
Gemini 2.5 Flash for planning, extraction, and answer synthesis
HMAC-SHA256 + Merkle trees for investigation certificates

The repository contains the investigation agent, Sanity integration layer, Studio schemas, evidence graph, audit system, certificate generation, and subsystem documentation.

How I Used Sanity

Sanity is not being used as a simple content database in ATLAS.

It is the knowledge layer that the investigation agent depends on.

Structured Content Model

The Content Lake contains six primary document types:

entity
claim
source
relationship
conflict
knowledge_doc

When a URL is ingested, ATLAS fetches the page and uses Gemini to extract structured information.

The resulting data is stored as interconnected Sanity documents.

A claim contains information such as:

Subject
Predicate
Object
Sources
Validity window
Status
Confidence

This means an article is no longer treated as a single text blob.

It becomes a navigable knowledge structure.

How the Agent Queries Sanity

All Sanity retrieval is handled through a dedicated query layer.

The investigation agent does not directly manipulate Sanity documents.

During an investigation, ATLAS performs several structured retrieval operations.

Entity Resolution

The agent uses GROQ matching against:

Entity names
Descriptions
Aliases

This allows the investigation to identify the entities relevant to the user's claim.

Claim Retrieval

Once entities are resolved, ATLAS retrieves claims connected to those entities.

The system batches these queries so that the investigation can retrieve the relevant knowledge efficiently.

Relationship Traversal

ATLAS also retrieves relationships connecting entities.

Relationships can represent concepts such as:

supersedes
introduced_in
depends_on

This allows the agent to reason about relationships instead of treating every statement as independent text.

Source Resolution

Claims and relationships maintain references to their sources.

ATLAS follows these references so that every assertion can be traced back to its provenance.

Knowledge Base Search

ATLAS also queries knowledge_doc documents using GROQ across titles, summaries, and extracted claims.

Conflict Records

Conflict documents are retrieved alongside the claims so competing evidence can be surfaced during the investigation.

From Structured Content to Investigation

The structure of the Sanity data directly drives the investigation process.

Contradiction Detection

ATLAS compares claims using their:

Subject
Predicate
Object
Validity interval

Statements from the same source are not treated as independent evidence.

When competing claims are detected, ATLAS applies explicit source-authority rules.

The current authority hierarchy includes:

Source Type	Authority
Official release	100
Git commit	95
RFC	85
Documentation	80
Community forum	40

Recency is then used as a tie-breaker.

This is important because the agent is not simply asking an LLM:

"Which answer sounds better?"

It is applying deterministic rules to structured evidence.

Evidence Graph

Every investigation can be visualized as an evidence graph.

The graph connects:

Entities → Claims → Sources → Relationships → Conflicts

This makes the provenance of an answer inspectable.

Instead of receiving a final answer with a collection of links, the user can navigate through the evidence structure and understand how the conclusion was reached.

Adversarial Audit

ATLAS does not stop after generating an answer.

The generated answer is passed through a 10-probe adversarial audit.

The probes check areas such as:

Grounding
Unsupported claims
Evidence coverage
Temporal ordering
Entity drift
Contradictions
Source consistency
Counterfactual source removal

The goal is to challenge the answer rather than simply accept the first generated response.

If the retrieved evidence cannot support the claim, ATLAS can return:

INSUFFICIENT_EVIDENCE

instead of guessing.

Cryptographic Investigation Certificates

ATLAS also adds a second layer of verification.

The evidence used during an investigation is committed into an HMAC-SHA256 Merkle certificate.

The certificate incorporates the relevant:

Claims
Sources
Relationships
Conflicts

This creates a tamper-evident record of the investigation.

If the underlying evidence is modified after the certificate is generated, verification fails.

The idea is simple:

The AI should not only explain why it reached a conclusion.

The evidence used to reach that conclusion should also be independently verifiable.

Sanity Context

The project was designed around Sanity's structured-content approach and the Sanity Context ecosystem.

The live application currently performs its structured retrieval through the Sanity GROQ HTTP API.

The application also exposes the configurable Sanity Context MCP endpoint through the Sanity Explorer area.

The current agent implementation uses GROQ for its retrieval path rather than directly invoking the Context MCP client.

This distinction is intentional and documented in the project.

The architecture allows the retrieval layer to evolve toward direct Context MCP integration while keeping the structured Sanity knowledge model intact.

Why Sanity Matters to ATLAS

The important part of this project is not simply storing articles in Sanity.

The investigation would not work the same way if the content were stored only as large blocks of text.

ATLAS needs to understand relationships such as:

Who made the claim?

What exactly was claimed?

Which source supports it?

Which entity does the claim refer to?

Does another source make a conflicting claim?

When was each claim valid?

That is where structured content becomes important.

Sanity provides the foundation for modeling this information as interconnected documents that the agent can query and reason over.

Local Fallback

ATLAS also includes a local corpus fallback.

If Sanity credentials are not available, the application can run against a local corpus that mirrors the same document structures.

The application status endpoint reports whether the system is currently running in:

live
local-corpus

This makes the project easier to test without requiring production credentials.

Sanity Project Details

Project ID: hrexnsmi

Project:

https://www.sanity.io/organizations/ofyfft9qh/project/hrexnsmi

Dataset: production

Document types:

entity
claim
source
relationship
conflict
knowledge_doc

The Studio schemas are available in the repository:

https://github.com/TejasRawool186/Atlas/tree/master/sanity-studio/schemaTypes

What I Wanted to Explore

The broader idea behind ATLAS is that AI systems are becoming very good at generating answers.

The next challenge is making those answers auditable.

For many applications, the question should not be:

"Can the AI answer this?"

It should be:

"Can the AI show me exactly why I should believe this answer?"

That is the direction I explored with ATLAS.

Structured content gives the agent something it can reason over.

Evidence graphs make the reasoning inspectable.

Adversarial probes challenge the result.

Cryptographic certificates make the investigation tamper-evident.

Final Architecture

At a high level, ATLAS follows this architecture:

                    REAL-WORLD CONTENT
                           |
                           v
                    CONTENT INGESTION
                           |
                           v
                  GEMINI EXTRACTION
                           |
                           v
                  SANITY CONTENT LAKE
                           |
          +----------------+----------------+
          |                |                |
          v                v                v
       ENTITIES         CLAIMS         RELATIONSHIPS
          |                |                |
          +----------------+----------------+
                           |
                           v
                  INVESTIGATION AGENT
                           |
          +----------------+----------------+
          |                |                |
          v                v                v
     CONFLICT        SOURCE AUTHORITY    RECENCY
     DETECTION           RULES           ANALYSIS
          |                |                |
          +----------------+----------------+
                           |
                           v
                    EPISTEMIC VERDICT
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
        EVIDENCE        AUDIT       CERTIFICATE
          GRAPH         PROBES       GENERATION
             |             |             |
             +-------------+-------------+
                           |
                           v
                  INSPECTABLE RESULT

Project Links

GitHub:

https://github.com/TejasRawool186/Atlas

Demo Video:

https://youtu.be/TCv8wEBfQmM

Sanity Project:

https://www.sanity.io/organizations/ofyfft9qh/project/hrexnsmi

Agent Session

An agent session can be added here after uploading the relevant transcript through the DEV Agent Sessions uploader.

Conclusion

ATLAS started with a simple question:

What if an AI answer came with an investigation instead of just a response?

That question led to a system where content becomes structured knowledge, claims become first-class objects, sources retain provenance, contradictions become explicit, answers are adversarially tested, and the final evidence can be cryptographically verified.

The goal is not to make AI sound more confident.

The goal is to make AI more inspectable.

Don't just trust the answer. Inspect the evidence.

[Boost]

Tejas Rawool — Sun, 07 Jun 2026 18:08:13 +0000

GitHub “Finish-Up-A-Thon” Challenge Submission

Tejas Rawool

Jun 7

FlashChat - From an Abandoned Prototype to a Secure, End-to-End Encrypted Communication Platform

#devchallenge #githubchallenge #ai #webdev

3 min read

FlashChat - From an Abandoned Prototype to a Secure, End-to-End Encrypted Communication Platform

Tejas Rawool — Sun, 07 Jun 2026 18:04:54 +0000

This is a submission for the GitHub Finish-Up-A-Thon Challenge

What I Built

FlashChat is a privacy-first, zero-login, temporary messaging and file-sharing portal. It is designed to be a secure, zero-config workspace for developers and teams who need to share code snippets, files, and links in absolute privacy.

Under the hood, all communication is fully encrypted client-side using the browser's native Web Crypto API (AES-GCM-256), meaning plaintext never touches the database or server logs. Rooms are generated dynamically with secure alphanumeric codes and disappear automatically after 30 minutes of inactivity. It also features a secure local AI assistant, typing indicators, iMessage-style reactions, quote replies, and live file chunk streaming.

Demo

Here are the live links to the production application:

Live Frontend (Vercel): https://flashchat-blush.vercel.app/
GitHub Repository:: https://github.com/TejasRawool186/flashchat

📸 Application Screenshots

1. Elegant Landing Page & Setup

2. Secure Chat Interface (Desktop)

3. Highly Responsive Mobile Views (iOS & Android)

The Comeback Story

Where We Started (The Abandoned Code)

The project started as a raw, single-file JavaScript prototype. It was an abandoned monolithic App.jsx file (over 800 lines of spaghetti code) containing mixed logic for Socket.IO events, file chunking, UI components, and state management. The code was prone to runtime errors, vulnerable to XSS attacks, completely lacked mobile responsiveness, and offered zero data encryption.

What I Changed, Fixed, and Added

To turn this prototype into a production-grade secure application, I executed a complete overhaul:

Decomposed Architecture: Split the monolithic App.jsx into 17 clean React + TypeScript modules with strict type safety.
End-to-End Cryptography: Integrated client-side ECDH/PBKDF2 key derivation from the alphanumeric room codes, encrypting text messages and shared file chunks using AES-256-GCM before sending them.
E2E-Wrapped AI Bot: Built an AI Assistant (/ask <prompt>) that calls Google Gemini AI through backend proxies (to keep keys secure) and returns responses encrypted client-side to the room.
Enhanced Chat Socials: Added quote threads, message reaction badges (👍 ❤️ 😂 😮 😢 🙏), typing notifications, and blue double-check read receipts.
Mobile Responsiveness: Replaced the static layout with an overlay sliding drawer sidebar on mobile, circular compact header buttons, and a responsive emoji picker.
Security Hardening: Integrated Nginx reverse proxying, rate-limiting middleware, CORS configuration, Helmet CSP headers, and SSRF scrapers.

My Experience with GitHub Copilot

As a developer, rewriting legacy code and implementing complex cryptography can feel overwhelming. GitHub Copilot acted as a 24/7 pair programmer, speeding up my workflow:

TypeScript Migration: Copilot analyzed the 800-line prototype and generated clean React prop interfaces and hooks. It predicted correct React event types (such as React.DragEvent and HTMLTextAreaElement), saving me dozens of compilation check cycles.
Cryptographic Implementation: Writing Web Crypto pipelines involves dense parameters. Copilot suggested correct iteration counts for PBKDF2, initialization vector (IV) structures, and helped design key import/export methods in crypto.ts without needing to constantly check MDN documentation.
Layout and Flexbox Debugging: When sent message bubbles clipped off-screen on mobile viewports, Copilot identified that the flex layout was expanding beyond its bounds. It suggested adding min-width: 0; and overflow: hidden; to the .chat-main wrapper—resolving the horizontal layout overflow instantly.
SSRF Protections: Copilot helped write robust security checks inside the Link Preview scraper to verify that outgoing requests do not target private IP subnets on our VPS.

🌐 Breaking Language Barriers: Building a Real-Time Multilingual Chat App with Next.js & Lingo.Dev

Tejas Rawool — Thu, 05 Feb 2026 18:33:09 +0000

Communication is the foundation of every online community. But the moment people from different countries join the same space, one invisible problem shows up fast: language.

You might be comfortable chatting in English, while someone else prefers Hindi, Spanish, or Japanese. Most chat apps assume everyone will “figure it out” — but in reality, that often leads to confusion, hesitation, or people staying silent.

I wanted to fix that.

So I built FlowTalk, a real-time multilingual chat application where users can write in their own language and instantly read messages in theirs — without breaking the flow of conversation.

In this article, I’ll walk through how I built it, the unexpected translation problems I ran into, and how I used Lingo.dev to solve them in a clean, scalable way.

🚀 The Tech Stack

I kept the stack modern but practical:

Frontend: Next.js 16 (App Router) + React 19
Styling: Tailwind CSS v4
Backend: Next.js API routes + MongoDB
Real-time updates: Pusher / polling
Translation layer: Lingo.dev

Nothing exotic — just tools that work well together.

🏗️ High-Level Architecture

The core challenge wasn’t how to translate text.

It was how to translate text without slowing down a real-time chat.

Here’s the flow I ended up with:

A user sends a message (for example, “Hello everyone”)
The server receives the message and detects the source language
A Translation Engine checks if translations already exist (cache first)
If not cached, it calls Lingo.dev to generate translations
The message is broadcast to all connected clients
Each client displays the message in the user’s preferred language

Only one message is sent — translation is treated as metadata, not a new chat message.

🧠 The Real Translation Problems (That No One Mentions)

This is where things got interesting.

Once real users started testing the app, I discovered problems that don’t show up in simple demos.

1. Script ≠ Language (Hinglish Is Real)

One of the most common messages I saw was something like:

muje aapki help chahiye

This is Hindi, but written using English letters (often called Hinglish).

Most systems either:

Treat it as English (wrong), or
Don’t translate it at all (also wrong)

So FlowTalk detects language intent, not just the alphabet used.

Correct result:

I need your help

2. Brand Names Should Not Be Translated

Auto-translation loves to translate everything — including things it absolutely shouldn’t.

Examples:

ChatGPT
Discord
React
Next.js

If these get translated, the message becomes confusing fast.

I needed a way to protect proper nouns and technical terms.

3. Broken Characters & Formatting Issues

Another subtle issue:

Some platforms and fonts don’t handle all scripts perfectly.

That can lead to:

Broken characters
Random symbols
Numbers appearing where text should be

To avoid this, I normalized output and ensured Unicode-safe formatting across the pipeline.

💡 The Heart of FlowTalk: The Translation Engine

At the center of everything is a small but powerful service: TranslationEngine.

Instead of scattering translation logic everywhere, I wrapped it in a single layer that handles:

Language detection
Caching
Glossary protection
Error handling

Here’s a simplified version:

// src/services/TranslationEngine.ts

import { LingoDotDevEngine } from "lingo.dev/sdk";

export class TranslationEngine {
  private lingoEngine: LingoDotDevEngine;

  constructor(apiKey: string) {
    this.lingoEngine = new LingoDotDevEngine({
      apiKey,
    });
  }

  async translateText(
    content: string,
    sourceLang: string,
    targetLang: string
  ): Promise<string> {
    if (sourceLang === targetLang) {
      return content;
    }

    const result = await this.lingoEngine.localizeText(content, {
      sourceLocale: sourceLang,
      targetLocale: targetLang,
    });

    return result;
  }
}

This is where Lingo.dev really shines.

Instead of simple word replacement, it provides context-aware translation, which makes conversations feel natural rather than robotic.

Chekout My Repo here: https://github.com/TejasRawool186/FlowTalk

special thanks to @sumitsaurabh927 @maxprilutskiy for the continious guidance