DEV Community: rishabh-hasija

SpecterLAN: Find the Ghosts on Your Network

rishabh-hasija — Sat, 31 Oct 2026 11:23:40 +0000

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

What I Built

I built SpecterLAN, a local-first network monitor that helps you understand which devices are connected to your network and what changed between scans.

SpecterLAN can show:

New devices
Devices that went offline
Devices that returned
IP address changes
Devices that still need review

For the Ghost in the Machine theme, unfamiliar or forgotten devices become the "ghosts" on your network.

SpecterLAN does not assume an unknown device is dangerous. It shows what changed and lets you identify the device yourself.

It also includes Ask the Ghost, where a local AI model explains network changes using evidence collected by SpecterLAN.

Everything runs locally on your device.

Demo

Watch the SpecterLAN demo

The demo shows:

A baseline network scan
A new device appearing
SpecterLAN detecting the change
Ask the Ghost explaining the change with local AI
A device changing IP while keeping the same identity
Another device going offline

SpecterLAN also includes Demo Séance, which uses simulated network data so people can test the full experience without exposing their real network.

Code

GitHub repository:

https://github.com/rishabh-hasija/spectarlan

SpecterLAN is open source and released under the MIT License.

How I Built It

SpecterLAN is built with:

Python
Streamlit
SQLite
Ollama
Gemma 3 4B as the default local AI model
Pydantic
Nmap when available, with a local fallback when it is not

Network scanning happens on the user's own device.

Scan history, device names, trust labels, and other information are stored locally in SQLite.

For AI analysis, SpecterLAN sends structured evidence only to the locally running Ollama service.

The default model is gemma3:4b.

SpecterLAN also detects other compatible Ollama models already installed on the device and lets the user select one from a dropdown.

Ask the Ghost does not decide whether a device is malicious.

Instead, SpecterLAN creates evidence records, checks the evidence referenced by the model, and removes unsupported AI output.

Why Does Open Innovation Matter?

Network information is private.

A network scan can contain device names, local addresses, hardware details, and information about devices inside someone's home.

I did not want SpecterLAN to send that information to an external AI API.

Using Ollama and an open-weight model means the AI runs on the same device as SpecterLAN.

There is:

No cloud AI
No API key
No SpecterLAN account
No registration
No shared database
No network history uploaded to a SpecterLAN server

Users can also switch to another compatible local Ollama model.

Even without AI, device discovery, tracking, and scan history continue to work.

This open and local approach keeps the user's network data under their control.

The Spirit of It

Devices appear, disappear, return, and sometimes change addresses.

SpecterLAN treats those changes like apparitions on your network.

A forgotten device might suddenly appear again. A new device might show up without a recognizable name. Ask the Ghost helps explain what SpecterLAN observed.

The Halloween theme is part of the experience, while the findings remain evidence-based.

Unknown does not mean malicious.

Prize Categories

Best Use of Gemma

SpecterLAN uses Gemma 3 4B through Ollama as its default local AI model.

Gemma powers Ask the Ghost, which explains changes between saved network scans using structured local evidence.

The model runs on the user's own device, so private network information does not need to be sent to a hosted AI provider.

LazyResearch OS: The AI That Reads What I’m Too Lazy to Read

rishabh-hasija — Mon, 26 Oct 2026 02:23:30 +0000

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

LazyResearch OS — Save the reading. Find what matters. Keep the evidence.

What I Built

I built LazyResearch OS, a tool for people who keep saving things they intend to read later — PDFs, articles, notes, quotes, meeting notes, emails copied as text — and then never get around to organizing or acting on them.

The basic idea is:

Give LazyResearch the things you were too lazy to read, organize, or research. It finds what matters, keeps the evidence, and tells you what may actually need your attention.

A user can:

Add URLs, PDFs, TXT/Markdown files, or pasted text.
Let an open-weight Gemma model analyze each source.
Open What Matters to see which saved items deserve attention.
Give simple feedback so LazyResearch can learn their preferences over time.
Ask a research question across a specific collection of saved material.
Get a cited research brief showing exactly which saved sources support the answer.
Review source-backed actions such as deadlines, follow-ups, or things that need verification.
Accept, edit, complete, dismiss, or reopen those actions.

A real example from my testing

I added a short meeting note comparing three project-management tools:

Tool A costs €12/user/month and includes time tracking.
Tool B costs €9/user/month but does not include time tracking.
Tool C costs €15/user/month and includes automation.
The team has to decide before 15 November 2026.
Before choosing, Tool B's SSO support and Tool C's data-export capability need to be confirmed.

LazyResearch automatically:

summarized the note,
detected the decision deadline,
classified it under Action required,
proposed:
- Confirm Tool B SSO support
- Confirm Tool C data export capability
let me ask: > “What should we verify before choosing office software?”
created a research brief using only the selected Office software collection,
cited the original note as evidence,
disclosed that the answer had partial coverage because only one personal source was available,
and preserved the action provenance all the way back to the original text.

The point is not just summarization. The goal is to turn saved information into priorities, evidence-backed research, and things worth doing.

Demo video

https://drive.google.com/file/d/1SagYAnFA1xU-WO0xATvf1m8Ft8txGRIJ/view?usp=drive_link

Live demo

https://lazyresearch-os-demo.onrender.com/

The public deployment is intentionally a synthetic shared demo workspace.

Please do not upload personal or private information. The current challenge demo has no authentication and stores demo data persistently in PostgreSQL rather than temporary browser storage.

Some research/analysis features depend on a separately supervised worker and local model host, so they may not be continuously available.

Demo flow

For the final video I will demonstrate:

Add a new source.
Put it in a collection.
Analyze it with Gemma.
See it appear under What Matters.
Give explicit relevance feedback.
Start a research mission limited to that collection.
Inspect the generated brief.
Open the exact evidence used by the answer.
Review the generated source-backed actions.
Accept one of those actions.

Code

GitHub:

https://github.com/rishabh-hasija/lazyresearch-os

The project is released under the MIT License.

How I Built It

LazyResearch OS is a Python modular monolith backed by PostgreSQL.

The architecture deliberately keeps original sources, AI-generated analysis, evidence, research history, user feedback, and actions separate instead of treating an AI response as disposable chat output.

The simple version

The flow looks like this:

You provide

URLs
PDFs
TXT / Markdown files
pasted notes or email text

↓

LazyResearch

saves the original material,
extracts readable content,
analyzes it,
learns what you care about,
searches your saved material,
performs longer research jobs,
keeps evidence attached to generated claims.

↓

You receive

a What Matters priority view,
cited research briefs,
preserved research history,
coverage limitations,
source-backed actions.

What happens technically

Step	What the user sees	What happens behind the scenes
Add Sources	Upload or paste material	Original source and extracted content are stored in PostgreSQL
Analyze	Summary, topics, deadlines, actions	Gemma analyzes bounded source content through Ollama
What Matters	Read now / Useful later / Action required / Low priority	Deterministic baseline first, then TabPFN personalization only after enough explicit feedback and evaluation
Search saved material	Relevant evidence	PostgreSQL lexical retrieval plus pgvector semantic retrieval
Research	Cited brief	Temporal coordinates a durable research workflow
Evidence	Exact source text and provenance	Frozen evidence remains tied to the immutable research result
Actions	Things worth doing	Source-backed proposals keep their provenance, deadline and revision history

Gemma

I use Gemma locally through Ollama for source analysis and research synthesis.

It extracts:

summaries,
topics,
claims,
uncertainty,
candidate deadlines,
source-backed actions,

and later synthesizes structured research briefs from selected evidence.

The project does not assume that model output is automatically trustworthy. Citations are validated against the evidence selected for the mission, and partial coverage is disclosed instead of pretending the system knows more than it does.

Embeddings and pgvector

Saved source text is split into deterministic chunks.

I use qwen3-embedding to create semantic embeddings, which are stored with pgvector in PostgreSQL.

LazyResearch combines:

PostgreSQL full-text search for lexical/exact retrieval, and
semantic/vector retrieval for meaning-based matching.

A deterministic Reciprocal Rank Fusion step combines the two.

Lexical retrieval remains available as a fallback.

Temporal

Long research jobs run through Temporal.

A Research Mission is not just a large function call. It moves through durable stages such as:

personal-source retrieval,
evidence selection,
evidence freezing,
synthesis,
citation validation,
result publication.

During the challenge I explicitly tested worker restart and recovery. An in-flight mission survived worker interruption without producing a duplicate publication.

Research results are immutable: rerunning a topic creates another version instead of overwriting the previous answer.

TabPFN

TabPFN powers the personalized relevance path behind What Matters.

The important part is the cold start.

LazyResearch does not claim to know the user immediately.

At first it shows:

Learning your preferences

The baseline ranking uses transparent signals such as recency, deadlines and source-backed actions.

Users then give explicit feedback such as:

Read now
Useful later
Action required
Low priority

Only after enough labeled examples exist, and only if the personalized model passes the evaluation gate against the baseline, can the UI honestly switch to:

Personalized for you

My synthetic held-out benchmark produced:

TabPFN macro-F1: 1.000
baseline macro-F1: 0.544

That proves the integration works on the benchmark, not that real-user ranking quality has already been solved. Real-user personalization remains something to validate further.

Render

The public Streamlit demo runs on Render using a Docker web service.

The hosted application connects to the database through the provider-neutral DATABASE_URL configuration.

Render hosts the public web interface, while the supervised research worker and local inference stay separate for this challenge demo.

PostgreSQL / Neon

Neon PostgreSQL is the canonical durable store for the hosted demo.

It holds things such as:

source captures,
extracted content,
analyses,
chunks,
vector embeddings,
collections,
feedback,
research topics,
missions,
immutable research results,
citations/evidence,
actions and revisions.

The original source and AI-generated analysis are kept separately.

This also means the public demo is not temporary browser storage. Because the challenge demo is one shared workspace without authentication, it is explicitly restricted to synthetic/demo material.

Public web search

LazyResearch also contains a provider abstraction and implementation for public-web research through SerpApi.

However, I did not use a live SerpApi key in the final hosted verification, so I am not claiming live SerpApi use in this submission.

The saved-source research path is the one demonstrated and verified end-to-end.

Why Does Open Innovation Matter?

Open innovation is central to this project rather than an add-on.

The part of LazyResearch that actually reads and synthesizes a user's material runs through an open-weight model that I control.

That gave me several useful properties during development.

I could run inference locally

Gemma and the embedding model run through Ollama on my own machine.

I did not have to design the application around one proprietary model API before I even knew whether the product idea worked.

Models are replaceable

The domain and application layers depend on provider-neutral ports rather than a specific model vendor.

Gemma is the current implementation, but the architecture does not require rebuilding the product around a different API if the inference model changes.

I could inspect and constrain the pipeline

The system separates:

original source,
extraction,
model analysis,
evidence,
research synthesis,
user decisions.

That made it possible to test failures honestly.

For example, during my own end-to-end walkthrough, a research mission failed because strict lexical retrieval returned zero evidence. Instead of weakening the evidence invariant and allowing the model to answer anyway, I fixed the retrieval path so an explicitly selected collection could provide bounded fallback context and the final result was marked Partial coverage.

That behavior is much closer to what I want from personal research software:

When evidence is weak, say so.

Open tools let the pieces cooperate

The project combines:

Gemma for reasoning/synthesis,
Ollama for local inference,
qwen embeddings,
PostgreSQL + pgvector,
Temporal for durable workflows,
TabPFN for personal relevance learning,
Streamlit for the application UI,
Render for public hosting.

Because those pieces can be inspected, replaced and composed, I could build around the product behavior I wanted instead of around the limitations of one closed AI endpoint.

My Agent Session

I used coding agents heavily while building LazyResearch OS.

Rather than keeping one enormous agent conversation, I split development into small roadmap slices such as:

domain foundation,
persistent intake,
Gemma analysis,
retrieval,
Temporal Research Missions,
TabPFN ranking,
Streamlit application,
deployment,
final UX walkthrough fixes.

Each fresh agent session reconstructed the project from repository documentation such as AGENTS.md, STATUS.md, NEXT.md, architecture docs and ADRs.

That turned out to be especially useful during the final manual walkthrough.

Instead of assuming that passing tests meant the product was finished, I used the application myself from scratch and found several real usability and workflow problems:

collection creation failed in a stale Streamlit session,
“Analyze next source” could process refresh jobs before a new source,
feedback saved successfully but its confirmation appeared offscreen,
collection context initially did not carry consistently into Research or Actions,
strict lexical retrieval caused a real Temporal mission to fail with no evidence,
completed partial research existed but could not initially be opened from the UI.

Those issues were found by manually acting like a real user, then giving the agent a minimal reproducible case and requiring it to fix the root cause rather than hide the error.

DevRelay session:

To be added if I export one before submission.

The Lazy Payoff

I built LazyResearch because my own pattern is very simple:

I save things because they seem important.

Then I don't read them.

Or I read them once and forget why I saved them.

Or something in the document requires an action later, and that action disappears into the pile.

LazyResearch tries to remove those steps.

In the Office Software walkthrough, I only entered a short meeting note.

From that one source, the system:

preserved the original,
summarized it,
identified the decision deadline,
surfaced it as requiring action,
proposed two things that need verification,
accepted explicit feedback about its relevance,
researched a question across only that collection,
disclosed that the research had limited coverage,
cited the original note,
and turned one of those proposals into an accepted task.

I am deliberately not claiming a precise “X hours saved” figure yet.

The payoff is simpler:

I should not need to repeatedly reread everything I saved just to rediscover what mattered.

That is the kind of laziness this project is built to reward.

Prize Categories

I am entering the categories the project uses and has verified meaningfully:

Best Use of Gemma

Gemma is the core open-weight model for source analysis and cited research synthesis.

It was exercised through real local inference during both benchmarks and the manual end-to-end walkthrough.

Best Use of TabPFN

TabPFN powers the evaluated personalized relevance path for What Matters.

The product begins with an honest deterministic baseline and only activates personalization after explicit user feedback and evaluation justify it.

Best Use of Temporal

Temporal coordinates durable Research Missions.

The project includes real Temporal Cloud execution, retries, failure handling, worker-restart recovery and immutable publication behavior.

Best Use of Render

The public LazyResearch OS demo is deployed as a Docker-based Streamlit service on Render and uses the live Neon-backed application state.

Current Limitations

This is a challenge build, not a production personal-data service.

Current limitations include:

the public demo uses one shared synthetic workspace,
no authentication,
users must not upload personal/private information,
research/model processing depends on a separately supervised worker,
public SerpApi research is implemented but not live-verified,
Gmail/RSS connectors are not implemented,
TabPFN's benchmark is synthetic and real-user personalization still needs validation,
research can disclose partial coverage when evidence is insufficient,
OCR is not implemented.

I prefer listing those limitations rather than making the demo look more production-ready than it is.

LazyResearch OS started with a very lazy question:

What if I could save something once and never have to remember why it mattered?

The answer turned into a system that preserves the source, finds the evidence, tells me what deserves attention, and still lets me inspect where every important conclusion came from.

StockEntry Guard: Local Gemma-Powered Product Onboarding for Small Retailers

rishabh-hasija — Sun, 18 Oct 2026 21:34:16 +0000

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

What I Built

Adding products to an inventory sounds simple until catalogs grow. The same item often gets entered multiple times with slightly different names, pack sizes, or variants.

StockEntry Guard uses local Gemma 3 vision to extract product details, detect possible duplicates, and keep final inventory decisions with the retailer.

For example:

Coca-Cola Zero 330ml
Coke Zero Sugar 330 ml
Coca-Cola Zero 500ml

A normal product-entry form will happily create three unrelated records unless someone notices the duplication.

StockEntry Guard helps a retailer to:

Import an existing inventory CSV.
Upload a product photo.
Extract product details locally with Gemma 3.
Review and edit the extracted fields.
Compare the product against the existing catalog.
See whether there is no match, a possible match, or likely a duplicate.
Create a new product or update an existing one only after explicit human approval.
Export the updated inventory back to CSV.

The target user is a small retailer, independent shop, reseller, or anyone maintaining product data without a large inventory-management system.

How a retailer would use it

The current hackathon MVP runs locally and stores the retailer's catalog in a SQLite database.

A retailer imports their existing catalog once using CSV. After the import, the products are stored locally and remain available between application sessions.

From then on, new products can be added through the image workflow without re-importing the CSV.

The intended production experience is a Windows installer:

Install StockEntry Guard.
Launch the desktop shortcut.
Import an existing inventory CSV, or download the sample template.
Add future products by photographing them.
Export the catalog whenever needed.

For the hackathon MVP, the application still requires the local Python/Ollama setup described in the repository. Packaging it as a one-click Windows installer is the next deployment step.

The value is simple: reduce repetitive data entry and prevent messy catalogs from accumulating duplicate products.

Demo

Video demo:

https://drive.google.com/file/d/1GFhMoctpGnEdRfjUzeXzUT5H6zm5rnn3/view?usp=sharing

StockEntry Guard currently runs locally through Streamlit and uses Gemma 3 4B through Ollama for product-image extraction.

The demo shows the complete retailer workflow:

Import an existing inventory CSV.
Upload a product image.
Extract structured product details locally with Gemma.
Review and edit the extracted fields.
Check the product against the existing inventory for possible duplicates.
Approve the product.
Save it into the local inventory database.
Export the updated inventory back to CSV.

For the demo, I used a Hershey's Milk Chocolate bar.

The product image contains clear packaging information including the Hershey's brand, Milk Chocolate product type, and visible package weight.

Gemma analyzes the image locally and returns structured candidate data such as:

product name
brand
category
variant
size
SKU
barcode
description
confidence
uncertain fields

The extracted result is never written directly to inventory.

The retailer reviews the fields first, then runs StockEntry Guard's deterministic duplicate check.

The duplicate engine compares the candidate against existing inventory using product name, brand, variant, size, category, barcode, and SKU evidence.

