DEV Community: Shikha Shukla

👻 Memory Ghost: Bringing Forgotten Files Back to Life with Local AI | Gemma 3 + Ollama

Shikha Shukla — Tue, 27 Oct 2026 13:49:14 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

👻 Memory Ghost — Bringing Forgotten Files Back to Life with Local AI

Our computers are full of digital ghosts: old notes, assignments, research documents, and forgotten files whose contents we can barely remember.

Memory Ghost is a local-first AI assistant that helps users rediscover what's inside their files. Select a folder, choose a supported text file, and let AI generate a summary, identify topics, extract key points, and suggest a memory category.

I interpreted the Ghost in the Machine theme as the forgotten information hiding in our digital lives. Instead of letting useful knowledge disappear into cluttered folders, Memory Ghost helps bring it back to the surface.

The current version supports .txt, .md, .json, and .csv files.

Demo

🎬 Watch Memory Ghost in action: Watch the demo on YouTube

The video demonstrates the application running locally and shows the AI-powered file-analysis workflow.

Code

👩‍💻 GitHub Repository: Shikha18Shukla/Memory-Ghost

The project uses a React + TypeScript frontend and a Python + FastAPI backend, with local AI inference through Ollama.

How I Built It

The core of Memory Ghost is Gemma 3 (gemma3:4b) running locally through Ollama.

Here's how the pieces work together:

React + TypeScript: Provides the user interface for selecting folders and exploring analysis results.
FastAPI: Handles folder selection, file validation, reading supported files, and AI-analysis requests.
Ollama: Runs the model locally on the user's machine.
Gemma 3: Analyzes file content and generates summaries, topics, key points, and a suggested memory category.
SQLite: An initial database schema has been added as the foundation for future persistent memory storage.

The workflow is simple: choose a folder, select a supported file, send its text to the local model, and review the generated results.

The current version is a working prototype. Saving and searching previously analyzed memories are planned improvements, rather than completed features.

Why Does Open Innovation Matter?

I chose an open-weight model because I wanted to explore AI beyond the usual hosted-API workflow.

Using Gemma 3 with Ollama made it possible to build an application around local inference, giving users more control over where their files are processed and allowing developers to experiment with the model on their own machines.

Open innovation makes experimentation more accessible. Developers can learn from available tools, adapt them to specific problems, and build practical applications without depending exclusively on a proprietary hosted AI service.

For Memory Ghost, this matters because the application works with personal notes and documents. Local inference can reduce the need to send their contents to an external AI provider, although local execution alone does not guarantee complete security.

This project is my exploration of how open-weight AI can make everyday information easier to rediscover.

My Agent Session

DevRelay session: Not included. This section is optional, so the submission can proceed without it.

The Spirit of It

Somewhere on our computers, there are notes we wrote months ago, ideas we thought we'd lost, and documents we know contain something important.

We don't always lose information by deleting it. Sometimes, we lose it simply by forgetting where it is.

Memory Ghost is about bringing those forgotten digital memories back to life. 👻

The goal isn't to make the AI remember everything for us. It's to make the knowledge we've already saved easier to find, understand, and use again.

Prize Categories

Best Use of Gemma: Memory Ghost uses Gemma 3 (gemma3:4b) through Ollama as its core text-analysis model.

Memory Ghost was developed by adapting the existing LazyDesk-AI codebase. The project acknowledges this origin, and I am checking the applicable licensing and challenge eligibility requirements before claiming contest eligibility.

LazyDesk AI: Let Your Local AI Handle the Digital Mess 🦥💜

Shikha Shukla — Sat, 24 Oct 2026 15:58:36 +0000

LazyDesk AI: Let Your Local AI Handle the Digital Mess 🦥💜

This is a submission for the Hacktoberfest Open-Source AI Challenge — Week 3: Slow and Steady.

What I Built

Have you ever downloaded a PDF, saved a screenshot, renamed a document three times, and then completely forgotten where you put it?

Same problem, too many files, and somehow the job of organizing them always gets postponed.

That's why I built LazyDesk AI — a local-first, AI-powered file organizer designed to make digital clutter less overwhelming.

Instead of relying entirely on manually organizing files, LazyDesk AI explores how a local language model can help suggest clearer filenames and useful categories based on file metadata.

The goal is simple: spend less time deciding where files belong and more time doing the work that actually matters.

