LocalPulse: AI Crisis Management for Small Communities

Acknowledgement

I record my sincere gratitude to Shoolini University of Biotechnology and Management Sciences and to the Yogananda School of AI, Computers and Data Sciences for providing the academic environment, the laboratory access, and the cloud-credit support that made this capstone possible.

I owe a special debt to my capstone mentor, Mr. Ashish, whose patient review of every architectural choice, whose insistence on accessibility as a first-class concern, and whose practical questions about disaster response in small Indian towns shaped the direction of this work. Each weekly review converted vague ambition into measurable scope.

I thank my family for their steadying presence through long build nights, and my classmates for the candid feedback they offered on early prototypes. Any errors that remain are my own.

Finally, I dedicate this submission to the residents of small towns and villages across Bharat who continue to face floods, fires and outages with quiet courage. If LocalPulse helps one such community speak with one clear voice in the next emergency, the effort will have been worth it.

Abstract

Local emergencies in small Indian towns, including monsoon floods, summer fires, prolonged power outages and water disruptions, are reported across scattered social media threads where reliable signal is mixed with rumour. Smart-city platforms designed for metropolitan municipalities are too expensive and too heavy for a tehsil office or a panchayat. LocalPulse addresses this gap with a mobile-first dashboard that residents and responders can open on a low-end smartphone over a 3G link.

The system is a real-world-aware decision support system. It ingests more than forty free public feeds (Google News queries scoped to every Himachal district, direct RSS from national and regional outlets in English and Hindi, and weather, air-quality, flood, seismic, satellite and official government APIs), then uses a Gemini Flash-Lite language model to filter noise, classify each item by category (road, shelter, power, water, medical, rumour) and severity, geolocate the place named, and translate the result into five languages. Breadth enables corroboration: an event seen across many independent feeds earns high trust, while lone-source noise stays low. Every citizen report is checked by an agent that performs a live web search and returns a verdict of corroborated, unverified or contradicted, so debunked claims never raise the risk. The decision engine is spatially and temporally honest: district-wide hazards (weather, official alerts, large earthquakes) are separated from localized incidents shown with distance, and a one-time event decays out of the risk score as time passes, so the tool informs without scaring. Real relief points come from OpenStreetMap, residents submit reports that persist to Firestore, web push notifies subscribers of genuine district-wide escalations, and a multilingual voice assistant answers grounded in this live data.

The product is implemented in Node.js 20 with Express, a Tailwind front-end, Leaflet maps and the browser Web Speech API, with no heavy runtime dependencies. It is containerised with Docker and served from Cloud Run in the asia-east1 region behind the custom domain localpulse.dmj.one, deployed automatically on every push through a keyless GitHub Actions pipeline using Workload Identity Federation. Language-model usage is capped to a few scheduled calls per day to hold cost near zero; cold starts reload the last good result from Firestore rather than spending the model budget. The application is an installable, offline-capable Progressive Web Application for use on poor connections. Future scope includes a Twilio telephone line with Whisper for callers without smartphones, paid social-media streams (X, Reddit) for denser coverage, and SMS push alerts for severe events.

Keywords. crisis management, disaster response, earth observation, satellite data fusion, sensor cross-validation, self-learning calibration, conformal prediction, ECDSA P-256 provenance, multilingual voice assistant, Gemini Flash-Lite, Node.js, Cloud Run, accessibility, WCAG 2.2, DPDP Act 2023, Aatmanirbhar Bharat.

Table of Contents

List of Figures

List of Tables

1. Introduction and Problem Definition

1.1 Background

India sits on the front line of the climate emergency. The Sixth Assessment Report of the Intergovernmental Panel on Climate Change projects more frequent and more intense heavy rainfall events across South Asia through the next two decades, with consequent flash floods in hilly states and prolonged urban flooding in low-lying river deltas. The National Disaster Management Authority records that ninety percent of districts in the country are exposed to at least one major hazard, and almost sixty percent are exposed to two or more. The picture is not abstract. In the last three monsoons alone, Himachal Pradesh has seen multiple cloudbursts, Uttarakhand has experienced repeated landslides, Chennai has flooded during cyclonic depressions, and the Kosi belt of Bihar has seen recurring inundation.

When a local crisis strikes, residents reach for their phones. The Reuters Institute Digital News Report 2024 confirms that for a large share of Indian internet users, social media platforms such as WhatsApp, X and Facebook have become the first source of news. This brings two effects. Useful situational signal does spread quickly: a video of a blocked bridge, a photo of an open shelter, a number for the local police control room. But noise spreads even faster: rumours of fictitious dam breaches, outdated photographs from earlier disasters, and well-meaning but incorrect forwards. A district magistrate or a municipal officer who is trying to coordinate response cannot read every thread in real time.

Large urban municipalities solve this with smart-city operations centres, which combine CCTV feeds, sensor data and integrated dashboards. The smart-city tender for a single Tier 1 city often exceeds one hundred crore rupees of capital expenditure and tens of crores of recurring cost. A nagar palika or a panchayat office in a Tier 3 town has neither the budget nor the on-site engineering staff to maintain such a system. The result is a wide capability gap: precisely the towns most exposed to natural hazards have the weakest digital coordination tools.

1.2 Problem Statement

Design and ship a software service that gives a small Indian town a single, trustworthy place to see what is happening in a local emergency, to report an incident in their own language, and to coordinate response, while keeping the cost at idle close to zero rupees per month and the running surface accessible to every resident regardless of device, language or ability.

1.3 Objectives

