DEV Community: BARI ANKIT VINOD

Satbara Saathi: Understand Your 7/12 Land Record in Marathi, Without the Talathi Trip

BARI ANKIT VINOD — Mon, 26 Oct 2026 07:09:28 +0000

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

What I Built

Satbara Saathi (सातबारा साथी) explains a Maharashtra 7/12 (Satbara) land extract in plain Marathi, Hindi or English.

A 7/12 is dense, jargon-heavy and often scanned badly. Anyone buying or inheriting farmland ends up waiting at the talathi office or paying a middleman to read it to them. The lazy way is to upload a photo and get the answer back:

Preprocess the image and check its quality
OCR it and extract structured fields
Run 11 deterministic red-flag rules (loan/boja, multiple owners, minor owner, tenant, Class 2 land, inheritance mutation, area mismatch, and more)
Have an LLM explain the findings in simple language
Read the summary aloud (TTS)

The most important design decision is what the AI does not do. The rules engine contains no AI. The LLM only explains flags it is handed, and it is told never to call land "safe" or "valid". The tool gives no legal advice and says so.

Demo

Code

aijadugar / satbara-saathi

Satbara Saathi (सातबारा साथी)

Understand Maharashtra 7/12 (Satbara) extracts in plain Marathi / Hindi / English.

What it does

Reads a 7/12 image (scanned or digital)
Extracts structured data via OCR
Runs deterministic red-flag rules (no AI in the rules engine)
Explains findings in plain language via LLM
Speaks the summary aloud (TTS)

What it does NOT do

Give legal advice
Decide if land is "safe"
Store your images or personal data
Process 8A, mutation extracts, or other states (yet)

Quick start

cp .env.example .env
pip install -e ".[dev]"
make dev        # http://localhost:8000
make test       # run tests with fake providers

Architecture

Upload → Preprocess → OCR → Extract → Validate → Rules → Explain → TTS
                                         ↕
                                   Confirm fields

Privacy

Images deleted after processing
No PII in logs
Anonymous impact counters only
Consent gate before upload

License

Apache-2.0

View on GitHub

How I Built It

Backend: FastAPI + Pydantic. Providers sit behind small interfaces (OCR, LLM, TTS), so each can be swapped by config.
Rules: app/rules/mh_7_12.yaml, with bilingual (Marathi/English) titles, explanations and "what to do next" steps per rule. They are plain data, so a revenue-law professional can review them without reading Python.
LLM: the explain layer targets Sarvam-M, an open-weight 24B model (post-trained on Mistral Small 3.1) with Marathi and Hindi support. A post-check rejects explanations containing names or long numbers that aren't in the source document, and retries once before failing.
Privacy: consent gate before upload, jobs held in memory only, and the only thing persisted is an anonymous counter DB (no names, no survey numbers, no images).
Tests: 16 tests pass using fake providers, with CI on GitHub Actions.

Honest status: this is a one-week build. The Sarvam and OCR adapters are written, but the running server currently uses fake providers, and structured extraction from real OCR output is not finished. The rules engine, validation, explanation safeguards, consent flow and UI work end to end on sample data. The rules have not yet been reviewed by a Maharashtra revenue-law professional, which is the first thing needed before any real use.

Why Does Open Innovation Matter?

A land record contains names, family relationships and where someone's livelihood sits. That is exactly the data you don't want flowing through a black box.

Self-hostable explanations. Because Sarvam-M has open weights, a gram panchayat, CSC centre or NGO could run the explain step on its own server with vllm serve and keep documents off third-party systems. A closed API would not allow that.
Auditable rules. The red-flag logic is open YAML, not model behaviour, so lawyers and community members can read, challenge and correct it.
Built for the language. A model post-trained on Indic languages is what makes Marathi output realistic. Apache-2.0 means anyone can adapt this for other states.

The OCR and TTS adapters currently call hosted APIs. Replacing them with open models is the clearest next step.

Social Hustle: a done-for-you social media engine that runs entirely on open-source AI

BARI ANKIT VINOD — Mon, 19 Oct 2026 03:29:33 +0000

What I Built

Social Hustle generates a week's worth of on-brand social posts for small-business clients — research, angle-picking, drafting, and publishing — as a single durable Temporal workflow. You give it a client profile (voice, audience, keywords to avoid) and it comes back with drafts you approve before anything goes out. Nothing publishes without a human saying yes.

It's built for the operator, not the client: one CLI command starts a run, the Temporal UI shows each activity light up, and a small FastAPI dashboard lets you review and tick the drafts you want published. Posting goes to Bluesky; without creds it dry-runs to a per-client outbox.jsonl so you can demo it with zero setup.

Who pays: agencies and freelancers managing social for several small clients. Instead of a weekly hour of "what should we post today," they get drafts in their clients' actual voice, with the human approval still in the loop.

