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 combines two artificial intelligence services. The first is a social-media summarisation pipeline that ingests local Twitter or X and Reddit posts, removes duplicates and noise, classifies posts by category (road, shelter, power, water, medical) and produces a short status summary the responder can act on. The second is a multilingual voice bot built around Twilio telephony and OpenAI Whisper that lets elderly residents without smartphones call a single number and report an incident or ask for help in Hindi, Punjabi, Tamil, Bengali or English.

The minimum lovable product is implemented in Node.js 20 with Express, a Tailwind front-end, Leaflet maps and the browser Web Speech API. It is containerised with Docker, pushed to Google Artifact Registry and served from Cloud Run in the asia-east1 region behind the custom domain localpulse.dmj.one. Cold-start latency is held under two seconds, ninety-fifth percentile request latency under two hundred milliseconds and idle cost at near zero through scale-to-zero. Future scope includes live Twitter and Reddit ingestion, Twilio production telephony, an offline-first Progressive Web Application with satellite SMS fallback, and integration with the National Disaster Management Authority data feeds.

Keywords. crisis management, disaster response, NLP summarisation, multilingual voice assistant, Twilio, Whisper, GPT-4o, 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 social-media posts (Twitter or X and Reddit) and surface a deduplicated, categorised feed in the responder console.
• The system shall expose JSON application programming interfaces for incidents, summaries, reports and voice intents.
• The system shall accept a phone call on a single Twilio number, transcribe the speech with Whisper, classify the intent and respond either with spoken information or with a forwarding action.
• 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 and a /readyz endpoint for readiness probes.
• The system shall publish an OpenAPI specification at /api/openapi.json so that integrators can generate clients automatically.

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, configured with 1 vCPU, 512 mebibytes of memory, scale-to-zero (min instances = 0) and a maximum of 2 instances on the minimum lovable product. Artifact Registry stores the container image. A custom domain mapping points localpulse.dmj.one at the service URL.

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. The application layer is an Express server that exposes JSON application programming interfaces and renders the HTML shell. The intelligence layer is a set of small Node-side services for summarisation and intent classification, which talk to managed AI providers when running in production. The data layer is in-memory and static for the minimum lovable product, and is Firestore plus Pub/Sub plus BigQuery in production.

3.2 Component Inventory

3.3 Data Flow

Public posts arrive at the ingest worker every sixty seconds through the Twitter API v2 filtered stream and the Reddit listing endpoint scoped to the configured subreddit list. The worker normalises each post into a canonical event with fields source, source_id, author_hash, text, language, lat, lon and observed_at. It publishes the event to the Pub/Sub topic incidents-v1.

A subscriber, the dedupe-and-classify worker, pulls events in batches of fifty. It first computes a SimHash of the normalised text and discards events whose hash is within a Hamming distance of three of any event seen in the last fifteen minutes. It then sends the surviving events to a small zero-shot classifier with the five category labels. The classifier returns the top label and a confidence score.

Classified events are written to Firestore under the incidents collection and re-published on a downstream topic incidents-classified. A second subscriber, the summariser, pulls the last fifteen minutes of events for each category and prompts GPT-4o with a fixed system prompt and a JSON output schema. The schema enforces five short status lines, one per category. The result is written to the summaries collection with a server timestamp.

On the read path, the dashboard issues a GET to /api/summary?town=solan, which reads the latest summary document from Firestore. It also opens a server-sent events connection to /api/incidents/stream, which pushes any new incident document through a Firestore snapshot listener. A small client-side reconciler merges new events into the map.

On the voice path, an incoming call hits a Twilio number. Twilio posts the call to a webhook served by Cloud Run. The handler streams the audio to Whisper, gets a transcript, sends the transcript to a small intent classifier, and replies with TwiML that either speaks an answer via Polly Neural voices or transfers the call to a local control-room number. The transcript and the intent are persisted to the reports collection.

3.4 API Design