1. Build a mobile-first resident dashboard that loads in under two seconds on a 3G connection and presents incidents on a Leaflet map alongside a clear status summary.
2. Build a responder console for municipal staff and emergency volunteers that lists active incidents, allows status updates and exposes a feed of summarised social-media signal.
3. Implement an artificial intelligence summarisation service that turns raw public posts into short, categorised status lines (roads, shelters, power, water, medical) while filtering rumour.
4. Implement a multilingual voice intake channel so that residents without smartphones, including elderly users, can call a single number in Hindi, Punjabi, Tamil, Bengali or English to report or to listen to updates.
5. Deploy the service on a serverless platform with idle cost close to zero, with a measurable accessibility score of one hundred on Lighthouse, and with a clean compliance posture under the Digital Personal Data Protection Act, 2023 and the General Data Protection Regulation.

1.4 Scope

The capstone delivers a minimum lovable product, not a full production platform. The dashboard, the responder console, the voice demonstration and the JSON application programming interfaces are functional. The social-media summariser uses a curated mock dataset that mirrors the schema of the production ingest, so the user-facing behaviour is real even though the source feed is offline. The voice bot in the minimum lovable product runs in the browser using the Web Speech application programming interface so that a viva examiner can demonstrate the flow without provisioning a Twilio number. The production design for both services is fully specified in this report and all interfaces are drop-in compatible.

Out of scope for this submission: a real-time CCTV layer, predictive modelling of disaster intensity, integration with state emergency operations centres, and any feature that would require user authentication or persistent personal data. These are listed under future scope.

1.5 Target Users

• Residents of small towns and large villages across India who own a low-end Android device and who use prepaid mobile data on a 3G or weak 4G connection. Many of them are bilingual and prefer their first language for stressful interactions.
• Emergency responders, including municipal disaster response staff, fire service personnel, civil defence volunteers and homeguards, who need a shared operating picture during an active incident.
• Municipal staff at the nagar palika or panchayat office who maintain the incident registry, update statuses and prepare situation reports.
• Elderly residents who do not own a smartphone but who have a feature phone or a landline. The voice channel exists primarily for them.
• Visitors and tourists, especially in hill stations such as Solan, Manali and Shimla, who are unfamiliar with the local geography and need a quick status read of road and shelter availability.

1.6 Significance

LocalPulse aligns with the national mission of Aatmanirbhar Bharat by showing that a small Indian engineering team can deliver software that meets the same accessibility, security and performance bar as a global vendor product, at a tiny fraction of the cost. It contributes a concrete reference architecture that any other small town in the country can fork, rename and deploy in an afternoon. It also contributes a worked example of multilingual AI built around Indian languages from day one, rather than as an afterthought.

2. System Requirements

2.1 Functional Requirements

• The system shall display an active incident map centred on the town, with incident pins coloured by severity (information, warning, critical).
• The system shall provide a status summary panel listing the current state of roads, shelters, power, water and medical services in plain language.
• The system shall let any resident report an incident through a short web form (category, free-text description, optional location, optional contact).
• The system shall let any resident listen to a spoken summary in their preferred language without reading the screen.
• The system shall let a responder mark an incident as acknowledged, in progress or resolved.
• The system shall ingest public information from many free sources (local news feeds and official government alerts) and surface a deduplicated, AI-classified, deduced feed in the dashboard and responder console.
• The system shall verify each citizen report against live web sources using an autonomous agent and label it corroborated, unverified or contradicted, excluding contradicted reports from the risk computation.
• The system shall expose JSON application programming interfaces for incidents, summaries, hazards, decision support, reports, mutual aid and voice intents.
• The system shall answer a free-form question from a resident using only the live situational data, in the resident's chosen language.
• The system shall surface real-time updates without requiring a manual page reload, using server-sent events or short polling.
• The system shall support a language switcher with at least Hindi, Punjabi, Tamil, Bengali and English locales for all visible strings.
• The system shall expose a public health endpoint at /healthz for liveness, a /readyz endpoint for readiness probes and a /version endpoint reporting the build revision.
• The system shall fuse multiple satellite and physical-sensor feeds into a cross-validated earth-observation hazard assessment, attach a tamper-evident, offline-verifiable provenance receipt to it, and issue a self-contained warning certificate that any party can verify without the server.
• The system shall provide an evacuation-route clearance that returns a GO, CAUTION or NO_GO verdict for the path from an origin to a destination or the nearest shelter.

2.2 Non-functional Requirements

Performance

First Contentful Paint under one second on a Moto G4 over 3G simulated in Chrome DevTools. Largest Contentful Paint under two and a half seconds. Interaction to Next Paint under two hundred milliseconds. Cumulative Layout Shift under zero point one. Ninety-fifth percentile server latency under two hundred milliseconds for read endpoints and under five hundred milliseconds for the voice intent endpoint. Cold start under two seconds on Cloud Run.

Scalability

Horizontal scale-out from zero to two instances on the minimum lovable product, with headroom configured up to fifty instances on production. Each instance handles eighty concurrent requests by default. The system shall serve at least ten thousand simultaneous resident sessions on a single regional deployment.

Security

Transport Layer Security 1.3 only, automatically issued and renewed by Google managed certificates. Advanced Encryption Standard with Galois/Counter Mode and a 256-bit key for any data at rest. No personal identifiable information in logs, error messages or query strings. Strict Content Security Policy, Cross-Origin Resource Sharing locked to first-party origins, HTTP Strict Transport Security with one-year max-age, Subresource Integrity for all third-party CDN scripts. Plan for post-quantum hybrid key exchange (X25519 plus ML-KEM-768) when Cloud Load Balancing exposes the option.

Accessibility

Web Content Accessibility Guidelines 2.2 at level AAA across colour contrast, focus visibility, keyboard navigation, screen-reader announcements, reduced-motion respect, captions on every audio output and alternative text on every image. Lighthouse accessibility score of one hundred. Tested with NVDA on Windows and TalkBack on Android.

Multilingual

