DEV Community: Rishi raj Goel

Ghost in the Document: Hunting the Hidden Traces in Your Files

Rishi raj Goel — Wed, 28 Oct 2026 07:10:03 +0000

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

What I Built

I built Ghost in the Document, a local-first document privacy tool that helps identify sensitive information and hidden content in documents before they are shared.

The idea came from a simple concern: a document can reveal more than what is visible on the page. It may contain personal information, author metadata, comments, tracked changes, or other traces that are easy to overlook.

I wanted to build something that could help people find these details without having to upload their documents to an online service.

Ghost in the Document scans supported PDF, DOCX, and TXT files, identifies potential sensitive information, and lets users review the findings before choosing what to redact. It also performs checks on the resulting document to help verify the changes.

For this challenge, I interpreted "Ghost in the Machine" as the hidden traces that remain inside our digital files. The goal was to make those traces easier to find before they become a privacy problem.

Demo

Here is a walkthrough of Ghost in the Document, showing the application and its document scanning and redaction workflow.

Watch the demo on YouTube

Code

GitHub Repository: Github Repository

The project is written in Python and is designed to run locally on the user's machine.

How I Built It

I built the application in Python, using Gradio for the interface and a combination of rule-based detection, open-source AI, and local language models.

The detection workflow has multiple layers.

First, regular expressions and predefined rules identify structured information such as email addresses and phone numbers. This provides a fast way to detect information that follows recognizable patterns.

Next, I used GLiNER for named entity recognition. This helps identify information such as people, organizations, and locations that may not follow a predictable format.

I also integrated Ollama to support analysis using a locally running language model. This layer can help identify context-dependent sensitive information that simpler rules might miss. The application checks that proposed findings actually occur in the source text instead of blindly accepting model output.

Beyond visible text, the application checks supported document structures for selected hidden content, including metadata, comments, tracked changes, and hidden text.

Once the scan is complete, users can review the findings and select the information they want to redact. The application creates a redacted copy and runs post-save checks on the result.

One of the main challenges was bringing these different components together into a workflow that is practical to use. Detecting a possible privacy issue is only one part of the problem. The user also needs control over what gets removed, and the application needs to check the resulting file.

The current version supports text-based PDFs, DOCX, and TXT files. Scanned PDFs and image-based documents requiring OCR are not supported.

Why Does Open Innovation Matter?

For a project focused on document privacy, sending the document to an external service for analysis would defeat part of the purpose.

Open-source tools and locally runnable models made it possible to build a workflow where documents can be processed on the user's own machine. This also means the application does not need to depend on a paid hosted AI API for its core local workflow.

Another advantage is flexibility. Different detection methods can be combined, tested, and improved independently. Developers can experiment with different open models and adapt the system to their needs instead of being tied to a single closed service.

Open innovation makes it easier to explore these ideas, understand how the components work, and build tools that give users more control over their data.

Local processing is not a guarantee of perfect security, and AI models can still miss sensitive information or produce incorrect findings. That is why the project includes a review step and post-redaction checks, while acknowledging that the verification process has limitations.

The Spirit of It

The interesting thing about documents is that they can preserve traces of their past. A comment may remain after a discussion has ended. Personal information may appear in a place nobody thinks to check. A change that seems to have disappeared may leave something behind.

That idea became the foundation of Ghost in the Document.

I wanted the project to feel connected to the theme while solving a practical problem. Instead of treating the ghosts as fictional creatures, I treated them as the hidden remnants of information that we leave behind when working with digital files.

Building this also reminded me that privacy is not just about detecting sensitive data. It is about giving people a way to review it, make informed decisions, and check the results before sharing their work.

There is still room to improve the detection coverage and verification process, but this project is a step toward making those hidden traces easier to understand and manage.

Other Team member : @gaurikasethi88

Recipe De-Blogger: Less Scrolling, More Cooking with Local AI

Rishi raj Goel — Thu, 22 Oct 2026 19:11:06 +0000

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

What I Built

Recipe De-Blogger is a lightweight web app designed to help home cooks get straight to the useful part of an online recipe—without scrolling through lengthy personal stories, advertisements, and unnecessary page content.

Simply paste a recipe URL, and the app extracts the essential details into a clean, easy-to-follow format, including the recipe title, ingredients, and cooking instructions. It also supports ingredient scaling for different serving sizes when the original serving count is available.

The idea is simple: less scrolling, more cooking.

Recipe De-Blogger is especially useful for people who regularly cook from online recipes and want quick access to practical instructions while preparing their meals.

Demo

Watch the Demo Video

Code

View the GitHub Repository

The project uses a Python/FastAPI backend and a lightweight HTML, CSS, and JavaScript frontend. It extracts structured recipe data from web pages and uses a locally running language model for AI-assisted extraction when standard methods are insufficient.

How I Built It

I built Recipe De-Blogger using a small, practical technology stack:

Python and FastAPI: Power the backend and its API endpoints.
HTML, CSS, and JavaScript: Provide a simple, responsive frontend for interacting with the app.
Recipe-page extraction: Prioritizes structured data, such as Schema.org recipe markup, before falling back to other extraction methods.
Ollama: Runs an open-weight language model locally to support AI-assisted recipe extraction, including extraction from available YouTube transcripts.
Recipe scaling logic: Adjusts ingredient quantities for a target serving size when the original serving count is known.