The UI translates the result into simple messages such as:

No matching product found
Possible match found
Likely already in inventory

The retailer then explicitly chooses whether to create a new product, update an existing one, or discard the result.

After approval, the product is stored in the local SQLite inventory database and stays available in future application sessions.

The retailer can export the updated inventory back to CSV at any time.

This demonstrates the main goal of StockEntry Guard:

Use local AI to reduce manual product entry while keeping duplicate prevention and final inventory decisions under human control.

Video demo:

https://drive.google.com/file/d/1GFhMoctpGnEdRfjUzeXzUT5H6zm5rnn3/view?usp=sharing

Code

GitHub repository:

https://github.com/rishabh-hasija/stockentry-guard

The project includes:

Python 3.12
Streamlit
Gemma 3 4B
Ollama
SQLAlchemy
SQLite
Alembic
Pydantic
pytest
Ruff
mypy

The repository also contains architecture documentation, sample inventory data, automated tests, and a downloadable sample CSV for new users.

How I Built It

I wanted the hackathon MVP to stay small enough to finish, but I did not want the codebase to become a one-file Streamlit prototype that would need to be replaced later.

I used a modular monolith with clear boundaries:

Streamlit UI
     |
Application use cases
     |
Domain + ports
     |
Infrastructure adapters
     |
SQLite / Ollama / CSV / similarity engine

Why Does Open Innovation Matter?

Open-source AI is important to StockEntry Guard because the product is designed for small retailers who may not want product images, barcodes, catalog information, and internal inventory data sent to an external AI service.

StockEntry Guard runs Gemma 3 locally through Ollama.

That gives the retailer several practical benefits.

Product data stays local

Product photographs can contain packaging information, SKUs, barcodes, variants, and internal catalog details.

With local inference, the image can be processed on the retailer's own computer instead of being uploaded to a hosted AI API.

No per-product AI API bill

A retailer may eventually process hundreds or thousands of products.

A local open-weight model removes the need to pay for every image extraction request. The main requirement becomes local computing resources.

The model is replaceable

StockEntry Guard does not make the rest of the application depend directly on Gemma.

The AI layer implements an AIProductExtractor interface.

This means another local vision model could replace Gemma later without rewriting inventory management, duplicate detection, persistence, or the user interface.

I could control the extraction rules

For inventory data, a confident-looking wrong answer is worse than an empty field.

The extraction prompt therefore tells the model:

do not guess SKUs
do not guess barcodes
do not guess unreadable pack sizes
distinguish the brand from the product name
separate meaningful variants from marketing slogans
return null when information is uncertain

Open models and local inference made this combination of privacy, control, and low operating cost practical for the project.

My Agent Session

I used Codex as a development agent throughout the project, but built the application in small, reviewable slices instead of asking the agent to generate the entire project in one pass.

The main development stages were:

system architecture and repository structure
domain model and persistence
Ollama/Gemma image extraction
normalization and duplicate detection
CSV import/export and application workflows
Streamlit UI
retailer-facing UX refinement
regression testing and documentation

One of the most useful parts of this workflow happened during real Gemma testing.

All automated extraction tests were passing, but a real product image failed with:

MissingProductNameError

I tested Gemma directly with the same image and confirmed that its vision capability correctly identified the product as Heineken Lager Beer.

I then inspected the raw structured response produced through the application.

Gemma was returning only:

confidence
uncertain_fields

The issue was not the model or image.

The generated JSON Schema treated product fields such as name, brand, and variant as optional because they had default None values.

Gemma therefore followed the schema correctly and omitted them.

I changed the schema so every product key is required but nullable.

After the fix, the same real image produced:

Name: Heineken Lager Beer
Brand: Heineken
Category: Beer
Variant: City Edition
Confidence: 0.95

Unreadable SKU, barcode, and size values remained empty.

This was a useful reminder that passing mocked tests is not enough when integrating an AI model. I repeatedly tested the actual model between implementation slices and used those results to guide the next agent task.

The finished project currently has 238 automated tests covering the domain, persistence, migrations, extraction validation, duplicate detection, CSV workflows, transactions, idempotency, and Streamlit behavior.

My First User

Prize Categories

Best Use of Gemma

StockEntry Guard uses Gemma 3 4B as its local multimodal model.

Gemma analyzes retail product photographs and returns structured candidate information including product name, brand, category, variant, size, SKU, and barcode when those values are visible.

The model runs locally through Ollama.

AI output never writes directly to inventory. The retailer reviews the extracted information, StockEntry Guard independently performs deterministic duplicate detection, and the retailer explicitly approves the final inventory action.