✨ What LazyDesk AI brings to the table:

🗂️ A focused workspace: A dashboard with Overview, File Organizer, Activity, and Settings pages.
🧠 AI-powered suggestions: Gemma 3 running through Ollama can analyze file metadata and generate structured suggestions.
🔌 Local AI status: Check whether the backend can connect to Ollama and whether the model is available.
🎨 A clean interface: A dark, violet-accented UI designed to make organizing feel less like another chore.
🔐 A local-first approach: AI inference runs through Ollama on your own machine rather than requiring a hosted AI API.

The project is still evolving. The dashboard currently includes sample workspace data, and I am working toward a complete folder-selection and organization workflow. I want to be transparent about that: this is a working prototype, not yet a fully automated file manager.

Demo

GitHub repository: Shikha18Shukla/LazyDesk-AI

The repository contains the source code and setup instructions to run the project locally.

The application currently runs locally, so I don't have a public hosted demo to share yet. The next milestone is to connect the folder-selection flow end to end and demonstrate the complete experience with real files.

Code

Explore the project here:

🔗 View LazyDesk AI on GitHub

The project is organized into two main parts:

Frontend: React, TypeScript, and Vite.
Backend: Python and FastAPI, with an endpoint for analyzing file metadata.

The backend communicates with Ollama locally and uses gemma3:4b to request structured AI suggestions.

The repository also includes a README with installation instructions, the API overview, troubleshooting guidance, and the project's roadmap.

How I Built It

The central idea was to build around an open-weight model rather than making a hosted AI service a mandatory dependency.

Here's the architecture:

       User
        |
        v
+----------------------+
| React + TypeScript   |
| LazyDesk AI UI       |
+----------------------+
        |
        v
+----------------------+
| Python + FastAPI     |
| Local API            |
+----------------------+
        |
        v
+----------------------+
| Ollama               |
| Local inference      |
+----------------------+
        |
        v
+----------------------+
| Gemma 3 (4B)         |
| File metadata        |
| analysis and ideas   |
+----------------------+
        |
        v
+----------------------+
| Structured AI        |
| suggestions          |
+----------------------+

1. The interface

I built the frontend using React and TypeScript, with Vite for development. The interface is organized into separate pages so that the project can grow beyond a single file-upload screen.

2. The backend

FastAPI provides the API layer. The health endpoint checks whether Ollama is reachable and whether the configured model is available. The analysis endpoint accepts a filename, extension, and file size, then sends a prompt to the local model.

3. The open-weight model

I chose Gemma 3 (4B) and run it through Ollama.

The model receives file metadata rather than needing the entire file's contents for the current analysis workflow. It is asked to return a structured suggestion that the application can use.

4. Working within real hardware limits

I developed this on a laptop without a dedicated GPU. That made local inference speed an important practical consideration.

It also made the project more interesting: I wanted to explore how useful local AI could be on everyday hardware, rather than assuming everyone has access to an expensive GPU or a paid cloud API.

The current version is a foundation. Connecting real folder selection, adding safe rename and move operations, and measuring performance are still part of the work ahead.

Why Does Open Innovation Matter?

For this project, open innovation isn't just a way to avoid a paid API. It changes the way the application can be built.

1. More control over personal data

File names can reveal a surprising amount about someone's life: academic work, job applications, personal documents, and projects.

With local inference, the model can process the metadata on the user's own machine. The intended workflow does not require sending that metadata to a third-party AI API. Of course, the actual privacy guarantees still depend on how the application is configured and implemented.

2. No mandatory per-request AI bill

Once the model is downloaded, local inference doesn't require paying a hosted AI provider for every request. Electricity, hardware resources, storage, and setup still have costs, but experimentation becomes much more accessible.

3. Freedom to experiment

Using an open-weight model makes it possible to explore different prompts, change the model, and test different approaches without rebuilding the application around a single closed provider.

4. AI that's closer to the user

A local-first design can reduce dependence on internet connectivity for inference after the model has been downloaded and the local services are running.

For a utility that deals with personal files, that is a meaningful design choice.

Open innovation made it possible for me to experiment with a practical AI-powered desktop utility while learning how the UI, API, and local model work together.

My Agent Session

I used AI-assisted development while building the interface and project structure.

I haven't included a DevRelay session link because I don't have a verified public session URL to share yet. I'd rather leave that out than publish a link that doesn't work.