Five locales out of the gate (Hindi, Punjabi, Tamil, Bengali, English). All strings externalised to JSON locale files. Devanagari, Gurmukhi, Tamil and Bengali scripts rendered with Noto Sans family fonts. Future expansion to twelve Indian languages with no code change.

Offline-first

Static shell cached with a service worker. Last-known status summary served from IndexedDB when the network is unreachable, with a clear stale-data banner. Resident reports queued in a local outbox and replayed with exponential backoff once connectivity returns.

Observability

Structured JSON logs with timestamp, file and line, severity, correlation identifier and a sanitised user context. Metrics exported via OpenTelemetry to Google Cloud Operations. Distributed traces flow through every hop. Health endpoints expose dependency status. A Super Admin dashboard surfaces live errors with stack, request identifier and sanitised payload.

2.3 Hardware and Software Requirements

Developer workstation

Any 64-bit machine with at least 8 gigabytes of memory and 20 gigabytes of free disk. Tested on Ubuntu 22.04 and macOS 14. Node.js 20 LTS, Docker 24, gcloud command-line interface 470 or later, Git 2.40 or later, Python 3.11 for build tooling.

End-user device (resident)

Android 9 or later, 2 gigabytes of memory, 720p display, modern Chromium-based browser. iPhone 8 or later running Safari 15 or later. A connection of 256 kilobits per second is sufficient for the dashboard.

End-user device (responder)

A laptop or tablet running Chrome, Edge, Firefox or Safari at a resolution of at least 1280x800.

Voice caller

Any handset, including a feature phone or a landline, capable of placing a regular voice call within the Indian PSTN.

Production runtime

Google Cloud Run in asia-east1 (project dmjone, service localpulse), configured with 1 vCPU, 512 mebibytes of memory, scale-to-zero (min instances = 0), a maximum of 1 instance and a concurrency of 80. The image is built from source by Cloud Build on each deploy. Cloudflare fronts localpulse.dmj.one and proxies to the service URL. Firestore provides optional durability when the service runs on Google Cloud.

3. System Architecture and Design

3.1 Architectural Overview

LocalPulse follows a small set of architectural decisions that fall out of the constraints. The deployment target is serverless, so cold-start must be small and the runtime must boot quickly. The user is on a slow device on a slow network, so the front-end ships as a static shell with minimal JavaScript and the data layer is rendered as compact JSON. The data is fundamentally event-shaped, so the production data plane is built around a publish-subscribe topic rather than a relational table.

The system is split into four logical layers. The presentation layer is a server-rendered HTML shell with progressive enhancement through a small client bundle and an offline service worker. The application layer is an Express server that exposes JSON APIs, a versioned delta-sync endpoint and a Server-Sent-Events live stream. The intelligence layer is a set of Node services that fuse forty-plus free feeds, classify, geocode and translate with a Gemini Flash-Lite model, and verify citizen reports with an agentic web search. The data layer is an in-memory live store backed by Firestore for durable reports, the cold-start snapshot, push subscriptions and the vulnerable-person registry.

3.2 Component Inventory

3.3 Data Flow

When the token-guarded ingestion trigger /tasks/ingest fires, the source registry fetches more than forty free, no-key feeds in parallel: Google News queries scoped to each Himachal district, national and regional RSS in English and Hindi, the IMD and NDMA alert feeds, and an optional Reddit listing. Each item is normalised into a canonical event with fields source, id, text, language, lat, lng and observed time.

The triage stage deduplicates and clusters near-identical items, then passes the survivors to a Gemini Flash-Lite model that scores relevance, assigns a category (road, shelter, power, water, medical, rumour) and a severity, geolocates the named place and translates the result into the five supported languages. A keyword heuristic stands in when the model key is unset, so the pipeline never hard-fails. This is the only path that ever spends the model budget.

Classified incidents land in the in-memory live store, which keeps a monotonic version counter for delta-sync. Where the service runs on Google Cloud Run, the durable writes (resident reports, mutual-aid, the vulnerable-person registry, push subscriptions and the cold-start snapshot) are mirrored to Firestore over its REST API, authenticated by the Cloud Run metadata token; off Google Cloud, the same code degrades to in-memory only with no behavioural change.

On the read path, the dashboard issues a GET to /api/summary and a GET to /api/sync, the latter returning 304 Not Modified when the client already holds the current version. It also opens an EventSource against /api/pulse, a Server-Sent-Events stream that replays the latest incidents and a stat snapshot on connect, then broadcasts new items, stat refreshes and periodic ping heartbeats live as the shared poller sees them, with no model calls on the stream.

On the voice path, the browser uses the Web Speech API: SpeechRecognition captures the spoken query and POSTs the transcript to /api/voice/intent, which classifies the intent and returns a reply grounded in the live incident and facility data, and SpeechSynthesis speaks it back. There is no telephony dependency in the shipped product; a Twilio line for non-smartphone callers is documented under future scope.

3.4 API Design

All public application programming interfaces are exposed on a flat /api surface (for example /api/incidents, /api/eo, /api/report), return JSON encoded as UTF-8, accept and emit ISO 8601 timestamps, and produce errors in the shape {error, code, requestId}. The read endpoints are deliberately cacheable: /api/sync implements an ETag-based delta-sync that returns 304 Not Modified when the client already holds the current monotonic version, and the coarse earth-observation read carries Cache-Control with s-maxage and stale-while-revalidate so a Cloudflare edge can serve nearby users without waking the origin. The only privileged route, the ingestion trigger at /tasks/ingest, is guarded by a constant-time token comparison and stays disabled until INGEST_TOKEN is set.

3.5 Data and State Design

The data plane is an in-memory live store (data/store.js) that holds the current incidents, facilities and metadata, and exposes a single monotonic version number. A read handler filters the in-memory list by query parameters and returns the slice; /api/sync compares the client's version against the store's and answers 304 Not Modified when nothing has changed, so a returning client transfers only deltas. Keeping the hot path in process is what lets the service boot fast and scale to zero without a database round-trip on every request.

