This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

I built a tiny local-first review tool for a boring but real workflow: checking whether a merchant or vendor has source-backed public evidence behind the name they gave you.

The script searches public business registry records and optional WHOIS data, then asks a locally running Gemma 4 model to turn the raw evidence into a reviewer-friendly brief:

• strongest official-source matches
• fuzzy or name-similar matches that should not be over-trusted
• missing fields, like status, address, jurisdiction, or ownership evidence
• a suggested next verification step
• a compact evidence table with source URLs

The point is not to let an LLM decide whether a business is legitimate. That would be sloppy. The point is to give a human reviewer a clean first pass over messy public records while keeping the model grounded in the exact JSON it received.

This is the kind of tool I wanted while working on merchant underwriting and KYB data. A lot of the job is not glamorous AI reasoning. It is looking at several almost-matching entity names and asking, "Which of these are real matches, which are noise, and what evidence is still missing?"

Demo

Code and sample output are here:

https://gist.github.com/avabuildsdata/ac8054a90011563c665545844e194561

Run it locally with Ollama:

ollama pull gemma4:e4b
python3 merchant_evidence_brief.py "OpenAI" --states NJ,NY,TX,CA --domain openai.com

You can also inspect the exact evidence before the model sees it:

python3 merchant_evidence_brief.py "OpenAI" --states NJ,NY,TX,CA --domain openai.com --raw

A shortened sample from my run:

### Reviewer Summary
The public records search yielded several potential matches for "OpenAI" across New Jersey, Texas, and New York. The strongest matches are two entities in New Jersey: "OPENAI OPCO, LLC" and "OPENAI, L.L.C." The WHOIS data confirms that the domain openai.com is registered through MarkMonitor, Inc., and is set to expire in 2029. The remaining results in TX and NY are fuzzy matches, and several are listed as inactive.

### Watchouts / Missing Evidence
- The evidence does not prove ownership or current operational status for any entity.
- Specific street addresses are missing for most listed entities.
- WHOIS data only shows registrar and registration dates; it does not confirm the ultimate owner of the domain.

That last line matters. My first version of the prompt was not strict enough, and the model started to treat WHOIS registration as stronger evidence than it really is. I tightened the instruction to explicitly say: registrar and domain dates are not proof of company ownership. The second output was much safer.

Code

The whole demo is a single Python file. It uses:

• AutoScrape's public no-auth API for official-source evidence
• Python's standard library for HTTP and JSON
• Ollama's local /api/generate endpoint
• gemma4:e4b by default, with gemma4:31b as the stronger slower option

The core prompt is intentionally conservative:

Use ONLY the JSON evidence below. Do not infer legal status, legitimacy, fraud,
or ownership beyond what the evidence says. WHOIS registrar/domain dates are not
proof of company ownership. If a field is missing, say it is missing. If there
are multiple possible matches, separate exact-looking matches from fuzzy/name-
similar matches.

That constraint is the product. In a workflow like this, a confident unsupported claim is worse than a missing answer.

How I Used Gemma 4

I used Gemma 4 as the local reasoning and writing layer over structured public evidence.

I chose gemma4:e4b for the default because it hits the useful middle of the challenge constraints:

• it runs locally on my machine through Ollama
• it is fast enough for an interactive reviewer loop
• it has enough context for multiple registry results plus WHOIS evidence
• it can produce structured Markdown without needing a hosted model or third-party LLM API

For a production version I would probably expose a model choice:

• gemma4:e4b for fast first-pass review
• gemma4:31b for slower, higher-quality review when the evidence is ambiguous
• a no-model --raw mode for auditors who only want the source JSON

What Gemma 4 unlocked here was not magic classification. It was local, private, repeatable synthesis over awkward official-source records. That is a good fit for compliance-adjacent work because the sensitive part is often the merchant list itself. Keeping the model local means I can test the workflow without sending that list to a hosted model provider.

What I learned

The main lesson was that model usefulness depends on the evidence boundary.

If I ask, "Is this merchant legitimate?" the model can only guess. If I ask, "Given only these records, which names look exact, which are fuzzy, and what is missing?" the model becomes much more useful.

I also learned that local models are good enough for a lot of the unsexy work around public data: deduplicating names, writing reviewer notes, and making missing evidence obvious. The model does not need to be the system of record. It needs to make the system of record easier to read.

What I would add next

If I had another day, I would add batch mode for CSV merchant lists and a stricter JSON output option so the brief could plug into a case-management or underwriting queue.

The most important future feature would be evaluation: a small set of known exact, fuzzy, and no-match cases so I can measure whether the prompt/model combination stays conservative as the evidence gets messier.