The Lazy Payoff 🦥

The payoff I'm aiming for is fewer repetitive decisions.

Imagine a folder containing files like:

notes_final.pdf
notes_final_v2.pdf
IMG_20261021_104533.png
download (7).pdf

A future end-to-end version of LazyDesk AI could inspect the metadata, suggest clearer names, and group related files for the user to review.

For example, it might suggest a more descriptive filename for a lecture PDF or recommend grouping screenshots separately from documents.

Those are illustrative examples of the intended workflow, not claims of measured results from the current prototype.

I haven't measured time saved yet. My next step is to test the workflow with a real folder, compare the manual process with AI-assisted suggestions, and record how long each takes.

Because saving time should be demonstrated, not just promised.

Prize Categories

Best Use of Gemma — using Google's Gemma 3 open-weight model through Ollama for local AI-powered file metadata analysis.

I'm entering only the category that directly matches the technology used in this project.

Final Thoughts 💜

LazyDesk AI started with a small idea: what if organizing digital clutter didn't always require another round of manual effort?

Building it has given me an opportunity to explore local inference, open-weight models, API integration, and the practical challenges of making AI useful on everyday hardware.

It isn't finished yet, and that's part of the journey. The next challenge is turning the prototype into a reliable workflow that works with real folders and gives users control over every change.

Because sometimes productivity doesn't mean doing more.

Sometimes it means letting the computer handle a little more of the boring stuff.

Build thoughtfully. Automate carefully. Stay a little lazy. 🦥

Hacktoberfest #HF26Challenge #OpenSourceAI #Gemma #Ollama #Python #React #LocalAI #Productivity

I Built DukaanDraft: A Local AI Content Studio for Small Businesses

Shikha Shukla — Tue, 13 Oct 2026 19:25:56 +0000

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

What I Built

Small businesses selling through Instagram, WhatsApp, and online marketplaces often spend a surprising amount of time writing product descriptions, social media captions, and sales messages.

For a small clothing reseller or independent shop owner, every new product means another round of writing content that sounds attractive, describes the product accurately, and encourages customers to take action.

I built DukaanDraft, a local-first AI-powered product content studio that turns product details into ready-to-use marketing content.

A seller enters the product name, category, price, features, and target audience, then selects English, Hindi, or Hinglish. DukaanDraft generates:

Three distinct Instagram caption options.
A descriptive product title.
A WhatsApp sales message.
A detailed product description.
Product selling points.
Relevant hashtags.
A call-to-action suggestion.
A marketplace listing title.

The goal is to help independent sellers spend less time drafting repetitive content and more time running their businesses.

The potential customers are clothing resellers, Instagram shop owners, independent retailers, and other small businesses that need product content regularly. Whether they would pay for it is something I want to validate through real user feedback.

Demo

DukaanDraft currently runs locally on my machine.

Screenshots and demo: I'll include a screenshot of the redesigned interface and a short recording showing the product-content generation workflow.

Youtube demo: https://youtu.be/7uVQsl0cFpA

The application uses local inference, so generation time depends on the computer running the model. On my CPU-based setup, a complete generation takes approximately 111 seconds.

Code

GitHub repository: https://github.com/Shikha18Shukla/DukaanDraft

The repository contains the Flask backend, prompt templates, Ollama integration, responsive frontend, and automated tests.

How I Built It

I built DukaanDraft using:

Python and Flask for the backend and API endpoints.
Ollama as the local inference runtime.
Gemma 3 4B as the open-weight language model.
HTML, CSS, and vanilla JavaScript for the frontend.
Python unittest for automated testing.

The application follows a simple workflow:

Validate the seller's product details.
Construct a category-aware prompt.
Send the prompt to Gemma 3 4B through the local Ollama HTTP API.
Parse and validate the model's structured JSON output.
Normalize hashtags and handle malformed responses with a bounded retry.
Display the generated content in separate cards with copy buttons.

One of the biggest challenges was improving the quality of the generated content. A generic product description isn't particularly useful to a seller, so I redesigned the prompts to produce three different caption strategies: product-led, lifestyle-oriented, and short-and-punchy.

I also added rules against inventing discounts, stock availability, delivery promises, product specifications, certifications, or customer testimonials.

The frontend received a complete visual refresh with a warm ivory background, burgundy accents, editorial typography, responsive layouts, and a more polished content-generation workspace.