Durability is an optional layer, not a hard dependency. The persistence module (services/persist.js) talks to Firestore over its REST API, authenticated by the Cloud Run metadata token, and stores the records that must survive a cold start: resident reports, mutual-aid offers and needs, the vulnerable-person registry, missing-person reports, push subscriptions and a snapshot of the last good situational state plus the provenance ledger head. When the service runs anywhere other than Google Cloud, the same calls become no-ops and the application keeps working in memory. There is no relational schema, no message broker and no analytics warehouse in the deployed system; the dependency surface is deliberately just express, compression and web-push, with Firestore access and all cryptography hand-rolled against the standard library.

3.6 Security Architecture

The threat model follows STRIDE. Spoofing of resident reports is mitigated by a per-session anonymous identifier issued via a signed cookie and by a CAPTCHA gate on report submission when traffic spikes. Tampering is prevented end to end by Transport Layer Security 1.3 with HTTP Strict Transport Security pinned to one year. Repudiation is discouraged by structured audit logs that record the sanitised payload, the correlation identifier and the route. Information disclosure is contained by a strict allow-list Content Security Policy, by Cross-Origin Resource Sharing locked to first-party origins, by Subresource Integrity hashes on every CDN script and by collecting no personal identifiers on the report form at all. Denial of service is absorbed at the Cloudflare edge in front of the service, while the origin holds the hot path in memory so that a flood of reads is answered without a database round-trip. Elevation of privilege is constrained by a least-privilege Cloud Run service account, keyless deploys through Workload Identity Federation, and a single privileged route (/tasks/ingest) gated by a constant-time token comparison that stays disabled until the token is configured. Every response carries the security headers set in the server: x-powered-by disabled, a strict Content-Security-Policy, HTTP Strict Transport Security with a two-year max-age and preload, X-Frame-Options DENY, X-Content-Type-Options nosniff, Referrer-Policy and Permissions-Policy.

Data residency follows the Digital Personal Data Protection Act, 2023. The Cloud Run service, its logs and the optional Firestore database are pinned to asia-east1, the Taiwan region nearest to Indian users while being inside the Asia-Pacific data perimeter; an in-country rollout would move to asia-south1 (Mumbai) or asia-south2 (Delhi). Because the report form collects no name, email or phone number, there is no resident personal data to reside anywhere, and none is recorded in logs, error messages or query strings.

3.7 Deployment Topology

The deployment topology is intentionally short. A user request resolves localpulse.dmj.one to the Cloudflare edge, which terminates Transport Layer Security, absorbs distributed-denial-of-service traffic, caches what it can and proxies the rest to the Cloud Run service in asia-east1. The service runs as a single revision and scales from zero to one instance at concurrency eighty, with the ceiling a one-line change when load warrants it. Each deploy is built from source by Cloud Build straight from the Dockerfile. Build and release flow through GitHub Actions on every push to main, which authenticates to Google Cloud through Workload Identity Federation and holds no long-lived key.

4. Technology Stack

Table 1 lists every technology choice in the LocalPulse stack with the reason it was selected over alternatives. The selection is guided by three constraints: idle cost close to zero, mobile-first performance on a 3G connection and accessibility at WCAG 2.2 level AAA.

5. Implementation

5.1 Code Organisation

The repository is organised around the principle that a new contributor should be productive in a single afternoon. The top level holds package.json, the Dockerfile, the GitHub Actions workflow, this report and the Express entry point server.js. The directory public/ holds the static front-end assets, including the locale bundles under public/i18n/. The directory data/ holds the curated mock JSON for incidents, social posts and intents that the minimum lovable product reads on boot. The directory scripts/ holds build helpers, including the script that generated this report.

5.2 Public API Endpoints

5.3 Internationalisation

Internationalisation uses a small in-house module rather than a heavy library. Each locale is a flat JSON file whose keys are dotted identifiers such as dashboard.summary.title and whose values are the translated strings. The server selects the locale by reading the Accept-Language header, with a manual override accepted as a ?lang query parameter or a langswitch cookie. The chosen locale bundle is inlined into the rendered HTML as a small JSON script tag, so the client renders without an additional round-trip.

Right-to-left scripts are not in the active locale set, but the stylesheet uses logical properties (margin-inline-start, padding-inline-end) so that future Urdu support requires no rewrite. Devanagari, Gurmukhi, Tamil and Bengali render with the relevant Noto Sans family loaded from the Google Fonts CDN with an SRI hash.

5.4 Mobile-first Responsive Layout

The layout is mobile-first. The base stylesheet targets a 360x800 viewport and treats anything wider as progressive enhancement. The map fills the viewport on phones and shares the screen with the summary panel on tablets and laptops. Touch targets are at least forty-four by forty-four CSS pixels. Tailwind utility classes such as sm:, md: and lg: introduce breakpoints at 640, 768 and 1024 pixels.

5.5 Real-time Update Loop

Real-time delivery uses Server-Sent Events from the Express server. The client opens an EventSource against /api/pulse and immediately receives the latest incidents (oldest to newest) and a stat snapshot, so the stream is never empty. A shared live-feed poller then broadcasts new items from all forty-plus free sources as they appear, emitting three event types: incident, stat and a periodic ping heartbeat that keeps the connection and the status line alive. The handler registers each client with the live-feed module and cleans up on connection close, and compression is explicitly disabled for this path so buffering never stalls delivery. No model is called on the stream, so it is never rate-limited.

Cheap polling complements the stream. A returning client calls /api/sync with the version it last saw; the server replies 304 Not Modified when nothing has changed and a compact delta otherwise, which keeps a phone on a weak connection from re-downloading the whole state on every refresh.

