Gemma 4 Challenge: Gemma Sonar Scout

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

What I Built

I built Gemma Sonar Scout, a local monitoring tool that watches supplier and dependency changelogs, release feeds, and status pages, then turns the new evidence into a daily operator brief.

The problem is simple: modern products depend on a stack of external services. Cloud hosts, DNS providers, payment processors, API platforms, AI tools, CI systems, and support platforms all publish important changes in different places. Some updates are harmless. Some are breaking changes. Some are outages that matter immediately.

Gemma Sonar Scout has two layers:

• A deterministic scanner fetches configured sources, parses RSS, Atom, Statuspage-style incident JSON, plain JSON, and basic public HTML, detects severity/categories, hashes events, and tracks local state so the digest can focus on what is new.
• A Gemma 4 summarization layer receives the structured evidence and produces a concise daily brief: headline, alert level, summary, recommended actions, and event-level reasoning.

That split is intentional. The model does not decide whether an outage happened or invent sources. The scanner builds the evidence packet; Gemma 4 makes the evidence readable and actionable.

The tool can run as a local cron job and outputs both markdown and a browser-friendly HTML report.

Example:

sonar-scout scan \
  --config examples/hosting-dependencies.json \
  --include-seen \
  --output daily-digest.md \
  --html-output daily-report.html

The bundled demo config watches providers like DigitalOcean, Cloudflare, GitHub, Vercel, Render, and Fly.io.

Demo

Demo video: Here

Local demo with Ollama running locally:

python3 -m pip install --upgrade pip setuptools wheel
python3 -m pip install -e .
PYTHONPATH=. python3 -m sonar_scout demo \
  --gemma-base-url http://localhost:11434/v1 \
  --gemma-model gemma4:e4b \
  --output demo-digest.md \
  --html-output demo-report.html

For a report like the recorded hosting demo:

PYTHONPATH=. python3 -m sonar_scout scan \
  --config examples/hosting-dependencies.json \
  --include-seen \
  --gemma-base-url http://localhost:11434/v1 \
  --gemma-model gemma4:e4b \
  --output demo-digest.md \
  --html-output demo-report.html
python3 -m http.server 8877 --bind 127.0.0.1

Then open:

http://127.0.0.1:8877/demo-report.html

For the recorded demo I used the bundled hosting config and public status-page examples from DigitalOcean, Cloudflare, GitHub, Vercel, Render, and Fly.io.

Code

Repository: https://github.com/changecrab/gemma-sonar-scout

Key files:

• sonar_scout/fetchers.py parses RSS, Atom, Statuspage incident JSON, basic HTML, and local fixture files.
• sonar_scout/detectors.py handles deterministic severity, category, and stable event-hash detection.
• sonar_scout/gemma.py sends the structured evidence packet to a local OpenAI-compatible Gemma endpoint.
• sonar_scout/render.py renders markdown and HTML reports.
• examples/hosting-dependencies.json is a practical demo config for public hosting/status providers.

How I Used Gemma 4

I used Gemma 4 E4B-it as the target model.

I chose E4B-it because the project is designed to run locally and repeatedly. A supplier-monitoring digest is exactly the kind of workflow where local AI makes sense: the raw operational context can stay on the user's machine, and the model only receives a compact evidence packet assembled by deterministic code.

E4B-it is a good fit because it offers a practical balance:

• Small enough to fit the local-first story better than a large hosted-only model.
• Capable enough to summarize messy multi-provider evidence better than a tiny edge model.
• Useful for long daily context windows when a team monitors many vendors.

Gemma 4 receives JSON shaped like this:

{
  "events": [
    {
      "id": "stable-event-id",
      "monitor": "Cloudflare",
      "source_type": "status",
      "title": "Network connectivity issue",
      "published_at": "2026-05-08T10:00:00Z",
      "severity": "warning",
      "categories": ["reliability"],
      "url": "https://status.example/incidents/example",
      "content": "Evidence text from the public incident update"
    }
  ]
}

It returns structured JSON:

{
  "headline": "short headline",
  "alert_level": "quiet|normal|watch|urgent",
  "executive_summary": "4-6 sentence summary",
  "recommended_actions": ["action 1", "action 2"],
  "notable_events": [
    {
      "event_id": "stable-event-id",
      "why_it_matters": "short explanation"
    }
  ]
}

This keeps the application testable and trustworthy. The scanner is responsible for evidence. Gemma 4 is responsible for synthesis.

The tool also works without Gemma via --no-gemma, which makes it easy to review, test, and demo before a local model server is running. When Gemma 4 is available, the same scan becomes a much better daily brief.

Why This Matters

Supplier change monitoring is often either too manual or too noisy. Teams do not need another raw feed; they need a quick answer to:

• What changed since yesterday?
• Which changes could affect us?
• What should someone check next?

Gemma Sonar Scout is a local, transparent version of that workflow.

Note: Gemma Sonar Scout is a free and simplified, local-AI adaptation of the monitoring engine we use at ChangeCrab. If you don't want to host this yourself, need something a little more robust - and just want the alerts in your Slack/email, check out ChangeCrab Sonar.