George Town, Penang is a UNESCO World Heritage city — popular with tourists and residents on foot. But walking its streets in the midday heat is genuinely uncomfortable, sometimes dangerous. The obvious "shortest path" from A to B ignores shade, heat-trapped alleyways, and real-time temperature. No existing navigation app accounts for thermal comfort.

The client, Think City — a George Town urban regeneration organisation — wanted a routing tool that would encourage walking by making it cooler, not just faster.

An AI-powered walking route optimiser that returns three options for any A→B journey: Fastest, Coolest, and Balanced. The coolness score is computed per road segment using satellite-derived Land Surface Temperature (LST), real-time weather, shade analysis from Landsat imagery, and an XGBoost model trained on 22 geospatial features. Results are displayed on an interactive Leaflet map with segment-level heat overlays.

22 features per road segment: OSM attributes, time of day, segment geometry, NDVI, shade coverage percentage, live weather (temperature, humidity, UV), neighbour segment averages, and lag features. Tracked in MLflow experiment coolest-path-lst.

Ingress: /coolpath/ → Traefik → UI nginx. GPU pod uses nodeSelector: kubernetes.io/arch: arm64 + NVIDIA_VISIBLE_DEVICES=all (no device plugin — GB10 unified memory workaround).

The public release (for Think City, George Town) uses Docker Compose on Ubuntu 22.04. Minimum spec: 16 CPU cores, 64 GB RAM, 1 TB storage.

git clone https://github.com/innovationhubmy-svg/coolest-path.git
cd coolest-path
cp .env.template .env  # fill in Google Maps, WeatherLink, NASA Earthdata keys
docker-compose -f docker-compose.production.yml up -d
./scripts/health-check.sh

Network Operations Centres (NOCs) deal with a flood of alerts from monitoring systems like Zabbix. Most of these alerts are raw — they say a switch went down, but not which customer is affected, what the likely cause is, or what the operator should do first. Tier-1 engineers spend significant time correlating device → customer → location → history before they can act.

This project simulates that workflow end-to-end and demonstrates how an LLM can compress the triage time by generating a ready-to-use incident summary with remediation steps and a customer communication draft — automatically.

A four-container Docker Compose pipeline that takes a Zabbix-style alert webhook, enriches it against a CMDB, calls a local LLM (Qwen 2.5 7B) to generate a natural-language incident summary and recommended actions, and displays everything in a live NOC dashboard. The LLM also generates a communication action — a drafted message to both the device owner and the affected customer. All running on-premises, no cloud dependency.

Pluggable via .env — no rebuild needed to switch provider.

git clone http://git.lab.local/AI_Innovation_Hub/network-emu.git
cd network-emu
cp .env.example .env   # set LLM_BASE_URL and LLM_MODEL
docker compose up -d
# Dashboard: http://<host>:8080
# Simulate an alert:
curl -X POST http://localhost:8001/alert \
  -H "Content-Type: application/json" \
  -d '{"device_id":"SW001","problem":"Interface GigE0/1 down","severity":"high"}'

Sales teams often need quick answers during client meetings — product specs, pricing, deal history, competitive comparisons. Reaching for a laptop and waiting on a cloud AI tool breaks the flow of conversation. And for organisations with sensitive client data, sending that data to a cloud LLM raises privacy concerns.

The ask: a sales assistant that knows your product catalogue and CRM data, runs entirely on the sales rep's laptop, answers in seconds, and never sends data outside the device.

A chat assistant that runs Qwen3-4B fully on the Qualcomm NPU (Snapdragon X Elite) — no GPU, no cloud, no internet required during chat. Product docs and client data are auto-indexed into a local ChromaDB on startup. CRM connectors (HubSpot, Salesforce) pull live deal context at query time. The whole thing ships as a signed one-click Windows installer for instant deployment on any Snapdragon X Elite device.

IntelliSalesWidget/
├── source_code/
│   ├── run.py          # entrypoint (~15 KB)
│   ├── app/            # FastAPI routes, LLM, RAG pipeline
│   ├── config/         # model paths, CRM config
│   ├── data/           # product docs, client docs (watched dirs)
│   ├── qnn_backup/     # QNN DLC weight files
│   ├── ui/             # chat UI (served statically)
│   └── tests/
├── installer/
│   ├── installer.iss   # Inno Setup script
│   ├── build_installer.py
│   └── sign_installer.ps1  # code-signing
└── pyproject.toml

Most AI chat tools are cloud-dependent — your conversations, your lab data, and your queries go to OpenAI, Anthropic, or Google. For a government-adjacent AI lab in Malaysia, that's a sovereignty concern. The team also needed the chat tool to know the lab — to answer questions about hardware specs, project details, and internal services without having to train a custom model.

And practically: the team wanted to be able to ask "what's the weather in KL today?" and "how does Coolest Path's ML model work?" from the same interface, with accurate answers to both.

A fully self-hosted AI chat platform — LibreChat as the UI, Gemma 4 26B as the LLM (running on the GB10 Grace Blackwell in-lab), with a custom strip-shim proxy that automatically routes each query to the right augmentation: RAG over the lab knowledge base (via pgvector), live web search (via Searxng), or straight to the model. No cloud APIs. The same LLM powers a voice avatar (Nova) at avatar.lab.local.

The strip-shim at litellm.vllm.svc:4000 is the most critical custom piece. It sits between LibreChat/avatar-backend and the real LiteLLM proxy, augmenting every request transparently. Processing pipeline per request:

Embedding model: BGE-M3 (1024-dim) via vLLM. Chunk size ~800 chars, 120 char overlap, sentence-boundary aware. Re-ingest after content changes: rebuild rag-memory-files ConfigMap on .7, then delete and re-apply the rag-ingest Job in ns vllm.

LibreChat agents use vLLM's /v1/responses endpoint which does not apply tool-call parsers. Even with --tool-call-parser gemma4 configured, agent tool calls leaked as raw text and LibreChat saw no structured tool_calls — returning empty chat bubbles. The shim bypasses this entirely by working on the regular /v1/chat/completions path where the tool-call parser works, and triggers transparently regardless of which model is active.

Chat interfaces are great at a desk. But for kiosk demos, factory floors, or accessibility scenarios, a keyboard is a barrier. The team wanted a voice-first interface to the lab's AI stack — something a visitor could walk up to, speak to naturally in English or Bahasa Malaysia, and get a spoken answer within two seconds, without touching anything.

Nova — a hands-free voice assistant running entirely on the lab's GB10. Speech is transcribed by Whisper Large v3 (on-device, ~0.5 s), routed through the same Sovereign AI Stack strip-shim (RAG + web search), answered by Gemma 4 26B, and spoken back using Piper TTS for English or Mesolitica's VITS-osman for authentic Bahasa Malaysia. Total round trip: approximately 2 seconds. No cloud, no external APIs, supports four languages.

Nova also has a wake-word mode — when enabled, she only responds if her name is spoken first, making her suitable for ambient/kiosk deployments where background noise would otherwise trigger false activations.

avatar-backend estimates a length hint from the user's text and passes it in the [VOICE MODE] prefix so Gemma 4 calibrates reply length for speech:

Toggle in the header. When ON + hands-free ON, Nova only replies if "Nova" is detected in the Whisper transcript. Regex tolerates known Whisper mis-transcriptions: Nova, Novah, Noah, Knower, Nowa. Unrecognised clips show a 🔇 debug bubble with what was heard. Implemented client-side — STT runs regardless, the chat+TTS calls are conditional.