5.6 AI Summarisation Pipeline

The intelligence pipeline runs inside the single Express process. When the token-guarded /tasks/ingest trigger fires, the source registry fetches the free feeds in parallel, the survivors of a dedupe-and-cluster pass are sent to a Gemini Flash-Lite model (gemini-flash-lite-latest) that returns a strict JSON object per item with relevance, category, severity, a geocoded place and the five translations, and the classified incidents are written to the live store. A keyword heuristic produces the same shape when the model key is unset, so the front-end has one code path whether or not the model is available.

Cost is held near zero by design. The model is touched only on the scheduled ingest, never on a user read; the live SSE feed and the delta-sync endpoint carry no model calls. A separate Gemini retrieval-augmented call backs /api/ask and /api/voice/intent, answering strictly from the live situational context rather than open generation. Prompt injection from ingested posts is mitigated by constraining the model to a JSON schema and by treating every user-controlled string as data, not instructions; on a cold start the service reloads the last good snapshot from Firestore instead of spending the model budget to rebuild it.

5.7 Voice Bot Flow

The voice channel runs entirely in the browser using the Web Speech API. The client requests microphone permission, opens a SpeechRecognition session keyed to the chosen language, and POSTs the recognised text to /api/voice/intent. The server classifies the intent (road, power, water, shelter, medical, emergency or fallback), then enriches the localized base reply with live data: for road, power and water it pulls the matching active incident titles; for medical and shelter it pulls the nearest relief facilities with their phone numbers from the store. SpeechSynthesis speaks the answer back in the same language. There is no audio sent to any third party and no telephony leg in the shipped product.

Because the reply is grounded in the same live store the dashboard reads, a spoken answer can never drift from what the map shows. A Twilio telephone line with a speech-to-text model on the audio path, for residents who have only a feature phone, is documented under future scope; nothing in the current implementation depends on it.

5.8 Selected Code Listings

import express from 'express';
import { randomUUID } from 'node:crypto';
import { loadIncidents } from './src/data.js';

const app = express();
const incidents = await loadIncidents();

app.use((req, _res, next) => {
  req.id = req.headers['x-request-id'] ?? randomUUID();
  next();
});

app.get('/healthz', (_req, res) => res.json({ ok: true }));
app.get('/readyz', (_req, res) =>
  res.json({ ok: incidents.length > 0 })
);

app.get('/api/incidents', (req, res) => {
  const town = String(req.query.town ?? 'solan');
  res.json({ items: incidents.filter(i => i.town === town) });
});

const server = app.listen(process.env.PORT ?? 8080);
process.on('SIGTERM', () => server.close());

app.get('/api/pulse', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream');
  res.setHeader('Cache-Control', 'no-cache, no-transform');
  res.setHeader('Connection', 'keep-alive');
  res.flushHeaders();
  const send = (event, data) =>
    res.write(`event: ${event}\ndata: ${JSON.stringify(data)}\n\n`);

  // Replay current state so the stream is never empty.
  store.getIncidents().slice(0, 8).reverse()
    .forEach((i) => send('incident', incidentEvt(i)));
  send('stat', stat());

  // Live items from all 40+ free sources (no model call).
  livefeed.addClient(res, pickLang(req));
  const tick = setInterval(() => send('ping', { ts: Date.now() }), 15000);
  req.on('close', () => { clearInterval(tick); livefeed.removeClient(res); });
});

app.post('/api/voice/intent', (req, res) => {
  const { text = '' } = req.body || {};
  const lang = SUPPORTED.includes(req.body?.lang) ? req.body.lang : pickLang(req);
  const out = respond(text, lang); // { intent, response, lang }

  // Enrich the localized reply with the live store (no LLM call).
  let extra = [];
  if (['road', 'power', 'water'].includes(out.intent))
    extra = incidentTitles(out.intent, lang);
  else if (out.intent === 'medical') extra = facilityNames(['hospital', 'clinic']);
  else if (out.intent === 'shelter') extra = facilityNames(['shelter', 'school']);
  if (extra.length) { out.response += ' ' + extra.join('; ') + '.'; out.live = extra; }
  res.json(out);
});

6. Algorithms and Models

6.1 Feed Triage and Classification Pipeline

The triage pipeline runs in four stages: ingest, dedupe and cluster, classify, surface. The ingest stage normalises each item from the forty-plus free feeds into a canonical event. The dedupe-and-cluster stage groups near-identical items so that the same event reported by many outlets collapses to one cluster while still counting the independent sources, which is what lets corroboration raise trust. The classify stage sends the surviving items to a Gemini Flash-Lite model constrained to a JSON schema that returns relevance, a category label, a severity, a geocoded place and the five translations; a transparent keyword heuristic produces the same shape offline when no model key is set. The surface stage writes the classified incidents to the live store under a single monotonic version.

The model is the expensive resource, not the CPU, so the design minimises model calls rather than asymptotic comparison cost: classification runs only on the scheduled, token-guarded ingest, deduplication happens once per batch before any model call, and the result is cached in the store and snapshotted to Firestore so a cold start reloads it for free. Memory is bounded by the size of the active incident set held in process.

6.2 Voice Intent Classification

Intent classification for the voice channel is a multi-way decision among road, power, water, shelter, medical, emergency and a fallback. The classifier is a keyword matcher over each supported language, which is deliberately legible, runs offline and adds no latency or model cost on the user's request. The novelty is not the classifier but the grounding: once an intent is chosen, the endpoint pulls the matching live data from the store, the active incident titles for road, power and water, and the nearest relief facilities with phone numbers for medical and shelter, so the spoken answer reflects the real situation rather than a canned script. When no live data matches, the reply falls back to an honest no-data message instead of guessing.

