Fieldnotes AI: a local evidence copilot for maintenance teams

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

What I Built

A maintenance question often has several answers scattered across an inspection note, a shift log, a work order, and a manual. Fieldnotes AI is a small, local copilot that brings those records together for a person reviewing an asset. It retrieves relevant records, flags contradictory numeric readings, and asks an open-weight model to produce an answer with record IDs and caveats.

The potential customer is a small maintenance contractor or asset team that spends time reconciling inspection and operations records but cannot casually send client records to a third-party AI service. A paid version could help them search their own records, surface disagreements, and prepare evidence for human review. That is a proposed use case, not a claim of paying customers or validated demand.

The included demo uses fictional records. For Aster 17, an inspection lists tubing pressure at 182 bar while a same-day operations log lists 147 bar. A valve work order is still pending. The app surfaces that disagreement instead of picking a value or claiming that the repair is complete. It does not make safety or engineering decisions.

Demo

The demo runs locally; there is no public hosted dashboard or video yet. To open it on your machine, follow the quick start in the repository: install Node.js 20+ and Ollama, pull the default Qwen3 model, then run:

ollama pull qwen3:8b
git clone https://github.com/AnkitPandit120/fieldnotes-ai.git
cd fieldnotes-ai
npm run demo

Open http://127.0.0.1:4173 on that same machine. The asset overview and conflict watch use the sample records without a model; answering questions needs Ollama running locally. A local URL is not a public demo link.

Code

Fieldnotes AI on GitHub is MIT licensed. It contains the Node.js package and CLI, local dashboard, fictional sample data, and setup guide. The package has no runtime npm dependencies.

How I Built It

1. Validate structured JSON records and connect each one to an asset.
2. Rank records with transparent keyword matching across asset names, IDs, titles, text, and source labels.
3. Compare measurements for the same asset, date, and metric. Values that differ by more than 5% become a conflict for review.
4. Send only the selected records and detected conflicts to Qwen3 through local Ollama inference.
5. Require the model to return structured JSON with an answer, record-ID citations, caveats, and a suggested follow-up. Reject citations that do not match retrieved records.

The source list proves which records were supplied to the model; it does not prove that every generated sentence is correct. Keyword retrieval can miss synonyms, and the demo reads structured JSON rather than parsing PDFs or CSVs. Those are the next areas to improve. I have not run automated tests or a user study for this prototype.

Why Does Open Innovation Matter?

The default runtime can stay on a team's machine: Ollama serves an open-weight Qwen3 model locally, and the app sends its evidence to that local endpoint rather than a hosted model API. After the model is downloaded, questions do not require an AI API key. Teams can choose another installed model without rewriting the evidence pipeline. Local inference still has hardware and operating costs, so I am not claiming that it is free.

That control matters for a niche workflow where records may be sensitive and the format of evidence is as important as a fluent answer. The project keeps retrieval, conflict rules, prompts, and citation checks visible in source code so a team can inspect and adapt them.

Related reading: Local RAG: Chat With Your Documents by Lingdas1 and RAG Beyond the Demo: Pipeline, Citations, Evaluation, and When Not to Bother by Xinyang Wu discuss local document workflows and the limits of citations.

Disclosure: Codex helped implement this prototype and draft this post.