The reported automated test run completed with 73 passing tests. I also tested real inference through the local Ollama API and checked Python and JavaScript syntax.

Why Does Open Innovation Matter?

Open-weight AI is central to how DukaanDraft works. It isn't simply a conventional website with an AI feature added on top.

By running Gemma 3 4B locally through Ollama, I can experiment with prompts, change model configurations, validate outputs, and build a useful workflow without depending on a paid, hosted LLM API.

This approach offers several advantages for the intended audience:

Cost control: There is no per-request charge from a third-party inference API.
Local processing: Product information is sent to the configured local Ollama endpoint rather than a hosted LLM provider.
Flexibility: The application can evolve as models and prompting strategies improve.
Transparency: The backend, prompt construction, output validation, and error handling can be inspected and modified.

Local AI also comes with trade-offs. Inference can be slow on CPU-only hardware, and a smaller model can produce imperfect output. My measured generation time was approximately 111 seconds, so I designed the interface to communicate the wait honestly rather than promise instant results.

For this project, open innovation made it possible to build and test a complete local AI content-generation workflow without paying for hosted model inference.

What I Learned

Building DukaanDraft taught me that connecting a language model to a form is only the beginning.

Useful AI products also need structured output validation, carefully designed prompts, error handling, a clear user experience, and honest communication about limitations.

The next challenge is to put DukaanDraft in front of actual small-business sellers, find out how much editing the generated content requires, and determine whether it saves enough time to become a product someone would pay for.

If you run a small business, what repetitive content-writing task would you want a local AI assistant to handle? I'd love to hear your ideas.

Nature Saathi: An AI Companion That Sends You Outside

Shikha Shukla — Wed, 07 Oct 2026 16:37:49 +0000

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

What I Built

We keep using our phones to learn about the world instead of looking at the world around us. We'll open an app to identify a bird while the bird is sitting ten feet away, ignored.

So I asked myself: what if AI didn't give us another reason to stare at a screen?

Nature Saathi is an AI-powered outdoor learning companion that turns an ordinary walk into a real-world nature expedition. Saathi (साथी) means "companion" in Hindi. Most apps want your eyes on the screen. Nature Saathi wants them on the sky, the soil, and the sparrow on the wall.

You tell it three things: how much time you have, how adventurous you feel, and what you're curious about (leaves, birds, and so on). A local AI model writes a custom expedition just for you. You read one mission, put the phone away, go explore, come back, and tap complete.

📱 The screen should be the shortest part of the experience.

Who is it for? Curious kids, families, students, and anyone who wants a nudge to notice the world. It also suits anyone who has caught themselves "going for a walk" while scrolling.

The Expedition Loop

The whole product is built around one idea: AI creates the mission, you leave the screen, and you come back with a discovery.

Key features