All public application programming interfaces follow REST conventions, are versioned under /api/v1/, return JSON encoded as UTF-8, accept and emit ISO 8601 timestamps, and produce errors in the shape {error: {code, message, details}}. Mutations require an idempotency key passed in the Idempotency-Key header. Pagination is cursor-based with a next_cursor field. Rate limits are enforced per endpoint and per anonymous client identifier with a Retry-After header.

3.5 Data and State Design

In the minimum lovable product, the data plane is a small set of JSON files mounted into the container and read on boot. A request handler filters the in-memory list by query parameters and returns the slice. Writes are append-only to a process-local array and are not persisted across instances; the design accepts this because the demo is meant to show the user-facing behaviour rather than the persistence story.

In production, Firestore in Native mode holds three collections. The incidents collection stores one document per classified post or resident report. The summaries collection stores one document per town per minute. The reports collection stores resident-submitted incidents and voice-bot reports. Each document carries a server-assigned timestamp, a town code and a content type. Pub/Sub topics carry events; BigQuery scheduled queries roll up daily metrics.

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 field-level encryption (AES-256-GCM) for any caller phone number passed from Twilio. Denial of service is dampened by Cloud Armor rate rules at the edge and per-route token-bucket limits at the application. Elevation of privilege is constrained by least-privilege service accounts that hold only the Pub/Sub publisher and Firestore user roles they require.

Data residency follows the Digital Personal Data Protection Act, 2023. The Cloud Run service, the Firestore database, the Pub/Sub topics and the Cloud Logging buckets are all pinned to asia-east1, which is the Taiwan region nearest to Indian users while being inside the Asia-Pacific data perimeter; production rollout will move to asia-south1 (Mumbai) or asia-south2 (Delhi) for in-country residency. No personally identifiable information 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 through Cloud DNS to a Google front-end. The front-end terminates Transport Layer Security with a Google-managed certificate, applies Cloud Armor rules and forwards the request to the Cloud Run service in asia-east1. The service runs in a single revision, scales from zero to two instances on the minimum lovable product (and up to fifty in production), and is fronted by a serverless Network Endpoint Group when traffic warrants a load balancer. Container images are pulled from Artifact Registry. Build and release flow through GitHub Actions, which authenticates to Google Cloud through Workload Identity Federation.

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/v1/incidents/stream and receives events keyed by an event-id that the server emits monotonically. If the connection drops, the browser reconnects with a Last-Event-ID header and the server replays missed events from a small in-memory ring buffer. On the production data plane the same endpoint is backed by a Firestore snapshot listener so that fan-out scales horizontally.

5.6 AI Summarisation Pipeline

The summarisation pipeline in the minimum lovable product is a pure function that reads the curated mock posts, groups them by category, joins the top three per category and returns a hand-crafted summary string. The function emits the same shape that the production pipeline emits, so the front-end has no special-case code path.

In production, the pipeline runs as a Cloud Run worker that is triggered by Pub/Sub. The worker calls the OpenAI Chat Completions endpoint with model gpt-4o, response_format set to JSON, and a fixed system prompt that instructs the model to return five short bullets, one per category, in the chosen locale. Prompt injection is mitigated by stripping URL fragments and by wrapping each user post in a fenced block with a sentinel.

5.7 Voice Bot Flow

The voice demonstration in the minimum lovable product runs entirely in the browser. The client requests microphone permission, opens a SpeechRecognition session keyed to the chosen language, sends the interim transcript to /api/v1/voice/intents on each result event and speaks the response with SpeechSynthesis. This flow is not for production use; it exists so that a viva examiner can test the language switching and the intent classification without hardware.

In production, an inbound call hits a Twilio number. Twilio posts a webhook to /api/v1/voice/webhook with the call SID and a media stream URL. The handler opens a WebSocket back to Twilio, forwards the audio frames to Whisper through the streaming endpoint, receives interim transcripts, classifies the intent, formats a short spoken reply with Polly Neural voices and sends back TwiML. If the intent is emergency-redirect, the call is dialled out to the configured control-room number using TwiML <Dial>.

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/v1/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());

const ring = []; const RING_MAX = 256;
export function emit(evt) {
  ring.push(evt);
  if (ring.length > RING_MAX) ring.shift();
  for (const sub of subs) sub.write(format(evt));
}