Demo

No deployed link yet — it runs locally. To demo:

ollama serve
temporal server start-dev
python social_hustle.py worker
python social_hustle.py run clients/brew-lane/brand.json   # -> prints a workflow id
python social_hustle.py show <workflow_id>                # review drafts
python social_hustle.py approve <workflow_id> 0 2          # publish #0 and #2

Or start the dashboard instead of the CLI: python web.py → http://localhost:8000.

Code

https://github.com/aijadugar/social-hustle

How I Built It

The whole LLM layer runs on Gemma 3 via Ollama — an open-weight model, local inference, $0 per post, and client data never leaves the machine. Every LLM call uses Ollama's structured-output mode (JSON schema), and the response is validated and repaired before it's used: Gemma occasionally truncates mid-string, so a single O(n) scan closes unterminated strings and open containers rather than failing the run.

Orchestration is Temporal (Python SDK). One durable ContentRun workflow per client per day: research (Google News RSS) → learn (what performed last week) → write (Gemma picks angles and writes the posts in one call) → a durable human-approval signal → publish (Bluesky, idempotent). Temporal means retries, time-skipping approval windows, and no lost state if you approve tomorrow.

Stack is deliberately tiny — stdlib + temporalio + fastapi/uvicorn, one static HTML file, no build step, no JS framework. Per-client data lives in clients/<slug>/ and is never mixed between clients.

Why Does Open Innovation Matter?

This project only works because the AI is open. Three things a closed API couldn't give it:

Data locality. Client brand voices, drafts, and posting history are sensitive business data. Running Gemma locally means nothing ever ships to a vendor — a real requirement for an agency handling multiple clients' accounts.
Zero marginal cost. At $0 per post, the economics work for small-business clients who can't afford $20/month AI subscriptions. An API bill scales with output; open inference doesn't.
You can actually inspect and fix it. When Gemma 3 truncated its output mid-string and killed the activity with JSONDecodeError, I could read the model's raw response, write a repair pass, and tune the retry/backoff — rather than file a support ticket against a black box. The failure modes are observable and fixable, which is what makes this a product and not a demo.

My Agent Session

My First User

Prize Categories

Open-Source AI — the entire LLM layer is open-weight Gemma 3 via Ollama
Side Hustle — it's literally a done-for-you side hustle for social media

`/export` slash command to [OpenHack]

BARI ANKIT VINOD — Mon, 12 Oct 2026 10:22:15 +0000

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

What I Built

I added a /export slash command to OpenHack, an open-source AI security scanner that runs in your terminal.

Before this, OpenHack could only copy one finding at a time (/copy), and the only report was a raw session JSON file. So the results lived inside the terminal, and the person who ran the scan had to stay there to use them.

/export [sarif|md|json] [path] writes every finding to a file you can take with you:

SARIF 2.1.0 (default) for GitHub code scanning, GitLab, Azure DevOps and VS Code. Findings are tagged with CWE IDs and severity, and paths are relative to the scanned repo.
Markdown for a readable report you can paste into a PR, ticket or audit.
JSON for a full findings dump.

How it gets people off the screen: a deep AI scan takes a while, and you shouldn't have to sit and watch it. Start it, step away, and come back to a finished report you can review on your phone, send to a teammate, or have CI pick up automatically. Exports are safe to share: token-like strings are redacted and exploit payloads are left out of SARIF and Markdown.

Who it's for: developers and small teams running OpenHack on their own code who want results in their existing workflow, not stuck in a terminal session.

Code

https://github.com/aijadugar/OpenHack

Main changes:

openhack/export.py: new, UI-free module with the SARIF/Markdown/JSON builders and an atomic file writer
openhack/tui.py: thin /export handler plus command-table and tip entries
tests/test_export.py: 31 new tests (the full suite is 542 passing)
README.md: command table row and a short "Exporting findings" section

How I Built It

OpenHack is a Python TUI (prompt-toolkit and rich) that runs a multi-agent scan pipeline against your codebase and works with several LLM providers. /export doesn't call a model. It's a deterministic transform over the findings the agents already produced.

Design choices worth mentioning:

Pure module, thin command. All the logic is in export.py with no TUI imports, so it's unit-tested directly. The TUI handler is about 40 lines.
Follows the repo's CLI contract. AGENTS.md says new functionality belongs inside the interactive agent, not as a new subcommand, so this is a slash command and not openhack export.
Built for sharing. It reuses the project's existing redact() helper, omits PoCs from shared formats, writes atomically (temp file and rename), and creates owner-only files.
Correct for real consumers. GitHub rejects line 0, so unknown lines default to 1. OpenHack's built-in fingerprint is category plus file only, which would merge distinct findings in one file, so the export hashes in the title too.