🎯 Tailored expeditions: choose duration, difficulty, and interest, and get a fresh mission list
🧠 Local AI via Ollama: missions are generated on your own machine, with no cloud AI account needed
🚶 One mission at a time: a focused, phone-light flow with a progress indicator
🔄 Refresh-proof runs: your active expedition survives an accidental refresh (it lives in the tab's sessionStorage)
🔍 Review What I Discovered: revisit your completed missions once you're back
🛡️ Safety-aware output: every expedition includes a safety note, and unsafe model output is rejected
🔒 Private by design: no accounts, no database, no uploads, and closing the tab clears everything

Demo

Youtube demo video : https://youtu.be/5P2vqBBz-FI

Homepage

Expedition setup: choosing time, difficulty, and an interest like 🌿 Leaves

Mission generation: Gemma writes the outdoor challenge

Active expedition: the key moment. The app literally tells you to put your phone away.

Code

Shikha18Shukla / nature-saathi

An open-source AI companion that turns outdoor walks into fun nature exploration missions.

🌿 Nature Saathi

Your phone is the map. The world is the classroom.

An AI-powered outdoor learning companion that turns an ordinary walk into a real-world nature expedition.

Quick Start · How It Works · API · Tests · Roadmap

🧭 What is Nature Saathi?

Saathi (साथी) means companion. Most apps want your eyes on the screen. Nature Saathi wants them on the sky, the soil, and the sparrow on the wall.

Pick how long you have, how adventurous you feel, and what you're curious about. A local AI model writes a custom expedition for you. You read one mission, put the phone away, go explore, come back, and tap complete.

📱 The screen should be the shortest part of the experience.

🎮 The Expedition Loop

   ┌───────────┐     ┌───────────┐     ┌───────────┐     ┌───────────┐
   │  1. PICK  │ ──▶ │  2. READ  │ ──▶ │ 3. EXPLORE│ ──▶ │ 4. RETURN

…

View on GitHub

The README covers setup, Ollama configuration, the API, tests, and a roadmap.

How I Built It

The stack

Layer	Tech
Frontend	HTML, CSS, vanilla JavaScript
Backend	Python, Flask
AI	Ollama running Gemma 3 4B locally
Tests	Python `unittest` + a Node test for frontend logic

Architecture

        Nature Saathi
             │
      Browser / UI
             │
          Flask
             │
     Mission Service
             │
          Ollama
             │
        Gemma 3 4B
             │
     Generated Mission
             │
          Browser

The browser sends your choices to a single endpoint:

POST /api/missions/generate
{
  "duration_minutes": 45,
  "difficulty": "Explorer",
  "interest": "Birds"
}

Flask hands the request to a mission service, which fills a prompt template and asks Gemma (through Ollama) for an expedition. The response contains a title, theme, intro, a safety note, and a list of missions. Each mission has a task, an observation_cue (what to look, listen, or feel for), a learning_note (the "aha" fact), and an evidence_type.

Never trust the model

The part I'm proudest of is the validation layer. The mission service checks everything the model returns. Malformed, incomplete, or unsafe output never reaches the page. Errors always share one shape, so the frontend can respond predictably:

{ "error": { "code": "...", "message": "..." } }

Status	Meaning
400	Invalid request
503	Ollama is unavailable
502	Model output was malformed, incomplete, or unsafe

When your product tells people to walk outside, "the AI said so" isn't good enough. Every expedition has to carry a safety note.

The challenge: local AI isn't always fast

I'll be honest: running a model locally is slower than calling a hosted API. My first Gemma generations took significantly longer than a typical API call, and the default timeouts failed before the model finished.

So I:

Increased the Ollama timeout to match real local inference times
Handled generation failures gracefully, with clear 503/502 errors and friendly messages instead of a broken page
Kept the loading moment short and calm, since the whole point is that the screen time is brief

That trade-off shaped the design. Because generation takes a moment, Nature Saathi generates the whole expedition once, up front. Then you put the phone away and never wait on the AI mid-walk.

Testing

The test suite is deliberately dependency-light:

python -m unittest discover -s tests -v   # mission service checks
node tests/test_frontend_render.js        # navigation, progress, refresh recovery, bad data

I Took Nature Saathi Outside 🌿

The mission I got: Find different types of flowers around you

Where I went: A park near my hostel.

What happened: I chose 45 minutes and flowers, and Nature Saathi gave me five field notes: Color Spectrum, Shape Seekers, Silent Observation, Flower Count, and Floral Sounds.I took it to a park near my hostel, and my friend came along. We did the flower activity together.

There were so many flowers: yellow, pink, purple, and white, plus some wild flowers growing on their own. I expected to find a few flowers. I didn't expect how much beauty I had been walking past.

The best part wasn't only the flowers. Once we stopped and really looked, we saw butterflies, honeybees, and other tiny insects moving from flower to flower. We also noticed how strong and different the fragrance was from each one.

While completing the missions, I felt calm. Doing it with a friend made it even better, because we kept pointing things out to each other.

I loved this experience, and we both enjoyed it a lot.

What I discovered:

Why Does Open Innovation Matter?

Nature Saathi uses Ollama to run Gemma 3 locally instead of sending every interaction to a hosted AI API. For this particular project, that open approach was better than a closed one in several ways:

🔒 Privacy is real, not a promise. A nature app for kids and families shouldn't ship their interests to a third party. Because inference happens on the user's machine, nothing leaves it. Combined with no accounts, no database, and a server bound to 127.0.0.1, the privacy story is simple to verify.
🔑 No API key, no signup. The core experience works with just ollama pull gemma3:4b. That matters for classrooms, community groups, and anyone who can't or won't hand over a credit card.
💸 No per-request cost. A mission generator is the sort of thing people want to run again and again. With local inference, a hundred expeditions cost the same as one: nothing.
🔁 Swappable models. The model is one environment variable (OLLAMA_MODEL). If a better open-weight model arrives next month, Nature Saathi can adopt it without rewriting the app.
🌱 No lock-in. The project can keep evolving without depending on one provider's pricing, policies, or availability.

There's also a philosophical fit. An app about noticing the world around you is stronger when the technology behind it is something you can inspect, run, and change yourself.

What's Next

📸 Photo discovery: bring your finding back, identify it with a local vision model, and get interesting facts
🖨️ Printable expedition cards, so you can leave the phone at home entirely
🌳 More themes: trees, insects, clouds, night sky
👨‍👩‍👧 Group and family expedition mode
🌐 Multilingual missions (English, हिन्दी, and more)

Contributions and ideas are welcome. Open an issue and say hello!

# Are we building AI tools for learning, or just better ways to avoid learning?

Shikha Shukla — Tue, 06 Oct 2026 18:22:05 +0000

I've been thinking about this while building AI-based learning tools.

AI can explain a difficult concept in seconds, translate something, generate examples, write code, create quizzes, and even act like a personal tutor.

But there's a question I keep coming back to:

At what point does an AI learning assistant stop helping us learn and start doing the learning for us?

For example, if I'm learning programming and AI gives me the solution immediately, I may finish the problem faster—but did I actually understand it?

On the other hand, an AI that gives hints, asks questions, explains mistakes, and adapts to my level could potentially make learning much more effective.

So I'm curious:

How do you personally use AI while learning?

Do you prefer AI to:

Give you the answer?
Give you hints first?
Explain the concept and make you solve it?
Act like a tutor and ask you questions?

And where do you think the line is between AI-assisted learning and AI doing the learning for us?

Would love to hear how other developers approach this. 👇

What If an AI Could Answer a Legal Question Based on the Law That Existed At That Time?

Shikha Shukla — Mon, 05 Oct 2026 09:54:10 +0000

What If an AI Could Answer a Legal Question Based on the Law That Existed At That Time?

I've been working on a research project called Indian Constitution Temporal QA, and it started with a question that sounds simple:

Can an AI answer a question about the Indian Constitution while taking the date of the question into account?

Most question-answering systems treat a document as if it is static.

Legal documents aren't.

The Indian Constitution has been amended repeatedly. Articles can change, provisions can be inserted, modified, or removed, and the version of the law that applies can depend on when you're asking the question.

That creates a problem for AI systems.

An answer can look completely correct today while being wrong for a question about what the Constitution said 20, 30, or 50 years ago.

So instead of building another general-purpose legal chatbot, I'm trying to build a system that understands time as part of the question.

What I'm building

The project is a dataset and retrieval pipeline for temporal question answering over the Indian Constitution.

The goal is to track constitutional provisions across amendments and eventually answer questions such as:

"What did Article X provide before the relevant amendment?"

"Which constitutional provision was applicable in a particular year?"

The system needs to do more than retrieve a paragraph containing the right keywords.

It needs to determine:

What was the relevant provision?

Which amendment changed it?

When did that change take effect?

Which version should be used for the question being asked?

That's where the temporal part comes in.

Why I think this is interesting

A normal RAG system might retrieve the latest version of a constitutional article and confidently generate an answer.

But for historical legal questions, the latest version may be exactly the wrong evidence.

That's the failure mode I'm interested in.

I want to explore whether adding amendment history and temporal metadata can make retrieval more reliable for questions where the answer depends on a specific point in time.

What I've built so far

I'm currently working on:

Extracting the Indian Constitution from source documents
Parsing it into individual Articles and structured records
Identifying constitutional amendments
Tracking article-level changes across amendments
Building structured amendment metadata
Preparing the data for temporal retrieval and question answering

The current dataset tracks changes across 106 constitutional amendments from 1951–2023.

The project is still under development, so I'm treating this as a research/engineering experiment rather than claiming that the problem is solved.

The difficult part isn't the chatbot

One thing I've realized while building this is that the hardest part isn't putting an LLM behind an API.

The difficult part is creating trustworthy context.

If the underlying dataset doesn't preserve:

article → amendment → change → date

then even a very capable model can produce a convincing answer from the wrong version of the law.

That's why I'm spending much more time on data extraction, normalization, and temporal relationships than I initially expected.

What I want to test next

The next stage is to build a question-answering benchmark around these historical constitutional questions.

I'll eventually want to compare things like:

Standard retrieval vs. temporal-aware retrieval

and measure whether explicitly incorporating amendment history actually improves:

retrieval accuracy
temporal correctness
evidence selection
answer reliability

I also want to test cases where the current version of an article is deliberately misleading for a historical question.

Why I'm building this

I'm interested in the intersection of AI, information retrieval, and law, but I'm also interested in a broader question:

Can an AI system know that the most relevant information isn't necessarily the most recent information?

For legal, historical, regulatory, and policy documents, that distinction matters.

This project is my attempt to explore it through the Indian Constitution.

The project is still evolving, but I'll be documenting the dataset, pipeline, experiments, and results as I go.

GitHub: Coming soon — I'm currently developing the dataset and retrieval pipeline.

If you've worked on temporal retrieval, legal NLP, RAG, or historical document QA, I'd genuinely love to hear how you approached it.

# 🪷 Sanskrit Saathi: I Built a Local AI Study Companion for My BAMS Friend

Shikha Shukla — Sun, 04 Oct 2026 08:49:45 +0000

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

What I Built

I built Sanskrit Saathi, a local AI study companion for my friend who is studying BAMS (Bachelor of Ayurvedic Medicine and Surgery).

Sanskrit is a core part of BAMS, but it's hard when you don't come from a Sanskrit background. My friend was struggling with exactly that.

The problem wasn't that she couldn't study. It was that a single Sanskrit word or shloka could turn into five separate tasks:

What does this mean?
How do I pronounce it?
What does each word mean on its own?
What's the simple Hindi meaning?
And when it shows up in an Ayurveda context, what am I supposed to take from it?

So I built a small tool around that exact problem. You paste a Sanskrit word, sentence, or shloka, and Sanskrit Saathi turns it into a structured lesson:

	What you get
📜	Original Sanskrit
🔤	IAST transliteration
🇬🇧	Simple English meaning
🇮🇳	Simple Hindi meaning
🧩	Word-by-word breakdown
📚	Context and usage
⚠️	A note about uncertainty
🧠	A quiz to practice what you just read

Two study modes

🌿 General Sanskrit focuses on learning the Sanskrit itself.
🪷 BAMS Sanskrit adds Ayurveda/BAMS context when it's relevant.

Both the explanation and the quiz follow whichever mode is selected.

I didn't want to build another general-purpose chatbot. I wanted something my friend could open, paste a line from her textbook into, and actually use while studying.

I tested it with a BAMS student, and she found the word-by-word breakdown and Hindi explanations particularly useful when working through unfamiliar Sanskrit terms.

Demo

 🎥 **Watch the demo:** https://youtu.be/DCMK8N5VwmQ

Sanskrit Saathi runs locally with Ollama, so there's no hosted link. The video shows the full flow.

The demo covers:

Pasting a Sanskrit word or shloka (or tapping a Quick practice chip)
Switching between General and BAMS mode
Getting an explanation from local Gemma
Reading the IAST transliteration and word-by-word meanings
Generating a quiz and checking answers

Screenshots

BAMS Sanskrit mode

General Sanskrit explanation

Quiz mode

Code

Shikha18Shukla / sanskrit-saathi

An AI-powered Sanskrit study companion for BAMS students using local Gemma 3.

🪷 Sanskrit Saathi

Your AI study companion for Sanskrit & Ayurveda

Understand Sanskrit. Learn Ayurveda. Study smarter.

An AI-powered Sanskrit study companion built for BAMS students. Runs fully on your own computer. No paid API. No cloud AI.

🌿 What is Sanskrit Saathi?

Sanskrit can be hard for BAMS students who don't have a strong Sanskrit background. Sanskrit Saathi helps by turning any Sanskrit word, sentence or shloka into a clear, beginner-friendly lesson, then testing you on it.

Paste Sanskrit → get an explanation → take a quiz → repeat. 🔁

✨ Features

Feature	What you get
📜	Sanskrit explanation	A structured breakdown of any word, sentence or shloka
🔤	IAST transliteration	Accurate Roman script, generated with `indic-transliteration`
🇬🇧	English meaning	Simple, easy-to-read English
🇮🇳	Hindi meaning	Simple Hindi explanation
🧩	Word-by-word breakdown	See how each word builds the meaning
📚	Context & usage	Where and how the text is

…

View on GitHub

(If the embed doesn't render, use the link: https://github.com/Shikha18Shukla/sanskrit-saathi)

Run it yourself

git clone https://github.com/Shikha18Shukla/sanskrit-saathi
cd sanskrit-saathi
python -m venv venv
.\venv\Scripts\activate        # macOS/Linux: source venv/bin/activate
pip install -r requirements.txt
ollama pull gemma3:4b
python app.py

Then open http://127.0.0.1:5000 in your browser.

How I Built It

The stack

Python + Flask for the backend and two API endpoints
Ollama + Gemma 3 4B for the AI, running locally on my own machine
indic-transliteration for IAST
Plain HTML, CSS, and vanilla JavaScript for the frontend, with no framework and no build step

Architecture

Sanskrit Text + Study Mode
          ↓
  Sanskrit Saathi Web UI
          ↓
     Flask Backend
       (/api/explain, /api/quiz)
          ↓
        Ollama
          ↓
      Gemma 3 4B
          ↓
  Explanation / Quiz
          ↓
        Web UI

The frontend sends { text, study_mode } to /api/explain or /api/quiz, where study_mode is "general" or "bams". The backend adjusts the prompt for the selected mode and returns plain text, either { "answer": ... } or { "quiz": ... }.

Transliteration comes from a library

IAST transliteration is generated by the indic-transliteration library on the backend, not written by the model. Transliteration is a mechanical conversion, so I wanted a deterministic tool for it and left the explaining to the model.

A frontend that expects messy output

The backend returns plain text, and a small local model doesn't always format things the same way twice. So I designed the UI defensively:

It looks for section headings (Original Sanskrit, IAST, English, Hindi, word-by-word, context, note) and turns them into separate cards.
If the response doesn't parse cleanly, it falls back to a readable formatted card instead of breaking.
The quiz works the same way. It tries to detect questions and A/B/C/D options and builds question cards, and if it can't, it shows the original quiz text.
Everything the model returns is rendered as text, never as HTML.

Small details for real study sessions

Copy buttons on the Original Sanskrit, the IAST, and the full explanation, so notes can go straight into a notebook app.
Quick practice chips that fill the input without sending anything to the AI.
Ctrl + Enter to explain.
Friendly loading and error states. Gemma runs on a local machine, so answers take a moment. The app says "Understanding your Sanskrit..." instead of sitting silent, and if Ollama isn't running it tells you to start it rather than showing a raw error.
Accessibility: keyboard-friendly controls, visible focus states, aria-live updates, and reduced-motion support.

Why Does Open Innovation Matter?

For this project, an open-weight model is what makes the whole idea practical.

It costs nothing per question. A student shouldn't have to pay for every shloka she looks up.
Her study material stays on her computer. Gemma runs locally through Ollama, so the text she pastes is not sent to a hosted AI provider.
**I could choose a model that fits. Gemma 3 4B runs locally on my CPU-only machine. The tradeoff is that responses take longer than they would with a hosted or GPU-backed model.
I could shape it for one person's problem. The two study modes, the structured output, and the quiz exist because I could control the prompts and the whole pipeline.

With a closed API, every explanation would be a paid request, and the app would need an account, a key, and a connection. For a study tool built for a friend, that's the wrong fit.

The tradeoff is setup: you need Ollama and the model installed, and local inference is slower than a hosted API. I think that's worth it for a tool someone will use every day.

Honest limitations

Sanskrit Saathi is a language-learning tool. It is not a substitute for a Sanskrit teacher, a textbook, or a qualified medical professional.
A 4B model can make mistakes, especially with rare words and complex grammar. Ayurvedic context in BAMS mode should be checked against textbooks and teachers.
It needs Ollama running locally, and responses are slower on CPU-only machines.

What's Next

This version intentionally stays small. If I continue developing Sanskrit Saathi, I'd like to add study history, more structured shloka practice, and test other open-weight models to see how well they handle Sanskrit.
But for this weekend, the goal was simple: build something my friend could actually use.

Prize Categories

Best Use of Gemma: Gemma 3 4B runs locally through Ollama and powers the explanations and quizzes in Sanskrit Saathi, adapting them to both General and BAMS study modes.

Thanks for reading! 🪷 If you're learning Sanskrit, studying BAMS, or building tools for a friend, I'd love to hear your thoughts in the comments.