This is my submission for the Hacktoberfest Open-Source AI Challenge — Week 2: Side Hustle.
What I Built
I built LocalBiz Scout, a Python tool for analyzing business CSV data, reviewing potential data-quality issues, and applying explicitly approved corrections.
Business data cleaning is not just about finding inconsistencies. An incorrect phone-number correction or a false duplicate match can be worse than leaving a record untouched. I wanted to build a workflow where automation identifies problems, but the person responsible for the data retains control over changes.
LocalBiz Scout has three main stages:
- Analyze: Generate structured findings, a Markdown report, and duplicate candidates.
-
Review: Create correction proposals and a decision template. Proposals default to
deferred. - Remediate: Apply only accepted, allowlisted formatting corrections and produce an audit trail.
The tool preserves the original input, protects existing outputs, and does not merge or delete records as part of duplicate handling.
The intended users are developers and data teams working with business directories, lead lists, and other CSV datasets that need a reviewable data-quality workflow.
Demo
I verified the complete analyze → review → remediate workflow using synthetic business records.
The workflow produced the expected reports, review templates, corrected CSV, and remediation audit. I accepted two proposed corrections, deferred one, and rejected another. Only the two accepted corrections were applied, and a SHA-256 check confirmed that the original input remained unchanged.
I also ran the web interface locally and verified that it rejected invalid Host and Origin requests. The interface is loopback-only and analyze-only.
There is no hosted demo at present. The project can be run locally using the instructions in the repository.
Code
GitHub repository: ayushshandilya-dev/LocalBiz-Scout
The implementation includes the CLI, CSV analysis, correction review, controlled remediation, audit generation, a local web interface, and automated tests.
How I Built It
The project uses Python, RapidFuzz for fuzzy matching, Pytest for testing, and a small local web interface.
I designed the workflow around a distinction between proposing a change and being authorized to apply it.
Correction proposals are not automatically applied. The user must explicitly accept them, and only predefined correction rules are permitted. The remediation process writes a separate output and records what was proposed, what decision was made, and whether the correction was applied.
Duplicate candidates are treated as items for review rather than permission to merge records. The matching logic also accounts for address details such as house numbers and unit identifiers, which can distinguish businesses with otherwise similar information.
I added safeguards for input/output path conflicts, existing output files, malformed decisions, CSV quoting, and embedded newlines. These are easy to overlook in a small utility, but they matter when the input contains data that must not be silently changed.
Where AI Fits
AI is optional rather than a prerequisite for the core workflow.
I integrated local inference through Ollama for ambiguous duplicate-candidate adjudication. I verified an offline run using the locally available gemma3:1b model, which adjudicated three ambiguous candidates without falling back.
The deterministic workflow remains usable without AI. The model does not directly rewrite business records or bypass the review and remediation safeguards.
Why Does Open Innovation Matter?
Open innovation makes it possible for developers to inspect, test, adapt, and challenge the design rather than relying on an opaque data-cleaning service.
For this project, the important benefit is transparency. The correction rules are explicit, decisions are reviewable, and remediation produces an audit trail. Developers can inspect how candidate matches are generated and decide whether the safeguards fit their own datasets.
Local inference also provides an option for experimenting with AI-assisted adjudication without sending the sample data to a hosted model API. It does not eliminate the need to validate model outputs, which is why the AI path remains optional.
My Agent Session
I used OpenCode as a coding agent during development and verification.
The process included implementation reviews, regression testing, data-integrity checks, and a final audit of installation and command-line behavior. I kept the final verification separate from implementation changes so the reported results could be checked against the committed revision.
I do not have a published DevRelay or agent-session link to include here.
Testing and Results
The final verification reported:
- 406 tests passed
- 1 test skipped because IPv6 loopback binding was unavailable in the environment
- Installation through
pip install .verified in an isolated virtual environment - Installed console-script entry point verified
- End-to-end analysis, review, and remediation verified on synthetic data
- Local web-server smoke tests passed
- Optional Ollama adjudication verified offline
These results establish that the tested workflow works in the verification environment; they are not a claim of production deployment or real-world adoption.
Prize Categories
This project is submitted to the Hacktoberfest Open-Source AI Challenge Week 2. The relevant themes are Python tooling, practical AI integration, and open-source developer tools.
Closing Thoughts
The central lesson from building LocalBiz Scout is that useful automation needs boundaries.
Finding a likely correction is one problem. Deciding whether the system is allowed to apply it is another. By separating analysis, human review, and remediation, I wanted to make data cleaning more auditable and less likely to silently damage the original dataset.
The implementation is complete and available for review on GitHub. Feedback on the correction workflow, duplicate matching, and safe handling of CSV data is welcome.
Top comments (0)