Why Does Open Innovation Matter?

Security tooling is a place where trust matters, and open source makes that trust checkable. With OpenHack you can read exactly what the scanner does, and I could add a feature to it without asking anyone's permission or waiting on a vendor roadmap.

The feature itself is also about openness: SARIF is an open standard, so findings aren't locked into one tool's UI. Exporting to a standard format means the same results work in GitHub, GitLab, VS Code or whatever you use next. A closed scanner tends to give you its own dashboard, but here I could make the output portable.

Spotter: a private workout form coach I built for a friend who trains at home

BARI ANKIT VINOD — Mon, 05 Oct 2026 06:46:55 +0000

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

What I Built

Spotter is a workout form coach for my friend, who trains at home. There's no gym nearby and no budget for a private trainer, so a phone propped on a shelf is the only feedback they get. Every "AI coach" app they tried either wanted a subscription, sent their workout videos to a company's servers, or repeated generic YouTube advice.

So I built something different. They upload a short clip, add a little training context, and get back:

the detected exercise and a confidence score
a rep-by-rep analysis
valid variations separated from real form issues
an annotated video plus short clips of each issue
a grounded coach summary with fixes and a next-session plan

It currently supports squats, push-ups and shoulder presses. It also says "I can't tell" on purpose: if a clip isn't one of those movements, Spotter rejects it instead of forcing a guess. It is a practice companion, not a medical device. It doesn't diagnose injuries or claim to prevent them.

My friend said, "I have good shoulder strength but it helps me in squats".

Demo

Video link - https://youtu.be/DImVwhrrkFA

Code

aijadugar / spotter

title

Spotter

emoji

🏋️

colorFrom

green

colorTo

blue

sdk

gradio

sdk_version

6.17.3

python_version

3.10

app_file

app.py

fullWidth

true

short_description

Workout form coach for a friend, built on open-weight small models.

Spotter

Spotter is a small-model workout form coach I built for a friend.

My friend trains at home: no gym nearby, no budget for a private trainer, and a phone propped on a shelf is the only feedback they get. Every "AI coach" app they tried wanted a subscription, shipped their workout videos to a company's servers, or paraphrased generic YouTube advice. So I built Spotter for them instead.

A user uploads a short exercise video, adds basic training context, and gets a structured form-review report with rep counts, movement notes, annotated video, and a grounded coach summary — produced by open-weight models that cost nothing to run and never…

View on GitHub

How I Built It

Spotter is a pipeline of small, checkable steps rather than one big chatbot:

video + profile
  -> video quality check
  -> pose extraction (MediaPipe Pose Landmarker Lite)
  -> pose cleaning
  -> exercise router (custom PyTorch BiLSTM, 182,796 parameters)
  -> exercise-specific rep counter
  -> per-rep analysis -> variation detection -> issue markers
  -> annotated video + issue clips
  -> coach summary (Nemotron-3-Nano-4B + LoRA)
  -> verifier

The models. The router is a tiny BiLSTM over 30-frame windows of pose landmarks. The coach summary comes from nvidia/NVIDIA-Nemotron-3-Nano-4B-BF16, fine-tuned with a LoRA on task-specific data. Training and publishing run as Modal jobs. For fully local use, the summary can run through llama.cpp with a GGUF build, so MediaPipe, the router and the coach summary all run on a laptop.

Evidence first, language second. The numbers (reps, depth, issue counts) come from deterministic code. The language model only phrases them. A verifier then checks the summary against that evidence and blocks claims it can't ground or that sound like a diagnosis. I'd rather the coach say less than say something it can't back up.

Optional extras, all opt-in. Spotter's core promise is that it runs locally with no account, so anything cloud-based is off by default and falls back quietly:

Voice coach (ElevenLabs). Short spoken cues for the top issues, like "rep 3: knees drifted inward". It only speaks text that already passed the verifier, caches audio on disk so repeat runs cost nothing, and enforces a per-run character budget. Only text is sent, never video.
Cross-session memory (Backboard). A "vs last session" comparison, so my friend can see whether a fault is fading. SQLite stays the source of truth. Only derived metrics (date, exercise, rep count, issue counts) are synced, never video, frames or landmarks.
Fine-tuning pipeline (Tinker). A LoRA fine-tune of a small Qwen model for the progress-plan step, with a dry-run mode that prints token counts and cost before spending anything.
Deployment (Render). A Render Blueprint with a health check and a persistent disk for history. Live require credit card (I don't have).

I built this with Claude Code in a long session of small, verified steps.

Why Does Open Innovation Matter?

Three things my friend cares about would have been impossible, or paid for, with a closed API:

Their workout videos stay on their machine. Videos of someone training at home, often in their living room, are personal. With open weights and local inference, there is no server that has to see them.
It costs nothing to run and needs no account. There is no subscription and no per-request bill. That matters when the whole point is that a trainer is too expensive.
I can change it for them. The coach's voice and focus come from a LoRA I trained, so when a better 4B model appears or my friend wants a different style, I retrain the adapter instead of waiting for a vendor. The small router and the verifier mean every claim can be inspected, not just trusted.

GuWiki: Building a Gujarati AI Wikipedia from Scratch 🇮🇳

BARI ANKIT VINOD — Fri, 05 Jun 2026 16:31:04 +0000

What I Built

GuWiki is an AI-powered Wikipedia-style platform built specifically for the Gujarati language.

Gujarati is spoken by more than 60 million people worldwide, yet high-quality AI tools, language models, and speech technologies for Gujarati remain limited compared to English and other major languages.

I wanted to help close that gap.

Instead of relying on existing foundation models, I built the core AI components from scratch:

A Gujarati Large Language Model (LLM)
A Gujarati Automatic Speech Recognition (ASR) model
A complete data engineering pipeline
A Wikipedia-style knowledge platform powered by these models

Users can search, read, and interact with Gujarati knowledge using AI that understands the language natively.

AI Models

Gujarati NanoGPT (LLM)

https://huggingface.co/aijadugar/gujarati-nanogpt

A language model trained specifically on Gujarati text to understand vocabulary, grammar, and language patterns.

Gujarati ASR Model

https://huggingface.co/aijadugar/gujarati-asr

A speech-to-text model trained for Gujarati audio, enabling voice-based interaction and accessibility.

Demo

Live Application

👉 https://gu-wiki.vercel.app/

Video Walkthrough

🎥 https://www.loom.com/share/b5e278e624724d8f975e95b0fc3c6297

Key Features

AI-powered Gujarati knowledge search
Native Gujarati language understanding
Speech-to-text capabilities
Custom-trained Gujarati LLM
Custom-trained Gujarati ASR
End-to-end data engineering pipeline
Fast and responsive web interface
Open-source repository for community contribution

The Comeback Story

This project started as an ambitious idea:

"Can I build AI infrastructure for Gujarati instead of simply consuming models built for English?"

The answer turned out to be much harder than expected.

The biggest challenge wasn't building the website.

It was the data.

Gujarati lacks the abundance of high-quality datasets available for English. I spent significant time collecting, cleaning, validating, and preparing Gujarati text and speech data before any model training could even begin.

The project went through multiple iterations:

Rebuilding data pipelines
Cleaning noisy datasets
Experimenting with tokenization strategies
Training and retraining language models
Improving speech recognition quality
Optimizing inference performance
Connecting everything into a single user experience

For the Finish-Up-A-Thon, I focused on turning these individual research efforts into a complete, usable product.

I improved:

Model integration
Frontend experience
Deployment workflows
Documentation
Performance optimizations
Repository structure
End-to-end user experience

The result is GuWiki: a fully working AI-powered knowledge platform designed around Gujarati language users.

My Experience with GitHub Copilot

GitHub Copilot played a significant role throughout development.

While building GuWiki, I worked across multiple domains:

Data engineering
Machine learning
Deep learning
Model training
API development
Frontend development
Deployment

Switching contexts constantly can slow development, and Copilot helped reduce that friction.

Some of the ways it helped include:

Generating boilerplate code
Accelerating API development
Creating data processing utilities
Writing training scripts faster
Refactoring repetitive code
Generating documentation
Suggesting fixes during debugging

What I appreciated most was that Copilot allowed me to stay focused on solving the actual AI and language challenges instead of spending time on repetitive implementation details.

It felt less like autocomplete and more like a development companion that helped maintain momentum throughout the project.

Why This Project Matters

Most AI innovation today happens in a small number of major languages.

Millions of people speak Gujarati every day, but the ecosystem of open-source AI tools for the language is still developing.

GuWiki is my contribution toward making AI more accessible for Gujarati speakers by building:

Open-source language models
Open-source speech models
Public datasets and pipelines
Real-world applications powered by those models

My goal is not only to build a product but to help strengthen the Gujarati AI ecosystem so future developers and researchers can build on top of it.

If even a small part of this work helps expand access to knowledge and AI for Gujarati speakers, then the project has already succeeded.

Repository & Resources

GitHub: https://github.com/aijadugar/GuWiki
Live App: https://gu-wiki.vercel.app/
Demo: https://www.loom.com/share/b5e278e624724d8f975e95b0fc3c6297
Gujarati LLM: https://huggingface.co/aijadugar/gujarati-nanogpt
Gujarati ASR: https://huggingface.co/aijadugar/gujarati-asr

⭐ If you find the project interesting, feel free to explore the repository and share feedback.