DEV Community: Abhijeet Nardele

GearWitness: Privacy-First Local AI Return Inspection for Equipment Rentals

Abhijeet Nardele — Thu, 15 Oct 2026 13:22:29 +0000

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

What I Built

Independent camera-rental shops, community equipment libraries, and creators running rental side hustles face the same awkward moment: a valuable kit comes back, a customer is waiting, and the operator must quickly decide whether a mark is new damage, harmless glare, or normal wear—and whether every cable and battery came back.

GearWitness is a privacy-first local AI return-inspection workstation. It aligns checkout and return photos, proposes evidence-backed changes, reconciles the kit inventory, and requires a human decision before an inspection can be finalized.

The paying users are small rental operators and media-loan desks that cannot justify enterprise inspection software or cloud vision fees. My launch hypothesis is a $39 one-time workstation license, with an optional paid setup service for custom capture templates and inventory imports. This is a pricing hypothesis, not a revenue claim; I have not taken payment yet.

Why would they pay?

Faster, calmer counter check-ins
Fewer missed accessories before the customer leaves
Evidence-linked conversations instead of subjective memory
No per-image API bill or cloud subscription
Customer photos, serial numbers, and project context stay on the shop's machine

Demo

Live demo: https://gearwitness.onrender.com

The public Render deployment deliberately identifies itself as Deterministic Fixture mode. It demonstrates the complete operator workflow without pretending that the free hosted container has a local Ollama runtime. A free Render instance may need a short cold start after inactivity.

Try this path:

Drag the comparison divider across the Sony FX3 baseline and return images.
Toggle the heatmap or switch to side-by-side view.
Confirm the real scratch, dismiss the lighting artifact, and mark the missing cable uncertain or confirmed.
Open Review & Export. The server will not allow final approval while any proposal remains pending.
Export the manifest JSON, printable HTML, or vector PDF report.

The deployed health endpoint, image fixtures, evidence crops, operator decisions, manifest, HTML report, and PDF report were all verified with HTTP 200 responses. A clean browser run produced zero console errors.

Code

abhijeetnardele24-hash / gearwitness

Privacy-first local AI return-inspection system for equipment rental businesses. Hacktoberfest 2026 Week 2.

GearWitness 🔍

Privacy-First Local AI Return-Inspection System for Equipment Rental Businesses
Deterministic Computer Vision Alignment + Constrained Local Gemma 3 Multimodal Reasoning + Strict Human Decision Boundary

📌 Executive Summary

Equipment rental operations (cameras, cinema packages, pro audio, drones, precision surveying tools, and construction machinery) face a structural friction point at the return counter:

Check-In Bottlenecks: Skilled rental agents spend 10–20 minutes visually inspecting cameras and multi-piece accessory cases, causing long customer queues during peak turn-in windows.
Disputed Charges: Minor scuffs, preexisting wear, and lighting glare create confrontational disputes between operators and valued clients.
Missing Kit Accessories: High-value items (e.g., $150 USB-C tethering cables, custom mounting brackets, extra NP-FZ100 batteries) are overlooked until the next customer discovers them missing on a production set.
Cloud Privacy & Compliance Liabilities: Operators hesitate to upload proprietary equipment photos, rental contracts, and customer serial numbers to third-party proprietary clouds.

GearWitness solves this by bringing…

View on GitHub

Repository: https://github.com/abhijeetnardele24-hash/gearwitness

The repository includes an Apache-2.0 license, Dockerfile, Render Blueprint, architecture guide, model card, evaluation methodology, privacy threat model, deterministic fixtures, and reproducible automated tests.

How I Built It

GearWitness deliberately separates detection, reasoning, and authority.

1. Deterministic alignment before AI

Checkout and return photos rarely share the same angle. Feeding unaligned images directly to a vision model encourages false differences. GearWitness first uses OpenCV ORB keypoints, Hamming-distance matching, RANSAC homography, perspective warping, bilateral filtering, luminance subtraction, and Otsu thresholding. The result is a set of small, aligned candidate regions rather than two uncontrolled full-frame images.

2. Local Gemma 3 multimodal reasoning

Aligned crop pairs are sent to Gemma 3 4B through Ollama in local mode. Gemma must produce a schema-valid condition, severity, confidence, description, and observable rationale. It is not asked who caused damage and it cannot create a charge.

Real local execution was verified against Gemma 3 4B. When Ollama is unavailable, GearWitness does not disguise fixture output as model inference: health metadata reports Ollama disconnected and labels the engine Deterministic Fixture Engine.

3. A strict human decision boundary

Every proposal has exactly three operator actions:

Confirm Damage
Dismiss Wear / Glare
Mark Uncertain

The backend rejects final approval while any proposal remains pending. There is no payment integration and no automatic charging path. The model proposes; the operator decides.