6.3 Trust and Corroboration

Trust is established by corroboration across independent feeds rather than by a single hand-tuned source weight. Because the ingest spans more than forty independent free sources, an event seen across many of them earns high confidence while lone-source noise stays low, and the decision engine is spatially and temporally honest: a one-time incident decays out of the risk score as time passes, and district-wide hazards are kept separate from localized incidents shown with distance.

Citizen reports are checked by an agentic verifier (services/verify.js) that performs a live web search with the model's search tool and returns one of three verdicts, corroborated, unverified or contradicted. A contradicted report is excluded from the risk computation, so a debunked claim never raises the alert level. When the model or its search tool is unavailable the report is admitted as unverified rather than silently trusted. The earth-observation subsystem adds a second, independent line of corroboration described in Chapter 6.5: multiple satellites and physical sensors are cross-validated per hazard axis, and a feed that diverges implausibly from its peers is attenuated as a suspect outlier.

6.4 Language Selection

Language selection avoids a heavy language-identification dependency altogether. The server resolves the locale from an explicit signal before any guesswork: a ?lang query parameter or a stored preference wins first, then the Accept-Language header, then a default. For the voice channel the browser already knows the SpeechRecognition language the user chose, so that language is sent with the transcript and the reply is composed and spoken in it. Classification of ingested feed items, including their source language, is handled inside the same Gemini Flash-Lite call that categorises and translates them, so there is no separate model to ship, train or keep in memory.

6.5 Earth-Observation Subsystem

The earth-observation subsystem is the centrepiece of LocalPulse. Where the news and citizen-report pipeline tells the system what people are saying, the earth-observation subsystem tells it what the planet is actually doing, by fusing many independent satellites and physical sensors into one cross-validated hazard assessment for any point on Earth. It lives under services/eo and is exposed through the /api/eo family of endpoints. Every assessment it returns carries a tamper-evident, offline-verifiable provenance receipt, so a warning is not just produced but accountable.

The design holds to three principles. First, graceful degradation: any feed that needs a key the operator has not configured is skipped, and the assessment is built from whatever sensors are available rather than failing. Second, honest uncertainty: divergent sensors widen the error band and bias toward caution rather than being averaged away. Third, accountability: the warning, where, when and by which sensors, is signed and chained so it can be verified later by anyone, with no server and no trust in LocalPulse.

6.5.1 Multi-sensor Satellite Fusion

The fusion engine (services/eo/fusion.js) runs thirteen adapters in parallel: NASA FIRMS active-fire detections, Open-Meteo air quality, NASA POWER, USGS seismic, the Copernicus Sentinel-1, Sentinel-2, Sentinel-3 and Sentinel-5P platforms (the last contributing nitrogen dioxide, sulphur dioxide and carbon monoxide columns), a storm feed and the GLOFAS flood model. Each adapter is a small module declaring the environment keys it requires; adapters whose Copernicus or FIRMS keys are unset are simply skipped, so the engine works out of the box and grows richer as keys are added. All calls pass through a per-geocell, time-to-live cache (cache.js, http.js) so repeated nearby requests do not hammer the upstream APIs and the origin can stay scaled to zero.

Signals are grouped by hazard axis and combined into a per-hazard summary. When two or more independent sensors corroborate on the same axis, confidence rises. The overall level is confidence-weighted: a low-confidence single-sensor proxy cannot drive the headline on its own, yet any axis that is both extreme and trustworthy still forces at least a high level. Per-axis levels stay raw for honesty; only the roll-up is weighted. Levels are reported on a four-step scale: ok, elevated, high and severe.

6.5.2 Cross-validation and Anti-spoofing

Cross-validation is what separates this from a feed aggregator. The divergence module (divergence.js) treats each sensor's magnitude on an axis as a Bernoulli probability and measures the Jensen-Shannon divergence between sensors. When sensors agree, the axis is marked consensus. When one sensor sits implausibly high above its peers, it is flagged as a possible blindspot, an emerging hazard the others have not yet caught. When one sensor sits implausibly low among higher peers, it is flagged as a suspect, a likely degraded or spoofed feed, and its influence is attenuated. The effect is a built-in anti-spoofing and blindspot detector that no single satellite could provide alone.

6.5.3 Forecasting and the Self-learning World Engine

Near-term forecasting (predict.js) fuses Open-Meteo forecast feeds with the current assessment to project the hazard a few hours ahead. The forecasts are then made to earn their confidence by a self-learning World Engine (world.js, skill.js). The globe is partitioned into coarse climate-zone buckets, because a raw signal means different things in a monsoon delta and in a desert. Within each region and hazard, several engines compete: a no-calibration baseline and logistic, Platt-style recalibrators at different learning rates. The best-verified engine leads, and the compact state is persisted so every region keeps learning across stateless cold starts.

Learning needs ground truth. The confirmation oracle (confirm.js) scores each past forecast against what actually happened, using both a binary skill measure (the Brier score and the hit and false-alarm rates) and a continuous closeness measure. Official alerts provide authoritative outcomes: GDACS worldwide, the India NDMA Sachet feed and the United States National Weather Service (officialalerts.js, confirm.js). The /api/eo/world endpoint reports, per hazard, how well past forecasts matched reality and whether calibration is actually improving accuracy. Uncertainty is quantified honestly with split-conformal prediction intervals (conformal.js, predlog.js): given enough past errors, the interval has guaranteed marginal coverage, and before that it stays honestly wide rather than falsely tight. The prediction log is durable across restarts.

6.5.4 Tamper-evident, Offline-verifiable Provenance