My focus was to keep the experience straightforward: enter a URL, extract the essential recipe details, and adjust the serving size when needed.

Since extraction quality can vary across websites and transcripts, the results should still be reviewed before cooking.

Why Does Open Innovation Matter?

Open innovation allowed me to experiment with AI-assisted extraction without relying on a paid, closed AI API for every recipe request. By running an open-weight model locally through Ollama, I gained greater control over the development process and an opportunity to understand how language models handle real-world, unstructured content.

This approach also keeps the architecture accessible and adaptable. By combining standard web technologies with a locally running model, the extraction workflow can be inspected, tested, and improved as the project evolves.

For a small open-source project, that flexibility is valuable. It allows me to experiment with prompts, refine parsing logic, and improve validation without making the entire application dependent on a single proprietary AI provider.

The Lazy Payoff

The real payoff is reducing the friction between finding a recipe and getting started in the kitchen.

Instead of repeatedly scrolling past lengthy introductions, advertisements, and other page content, users can access the essential recipe details in one organized view. They can then focus on the ingredients, follow the instructions, and adjust quantities when they need to cook for a different number of people.

I haven't made any measured time-saving claims because I haven't conducted a formal timing test. The intended benefit is simple: copy a recipe link, get the important details, and focus on cooking.

Other Team Members

Gaurika Sethi — @gaurikasethi88

Khata: Turning Paper Bills into Useful Business Records

Rishi raj Goel — Mon, 19 Oct 2026 06:21:17 +0000

Submission: Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle

Challenge: https://dev.to/challenges/hacktoberfest-week2-2026-10-12

What I Built

Small shops often handle bills and purchase records on paper. Entering those details into a ledger takes time, and handwritten or printed bills can be difficult to process consistently.

I built Khata, a local bill-to-ledger prototype for small shops in India. It uses AI to extract information from bill images and helps turn that information into structured records.

The current prototype includes:

Bill image preprocessing using OpenCV.
Local vision-based extraction using Ollama and Gemma 3 4B.
Structured extraction output and validation checks.
A Streamlit interface for reviewing and correcting extracted details.
A local SQLite ledger for saved bills and line items.
Monthly summaries and an experimental product-demand forecasting feature.

The goal is to reduce repetitive data entry while keeping the shopkeeper in control of the final record.

Demo

Video demo: Watch Khata Demo

In an initial test, one shopkeeper processed 10 bills:

Manual process: 60 minutes
Using Khata, including corrections: 40 minutes
Time saved: 20 minutes (about 33%)

This is an early, small-scale test rather than a broad performance study.

Code

GitHub repository: See the github repository here

How I Built It

Khata is built around a local-first workflow:

A user uploads a bill image.
OpenCV preprocessing improves the image for extraction.
Ollama runs the Gemma 3 4B vision model locally to extract bill details.
Pydantic-backed structure and validation checks help identify missing or inconsistent values.
The user reviews and corrects the extracted information in the Streamlit interface.
Confirmed records can be saved to a local SQLite database.
The project includes scripts to build product-demand data and generate experimental restocking forecasts using TabPFN where there is enough historical data.

The main tools are Python, Streamlit, OpenCV, Ollama, Gemma 3 4B, Pydantic, SQLite, pandas, and TabPFN.

I also evaluated extraction against a small set of 20 bills. The current results were:

Total accuracy: 19/20 (95%)
Item-count accuracy: 17/20 (85%)
Date accuracy: 7/9 (77.8%), calculated only for the nine bills with usable ground-truth dates.

These numbers describe this small test set and should not be treated as a guarantee of real-world accuracy. The prototype still needs testing on more shops, bill formats, and dates.

Why Does Open Innovation Matter?

Small businesses should be able to experiment with useful technology without being locked into a single cloud service. Using an open-weight model locally gives developers more control over the workflow and makes it possible to inspect, adapt, and improve the system.

Local inference can also reduce dependence on per-request API services, although the actual cost and privacy benefits depend on the hardware and deployment setup. Khata is an experiment in making practical AI tools more accessible while keeping the data workflow understandable and under the user's control.

My First User

I tested Khata with one shopkeeper using 10 bills. The manual workflow took about 60 minutes, while using Khata—including corrections—took about 40 minutes. That is a saving of 20 minutes, or roughly 33%, in this initial test.

The shopkeeper was maybe willing to pay, depending on the features, speed, and reliability. Their expected price was around ₹400–₹500 per month if the tool becomes faster and consistently saves time.

They also suggested two useful additions:

Tracking products or amounts given and taken on credit.
End-of-day restocking alerts that account for sales and a delivery lead time of around 3–4 days.

They mentioned Tally as an existing option, so accuracy and a clear advantage over current bookkeeping tools will matter if Khata is to be useful in real shops. This feedback is from one early user, so it is a starting point—not proof of product-market fit.

What I Learned

Building Khata made one thing clear: extracting data is only one part of the problem. The output has to be easy to verify, errors need to be visible, and the resulting records must be useful for everyday decisions.

The project is still a prototype. Its current limitations include inconsistent extraction on some bills, a small evaluation dataset, and limited historical data for demand forecasting. The next step is to improve reliability and test the workflow with more real bills and shopkeepers.

What would make a tool like this genuinely useful for a small shop- credit tracking, faster bill entry, restocking alerts, or something else?

Other Team Members

Gaurika Sethi @gaurikasethi88