4. Evidence and integrity

The final report binds source-image hashes, proposal coordinates, inventory status, and operator decisions into a SHA-256 Content Integrity Digest. This is accurately described as tamper-evident when compared with a trusted stored digest—not as a digital signature, timestamp authority, or proof of custody.

Architecture

Checkout and return photos flow through OpenCV alignment, candidate-region extraction, local Gemma structured analysis, the human review UI, and finally the integrity manifest plus reports. FastAPI and SQLite provide the local API and storage layer; React and TypeScript provide the forensic comparison workspace.

The design remains modular: the model adapter can be swapped, the deterministic vision stage can be tuned independently, and the operator boundary remains enforced server-side.

Why Does Open Innovation Matter?

Open innovation is not a branding choice here; it is what makes the product viable.

Privacy: Rental records may contain names, serial numbers, location metadata, and images from unreleased productions. Local Ollama inference keeps that material off hosted model APIs.

Predictable economics: A one-time tool for a small shop is difficult to sustain if every inspection generates variable vision-API charges. Running Gemma on existing hardware makes the pricing model possible.

Replaceability: Operators are not locked into one provider's endpoint, retention policy, or pricing. The model layer is explicit and swappable.

Auditability: OpenCV, FastAPI, Pydantic, SQLite, Ollama, and the application code can be inspected and tested. Degraded behavior is visible instead of silently substituted.

Community work on local multimodal models with Ollama, privacy-preserving local computer vision, and zero-monthly-cost local AI servers reinforced these choices.

Evaluation and Quality Evidence

I used a separated 40-case synthetic benchmark. Prediction code receives inputs without gold labels; a regression guard fails if a prediction runner attempts to access ground truth.

Results:

40 matched-pair cases
24 true positives
0 false negatives
100% recall on the synthetic damage cases
0.787 F1
100% missing-accessory accuracy across 8 cases
Zero automatic charges by architecture

The deliberately sensitive pixel baseline also produces false positives under lighting changes. That limitation is exactly why candidate generation is followed by multimodal reasoning and mandatory human review rather than an automatic accusation.

Automated quality gates are green:

61 backend tests with 92.96% line coverage
10 React component tests
6 Playwright browser tests across 360px to 1920px
Zero serious or critical Axe accessibility violations
Ruff, Bandit, and Oxlint clean
Docker health gate and GitHub Actions green

Honest Limitations

Extreme perspective differences can require a guided recapture.
Specular optics and chrome remain difficult under inconsistent lighting.
Live Gemma inference requires a local Ollama installation and Gemma 3 4B model.
The public Render demo uses transparent fixture mode because it does not include the local model runtime.
The current benchmark is synthetic and is not a substitute for a multi-shop field study.

Prize Categories

Best Use of Gemma

Gemma 3 4B is the local multimodal reasoning layer over tightly cropped, OpenCV-aligned evidence. It converts visual deltas into constrained proposals while leaving every consequential decision to the operator.

Best Use of Render

Render hosts the complete public judging experience from the repository's Blueprint: React UI, FastAPI service, health checks, image fixtures, evidence crops, manifest JSON, printable HTML, and PDF generation from one Docker service.

What I Learned

The strongest design was not “let the model decide.” It was to give each subsystem a narrow job: deterministic vision finds candidate regions, Gemma explains physical deltas, and the human owns the decision. That separation made the application more useful, more testable, and more honest.

GearWitness turns an uncomfortable return-counter judgment into a calm, source-linked workflow—without sending sensitive inspection data outside the deployment boundary.

GroundSignal — The Sidewalk Told on Itself

Abhijeet Nardele — Thu, 08 Oct 2026 20:10:14 +0000

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

What I Built

GroundSignal started with one question: can the motion already happening in your pocket become useful evidence without becoming surveillance?

I built it from scratch during the Week 1 challenge window. It turns a short walk, wheelchair journey, or stroller trip into a private, inspectable surface report. The AI core is TabPFN, which is well suited to the small, personal calibration sets this problem creates—and gives me probability evidence instead of a mystery label.

A sidewalk already communicates through motion. Smooth pavement, rough patches, unstable sections, and transitions all feel different, but they also change with the person, mobility mode, device, phone placement, pace, and conditions. So GroundSignal does not pretend that one universal threshold can describe every path. It learns from surfaces the user already knows.

That is the Touch Grass idea at the center of the project: the useful data is collected while someone is actually moving through the world. Screen time is reserved for setup, review, and export.

The deployed starting screen: no account, no map, and no location collection.

The workflow is deliberately designed to keep the screen as the shortest part of the experience:

Choose a mobility mode and phone placement.
Record examples of at least two known surface types.
Start an audit and put the phone in a pocket, bag, or mount.
Move naturally while GroundSignal records motion locally.
Finish the audit and inspect the resulting surface signals.
Confirm, correct, or discard uncertain predictions.
Export the evidence as CSV or JSON.

During recording, Pocket Mode becomes intentionally quiet and minimal. The product should encourage the user to experience the outside world instead of staring at another dashboard.

GroundSignal is intended for walkers, wheelchair users, mobility-scooter users, parents using strollers, and anyone interested in documenting how a path physically feels.

GroundSignal is a field-observation tool—not a route-safety guarantee, navigation product, or universal accessibility rating.

Demo

Live application

Open the GroundSignal live demo

This self-playing walkthrough was captured from the deployed application. The demo motion is synthetic and visibly labeled; it is not presented as field evidence.

The application includes a Run transparent demo walk option. It creates clearly labeled synthetic motion data, allowing judges to evaluate the complete workflow without granting sensor permission or physically carrying a phone.

The transparent demo covers:

Personal calibration data
Overlapping motion-window analysis
Surface predictions
Complete probability distributions
Confidence and abstention
Evidence-quality warnings
Human review and correction
Calibration improvement using reviewed signals
Local report persistence
CSV and JSON evidence exports

The report keeps the model name, confidence, evidence-quality warning, route signature, and human-review controls visible together.

The production API health endpoint is also public:

GroundSignal API health

The API response identifies the active model provider as tabpfn.

Because the API currently uses Render's free compute plan, the first request after an idle period may need a short cold start. The installed PWA still has a deterministic local fallback when the hosted model cannot be reached.

Three-minute judge path

Open the application and notice the local ledger and privacy boundary.
Select Run transparent demo walk.
Inspect the predicted route segments, probabilities, confidence, and review queue.
Confirm or relabel one uncertain segment.
Promote the reviewed signal into the next local calibration.
Export the report as CSV or JSON.
Reload the application and confirm that the report remains in the local ledger.

Code

The complete project is open source under the MIT License:

abhijeetnardele24-hash / groundsignal

A local-first pocket field instrument for uncertainty-aware surface reports.

GroundSignal

The sidewalk told on itself. Turn a short outdoor walk into a private, inspectable, uncertainty-aware surface report.

GroundSignal is a local-first pocket field instrument for the Hacktoberfest 2026 Week 1 Touch Grass challenge. It uses phone motion sensors, personal calibration, transparent signal features, and an open tabular model to describe how a path felt underfoot or under wheels—without collecting location or identity.

The project is built for two challenge categories:

Best Use of TabPFN: few-shot, personal surface classification from a small labeled calibration set.
Best Use of Render: a deployable PWA and bounded FastAPI inference service defined in one Blueprint.

GroundSignal is a field-observation aid. It is not a safety guarantee, navigation service, or universal accessibility rating.

Why this should exist

Traditional path data is usually static, generic, or tied to a map. But a surface feels different depending on a person's mobility mode, phone hardware, placement, weather, and…

View on GitHub

Repository: github.com/abhijeetnardele24-hash/groundsignal

The repository contains:

React 19 and TypeScript PWA
FastAPI analysis service
TabPFN model provider
Deterministic offline baseline
Motion-feature extraction
IndexedDB persistence
CSV and JSON export
Automated frontend and backend tests
GitHub Actions continuous integration
Render Blueprint deployment
Architecture, security, field-testing, and contribution documentation

How I Built It

GroundSignal is separated by a strict privacy boundary: raw motion belongs to the browser.

Raw motion stays on the device. Only bounded derived features and personal calibration labels cross the explicit analysis boundary; probabilities return for local human review.

Motion becomes bounded tabular evidence

GroundSignal listens to browser DeviceMotionEvent readings after an explicit user action. It records acceleration and rotation locally, then divides the recording into overlapping three-second windows.

Each window becomes a bounded feature vector containing interpretable measurements such as acceleration RMS and standard deviation, peak-to-peak acceleration, jerk RMS, gyroscope RMS, dominant frequency, spectral entropy, vertical and horizontal energy, and sample coverage.

Raw sensor samples are never included in an analysis request. GroundSignal also does not request or collect GPS coordinates, precise location, identity, accounts, camera data, or microphone data.

Personal calibration with TabPFN

A surface signal depends heavily on the user's device, mobility mode, phone placement, and pace. That makes this a small, session-specific tabular learning problem.

Before analysis, GroundSignal requires at least eight usable calibration windows covering at least two known surface classes.

The production backend sends only derived features and user-provided calibration labels to the TabPFN provider. The model returns predictions for:

smooth
rough
unstable
transition

Each prediction contains the complete probability distribution, not only the winning label. A prediction below the documented 0.58 confidence threshold is marked as abstained and placed into human review. GroundSignal does not silently turn uncertainty into truth.

Human judgment remains part of the model loop

A user can confirm a prediction, correct its surface label, discard an unusable window, or promote reviewed evidence into later local calibration. The correction remains visible in the exported evidence, making model output inspectable instead of presenting it as unquestionable truth.

Local-first and offline-capable

Reports, derived features, calibration evidence, and reviews are stored in IndexedDB. The local ledger has bounded retention and allows recent audits to be reopened.

The PWA includes a manifest and service worker. If the hosted API is unavailable, the frontend switches to an explicitly named offline-transparent-baseline.

The fallback is a deterministic nearest-centroid classifier. It is not disguised as TabPFN, and every exported report identifies which provider produced it.

A bounded public API

The FastAPI service applies strict schemas that reject unknown fields, request-size limits, rate limiting, model concurrency limits, an inference timeout, restricted CORS origins, and defensive browser headers.

The production service has no user accounts, file uploads, location storage, or database. The frontend and API are deployed together using a Render Blueprint, while the TabPFN token remains a private Render environment variable.

Verification

I tested the project locally and on its deployed Render environment.

Current automated verification:

9/9 frontend tests passed
12/12 backend tests passed
Production PWA build passed
Python dependency check passed
Production npm audit reported 0 vulnerabilities
GitHub Actions passed
Render Blueprint parsed and deployed successfully

The deployed flow was also tested through the browser:

Production API health and model card
TabPFN analysis
Confidence and abstention
Human review
Calibration promotion
IndexedDB persistence across reload
CSV and JSON export
Service-worker registration
Offline reload and transparent fallback
CORS, request limits, validation, and security headers
No browser-console errors during the complete demo

I kept the synthetic demo visibly labeled as simulation. I do not present generated motion as real field evidence, and GroundSignal documents physical phone testing as a separate validation step.

Why Does Open Innovation Matter?

GroundSignal handles motion that may indirectly reflect a person's mobility and environment. That made an inspectable, replaceable, and privacy-conscious architecture more important than hiding everything behind one opaque prediction endpoint.

Open innovation made four important design decisions possible:

The model is replaceable. The backend uses a provider interface instead of coupling the product permanently to one model. TabPFN powers the competition deployment, while the transparent local baseline preserves the workflow during poor connectivity.
The input boundary is visible. The repository documents every feature that may leave the device. Raw acceleration, rotation, location, and identity are excluded.
Uncertainty is a product feature. Access to prediction probabilities lets GroundSignal expose uncertainty directly. When the model is unsure, the interface says review.
Offline behavior remains useful. GroundSignal keeps its reports and calibration locally, and its fallback behavior is deterministic, labeled, and inspectable.

The project is available under the MIT License so others can audit its privacy assumptions, test alternative models, improve the feature pipeline, or adapt the instrument for different mobility experiences.

Two community perspectives reinforced these choices:

Offline-first without a backend: building a local-first PWA you can actually trust emphasizes explicit trust boundaries, authoritative local storage, predictable service workers, and deliberate exports.
What I Learned After Reviewing Many AI and Developer Projects as a Hackathon Judge argues that completion, evidence, documentation, privacy, and deployment readiness turn an interesting idea into a trustworthy project.

My Agent Session

I used an AI coding agent as a pair programmer during implementation, testing, security review, documentation, and Render deployment.

AI assistance helped with reviewing architecture decisions, refining implementation code, expanding automated tests, diagnosing deployment and CORS issues, testing the local and deployed applications, and improving documentation.

I reviewed the resulting work, kept the repository history visible, ran the complete test suites, and manually verified the deployed user journey.

The project does not include API keys or secrets in the repository. Any agent-session transcript will be reviewed for sensitive setup information before being made public.

Prize Categories

Best Use of TabPFN

GroundSignal uses TabPFN for a small, personal, tabular classification problem.

Each session begins with a limited calibration set representing the current user, device, placement, mobility mode, and conditions. TabPFN converts those calibration examples and derived motion features into a probability distribution across four surface-signal classes.

The project makes the result inspectable through probabilities, confidence, abstention, evidence-quality reporting, and human correction.

Best Use of Render

Render hosts the complete public application:

A static React and TypeScript PWA
A Python FastAPI inference service
Automated deployment after successful checks
Health monitoring
Private environment-variable management for the TabPFN token
Explicit CORS and security-header configuration

Both services are defined in a single render.yaml Blueprint, making deployment reproducible directly from the public repository.

GroundSignal uses Render as more than a place to host a landing page: Render runs the bounded inference API connecting personal calibration evidence to TabPFN.

GroundSignal asks people to look at the path, not the screen.

The phone becomes a small field instrument. The model stays uncertain when it should. And the sidewalk gets a chance to tell its own story.