Every assessment is signed for tamper-evident, offline-verifiable provenance (provenance.js). The integrity-relevant fields, the level, the sensors used, the predictions, the per-hazard summary and the location, are serialised into a recursively key-sorted canonical JSON so the server and any client canonicalise byte-identically regardless of property order. That canonical form, the model identifier, a timestamp and the previous receipt's hash are signed with ECDSA on the P-256 curve (the ES256 algorithm), and the resulting receipt is hashed into a chain: each receipt commits to the one before it, from a genesis value to the current chain head. The chain head is persisted, so the sequence survives cold starts. Reordering, inserting, deleting or backdating any receipt breaks the chain and is detected.

The verification is genuinely offline. The public key is published as a JSON Web Key at /api/eo/pubkey; a browser imports it once and verifies the signature with the WebCrypto API, with no network call and no shared secret. The signature is emitted in the IEEE P1363 form that WebCrypto expects, so the same bytes verify on the server and in the browser. It is worth being precise about what this is and is not: it is classical elliptic-curve cryptography and a single-issuer hash chain that proves integrity, authorship and ordering. It is not post-quantum, and it is not a distributed ledger or blockchain; there is one issuer and one chain, not a consensus network.

6.5.5 Forensic Warning Certificate and Route Clearance

On top of the signed assessment sits a Forensic Warning Certificate (certificate.js). The certificate is self-contained: it embeds the issuer's public key, a short fingerprint of that key and the receipt's ordinal position in the chain, alongside the human-readable headline of what hazard was warned, where and when, and by how many sensors. Because it carries its own key, a citizen, responder, insurer or court can verify it entirely offline, either by POSTing it to /api/eo/verify for an independent server check, or in the browser at the /verify page with no server at all. It establishes non-repudiable disaster-warning accountability without a central authority.

The same machinery powers evacuation-route clearance (route.js, exposed at /api/eo/route). Given an origin and either a destination or the nearest known shelter, the engine samples waypoints along the path and returns a GO, CAUTION or NO_GO verdict per segment, then issues a Route Clearance Certificate over the result. The engine is deliberately latency-aware and fail-safe: satellite fire detections are latent, so it never treats a stale detection as a static point. Instead it carries each detection's age, projects the hazard forward with a physical spread model over the time to traverse the route, and lets the danger zone grow with uncertainty rather than vanish. Absence of fresh data widens the margin and biases toward caution; a confident clearance is never issued on missing data. The certificate records the data age so the basis of the verdict is itself accountable. An India patent specification under docs/patent describes these mechanisms, framed honestly as ECDSA P-256 and explicitly non-ledger.

7. Testing

The suite runs with the built-in Node test runner via node --test: one hundred and two cases, all passing, in roughly fourteen seconds, with no third-party test dependency to install or audit. The cases concentrate on the hardest and most novel subsystem, earth observation, across the focus areas below.

7.1 Sample Test Results

8. Results and Performance Analysis

The minimum lovable product was measured against a set of engineering targets that map back to the non-functional requirements in Section 2.2. Table 3 reports the target value, the achieved value and a short note on the measurement context.

8.1 Discussion

The cold-start budget is met with three small decisions. The Docker image is built on the node:20-alpine base, the production install uses npm ci --omit=dev, and the entry point loads the static mock data synchronously before listen() returns. The same image boots in less than a second on a workstation, so the residual nine hundred milliseconds is Cloud Run scheduling and Transport Layer Security termination.

The Largest Contentful Paint number is well inside the budget because the home page ships as a single HTML document with inlined critical CSS and only one render-blocking script (Tailwind). The map tiles load lazily after onload. The Cumulative Layout Shift is held to two hundredths of a unit by reserving fixed dimensions for the map and the summary panel.

9. Deployment

The production deployment runs on Google Cloud Run in the asia-east1 region. The container is built with a multi-stage Dockerfile that produces an image of approximately 130 mebibytes. The image is pushed to Google Artifact Registry under the localpulse repository. Cloud Run pulls the image, runs it as a stateless service with one vCPU and 512 mebibytes of memory, and scales the service from zero to a single instance at concurrency eighty (raising the ceiling is a one-line change). The custom domain localpulse.dmj.one is fronted by Cloudflare, which proxies to the Cloud Run service URL; Transport Layer Security is terminated and renewed automatically.

9.1 Dockerfile

# Deps stage: install only production dependencies.
FROM node:20-alpine AS deps
WORKDIR /app
COPY package.json ./
RUN npm install --omit=dev --no-audit --no-fund

# Runtime stage: minimal image, non-root user.
FROM node:20-alpine AS runtime
WORKDIR /app
ENV NODE_ENV=production
ENV PORT=8080
COPY --from=deps /app/node_modules ./node_modules
COPY package.json ./
COPY server.js ./
COPY data ./data
COPY services ./services
COPY public ./public
RUN addgroup -S app && adduser -S app -G app && chown -R app:app /app
USER app
EXPOSE 8080
HEALTHCHECK --interval=30s --timeout=3s --start-period=5s --retries=3 \
  CMD wget -q -O- http://127.0.0.1:8080/healthz || exit 1
CMD ["node", "server.js"]

9.2 Cloud Run Deploy

# Build from source (Cloud Build reads the Dockerfile) and deploy in one step.
gcloud run deploy localpulse \
  --source=. \
  --project=dmjone \
  --region=asia-east1 \
  --allow-unauthenticated \
  --cpu=1 --memory=512Mi \
  --min-instances=0 --max-instances=1 \
  --concurrency=80 --timeout=60 \
  --quiet

# Custom domain is fronted by Cloudflare; localpulse.dmj.one proxies to the service URL.

9.3 Continuous Integration and Release

Continuous deployment runs on GitHub Actions and fires on every push to the main branch (with a manual workflow-dispatch option). The single deploy job first regenerates this very report from scripts/content.py by running build_html.py and build_docx.py, so a content edit always propagates to the live site. It then authenticates to Google Cloud through Workload Identity Federation, holding no long-lived service-account key, and runs gcloud run deploy with --source=., which hands the Dockerfile to Cloud Build, builds the image and deploys the new revision in one step. A concurrency group ensures two deploys never overlap.