app.get('/api/v1/incidents/stream', (req, res) => {
  res.set({
    'Content-Type': 'text/event-stream',
    'Cache-Control': 'no-store',
    Connection: 'keep-alive',
  });
  const since = Number(req.headers['last-event-id'] ?? 0);
  for (const evt of ring) if (evt.id > since) res.write(format(evt));
  subs.add(res);
  req.on('close', () => subs.delete(res));
});

const RULES = [
  [/(shelter|राहत|आश्रय)/i, 'ask-shelter'],
  [/(road|रास्ता|सड़क)/i,  'ask-road-status'],
  [/(power|बिजली)/i,        'ask-power'],
  [/(emergency|खतरा)/i,     'emergency-redirect'],
];

app.post('/api/v1/voice/intents', express.json(), (req, res) => {
  const text = String(req.body?.text ?? '').slice(0, 500);
  const intent = RULES.find(([re]) => re.test(text))?.[1] ??
    'report-incident';
  res.json({ intent, reply: replyFor(intent, req.body?.lang) });
});

6. Algorithms and Models

6.1 Social-media Summarisation Pipeline

The summarisation pipeline runs in four stages: ingest, dedupe, classify, summarise. The ingest stage normalises each post into a canonical event. The dedupe stage uses SimHash with sixty-four bits and a Hamming distance threshold of three over a sliding fifteen-minute window; SimHash is preferred over a vector cosine because the bit operation runs in constant time per comparison and the window fits in a small bitmap. The classify stage uses a zero-shot text classifier built around a small instruction-tuned model. The summarise stage uses GPT-4o with JSON-mode and a fixed schema that enforces five short bullets.

The complexity of the pipeline is dominated by the deduplication step. With n events in the active window, the naive comparison is O(n^2), which we reduce to O(n log n) by maintaining a sorted Bloom-filter-of-SimHash structure keyed on the top sixteen bits of the hash. Memory is O(n) bounded by the window size.

6.2 Voice Intent Classification

Intent classification for the voice bot is a five-way decision among report-incident, ask-shelter, ask-road-status, ask-power and emergency-redirect. In the minimum lovable product, the classifier is a small set of regular expressions that match keywords in each supported language; this is deliberately legible and works offline. In production, the classifier is the same GPT-4o call that produces the spoken reply, which avoids a second model hop and saves about one hundred and fifty milliseconds of latency per turn. Confidence is reported as the model logprob aggregated over the JSON intent field; below a threshold of zero point seven five, the bot asks a clarification question.

6.3 Trust Score

Each surfaced post carries a trust score that is computed as the weighted product of three factors. Source reliability is a static weight assigned per source domain (verified municipal account = 1.0, verified news = 0.8, recognised volunteer = 0.6, anonymous = 0.3). Confirmation count is the number of independent posts within fifteen minutes that are classified into the same category and that reference an overlapping geographical area; this factor is a saturating function 1 - exp(-k/3). Recency decay is an exponential with a half-life of twenty minutes. The score is in the range zero to one and is shown to responders as a four-step indicator: low, moderate, strong, confirmed.

6.4 Language Identification

Language identification uses Compact Language Detector 3 (cld3) on the server side and FastText pre-trained language vectors when an offline fallback is needed. cld3 is preferred because it ships as a small native binding, recognises the major Indian scripts out of the box and runs in micro-second latencies. For very short voice transcripts (under five tokens), the system falls back to the language hint passed by Twilio in the call leg, which is set from the language IVR menu.

7. Testing

Tests run at six layers, each chosen to catch a specific class of regression as early as possible in the development cycle.

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 two instances. The custom domain localpulse.dmj.one is mapped to the service through a Cloud Run domain mapping; Google issues and renews the Transport Layer Security certificate automatically.

9.1 Dockerfile

# Build stage: install only what we need to compile.
FROM node:20-alpine AS build
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci --omit=dev
COPY . .

# Run stage: minimal image, non-root user.
FROM node:20-alpine
RUN addgroup -S app && adduser -S app -G app
WORKDIR /app
COPY --from=build --chown=app:app /app /app
USER app
ENV NODE_ENV=production PORT=8080
EXPOSE 8080
HEALTHCHECK --interval=10s --timeout=2s CMD wget -qO- http://127.0.0.1:8080/healthz || exit 1
CMD ["node", "server.js"]

9.2 Cloud Run Deploy

gcloud run deploy localpulse \
  --image=asia-east1-docker.pkg.dev/$PROJECT/localpulse/api:$SHA \
  --region=asia-east1 \
  --platform=managed \
  --allow-unauthenticated \
  --port=8080 \
  --cpu=1 --memory=512Mi \
  --min-instances=0 --max-instances=2 \
  --concurrency=80 \
  --service-account=localpulse-runtime@$PROJECT.iam.gserviceaccount.com \
  --set-env-vars=NODE_ENV=production,LOG_LEVEL=info

gcloud beta run domain-mappings create \
  --service=localpulse \
  --domain=localpulse.dmj.one \
  --region=asia-east1

9.3 Continuous Integration and Release

Continuous integration runs on GitHub Actions. The workflow has three jobs. The lint-test job runs npm ci, npm run lint, npm run test:unit and npm run test:integration. The build job runs only on the main branch, builds the Docker image, signs it with cosign and pushes it to Artifact Registry. The deploy job is gated behind an environment-protection rule that requires manual approval for the production environment; once approved, it runs gcloud run deploy with the new image digest. Authentication uses Workload Identity Federation, so the workflow holds no long-lived service-account key.

The release strategy is rolling with health-gated traffic. New revisions receive zero percent of traffic on first deploy. A small smoke-test script hits /healthz, /readyz and /api/v1/summary against the new revision. If all checks pass, traffic is shifted to one hundred percent. If any check fails, the revision is deleted and traffic stays on the previous good revision. Rollback is a single gcloud command and completes in under sixty seconds.

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

• Live ingestion. Replace the curated mock with the Twitter or X filtered stream, the Reddit listing endpoint and a small WhatsApp Business listener so that real public posts feed the summariser.
• Production telephony. Provision a Twilio Indian DID, wire the Whisper streaming endpoint, and run a closed pilot in one Tier 3 town with the local civil defence unit.
• Offline-first PWA. Promote the service to a full Progressive Web Application with a service worker, IndexedDB-backed outbox and a satellite SMS fallback through Inmarsat or Iridium 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.
• Government data integration. Join the National Disaster Management Authority and State Disaster Response Force feeds where available, publish situation reports back as standard CAP (Common Alerting Protocol) messages, and let LocalPulse sit alongside Sachet.
• 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. Radford, A., Kim, J. W., Xu, T., Brockman, G., McLeavey, C., and Sutskever, I. (2022). Robust Speech Recognition via Large-Scale Weak Supervision. arXiv:2212.04356.
2. OpenAI. (2024). GPT-4o System Card. OpenAI Technical Report. https://openai.com/index/gpt-4o-system-card/
3. Twilio. (2024). Programmable Voice Documentation. https://www.twilio.com/docs/voice
4. Google Cloud. (2024). Cloud Run Documentation. https://cloud.google.com/run/docs
5. World Wide Web Consortium. (2023). Web Content Accessibility Guidelines 2.2. W3C Recommendation, 5 October 2023. https://www.w3.org/TR/WCAG22/
6. 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.
7. European Parliament and Council. (2016). Regulation (EU) 2016/679 (General Data Protection Regulation). Official Journal of the European Union, L 119, 4 May 2016.
8. 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.
9. 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.
10. Express. (2024). Express 4.x API Reference. https://expressjs.com/en/4x/api.html
11. Agafonkin, V. (2024). Leaflet 1.9 Documentation. https://leafletjs.com/reference.html
12. 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.
13. 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.
14. National Institute of Standards and Technology. (2024). FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (ML-KEM).
15. National Disaster Management Authority, Government of India. (2023). National Disaster Management Plan, Revised Edition. NDMA, New Delhi.
16. Rescorla, E. (2018). The Transport Layer Security (TLS) Protocol Version 1.3. RFC 8446, IETF.