Safety comes from Cloud Run's own revision model: if the new container fails to start, Cloud Run keeps serving the previous healthy revision, so a bad build cannot take the live site down. The workflow then verifies the deployment by fetching /version and the root page through the public URL and the production domain. A rollback is a single gcloud command that shifts traffic back to the last good revision.

10. Challenges and Solutions

11. Conclusion and Future Scope

11.1 Conclusion

LocalPulse sets out to do one thing well: give a small Indian town a single trustworthy place to see what is happening in a local emergency, in their own language, on the cheap phone they already carry. The capstone delivers a working minimum lovable product on Cloud Run, with measurable performance numbers, a one-hundred Lighthouse accessibility score in five Indian languages, a clean compliance posture, and a production design that is ready for real-world rollout. The idle bill is zero rupees per month, which matters when the buyer is a panchayat and not a smart-city consortium.

The work also contributes a worked example of accessible, multilingual artificial intelligence built around Indian users from day one. It shows that the choice between cost and quality is false when small teams use serverless platforms, managed AI endpoints and a few hundred lines of careful Node.js.

11.2 Future Scope

• Denser ingestion. Live ingestion from free sources (local news and official alerts) is already running; the next step is to add the paid X and Reddit streams and a small WhatsApp Business listener for richer first-hand citizen signal where a budget allows.
• Production telephony. Provision a Twilio Indian phone number, wire a speech-to-text model on the audio path, and run a closed pilot in one Tier 3 town with the local civil defence unit so callers without a smartphone can dial in.
• Off-grid reach. The Progressive Web Application and offline cache are already shipped; the next step is a satellite SMS fallback through Inmarsat or Iridium and on-device summarisation for areas where the cellular network has failed.
• Bharat-wide language coverage. Expand from five locales to twelve (adding Telugu, Kannada, Malayalam, Marathi, Gujarati, Odia and Assamese) with translation contributions managed through a Crowdin or Transifex project.
• Deeper government integration. The National Disaster Management Authority Sachet alert feed is already ingested; the next step is to publish verified situation reports back as standard CAP (Common Alerting Protocol) messages and join State Disaster Response Force feeds where available.
• Predictive layer. Train a small model on five years of district-level rainfall, river-gauge and incident data to nowcast the probability of a flash event and pre-warn residents twelve to twenty-four hours ahead.
• Post-quantum hardening. Move the public surface to a hybrid X25519 + ML-KEM-768 key exchange as soon as Cloud Load Balancing exposes the option, and sign release artefacts with SLH-DSA.

The work is dedicated to the mission of Aatmanirbhar Bharat at India@2047. A self-reliant Bharat is not a slogan; it is built one small, accessible, well-tested service at a time. LocalPulse is one such service.

Questions and Answers

The following ten questions are the standard viva voce set for this capstone. Each answer is written to be defensible on the stand.

References

1. Google. (2024). Gemini API: Models and Documentation. Google AI for Developers. https://ai.google.dev/gemini-api/docs
2. National Aeronautics and Space Administration. (2024). Fire Information for Resource Management System (FIRMS). NASA Earthdata. https://firms.modaps.eosdis.nasa.gov/
3. European Space Agency / European Commission. (2024). Copernicus Sentinel Missions (Sentinel-1, -2, -3 and -5P). https://www.copernicus.eu/en/access-data
4. European Commission Joint Research Centre. (2024). Global Disaster Alert and Coordination System (GDACS) and the Global Flood Awareness System (GLOFAS). https://www.gdacs.org/
5. Vovk, V., Gammerman, A., and Shafer, G. (2005). Algorithmic Learning in a Random World. Springer (split-conformal prediction).
6. National Institute of Standards and Technology. (2013). FIPS 186-4: Digital Signature Standard (DSS), ECDSA over the P-256 curve.
7. Google Cloud. (2024). Cloud Run Documentation. https://cloud.google.com/run/docs
8. World Wide Web Consortium. (2023). Web Content Accessibility Guidelines 2.2. W3C Recommendation, 5 October 2023. https://www.w3.org/TR/WCAG22/
9. Ministry of Electronics and Information Technology, Government of India. (2023). The Digital Personal Data Protection Act, 2023. Gazette of India, Extraordinary, Part II, Section 1, 11 August 2023.
10. European Parliament and Council. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, L 119, 4 May 2016.
11. Intergovernmental Panel on Climate Change. (2023). AR6 Synthesis Report: Climate Change 2023. Contribution of Working Groups I, II and III to the Sixth Assessment Report. IPCC, Geneva.
12. Newman, N., Fletcher, R., Robertson, C. T., Eddy, K., and Nielsen, R. K. (2024). Reuters Institute Digital News Report 2024. Reuters Institute for the Study of Journalism, University of Oxford.
13. Express. (2024). Express 4.x API Reference. https://expressjs.com/en/4x/api.html
14. Agafonkin, V. (2024). Leaflet 1.9 Documentation. https://leafletjs.com/reference.html
15. Joulin, A., Grave, E., Bojanowski, P., and Mikolov, T. (2017). Bag of Tricks for Efficient Text Classification. Proceedings of the 15th Conference of the European Chapter of the Association for Computational Linguistics, Volume 2.
16. Charikar, M. (2002). Similarity Estimation Techniques from Rounding Algorithms. Proceedings of the 34th Annual ACM Symposium on Theory of Computing (STOC '02), pp. 380-388.
17. National Institute of Standards and Technology. (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM).
18. National Disaster Management Authority, Government of India. (2023). National Disaster Management Plan, Revised Edition. NDMA, New Delhi.
19. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF.