Workflow blueprint

Kapido system flow, explained as one clear operational story.

This page shows how one analysis request moves from the input form, through prediction and persistence, into analytics, validation, and dashboard visualization.

Runtime stages

7

Backend routes

10

System modules

4

Offline training lane

1

Live request path

The sequence below focuses on what happens during a real dashboard analysis run.

1

Enter the analysis inputs

The user chooses an hour and types a location in InputForm. The component searches the local location index, resolves coordinates, and stores the last run in localStorage.

No direct API call
findLocationMatches • resolveLocationCoordinates • getLocationCoordinates
2

Route the request to the dashboard

The home page builds a query string from the submitted hour, location, latitude, and longitude, then navigates to /dashboard.

No direct API call
handleSubmit • useRouter
3

Request a prediction

DashboardPage calls getPrediction, which sends GET /predict with the chosen hour, location, latitude, and longitude.

GET /predict
getPrediction • predict
4

Build features and score the models

PredictorService loads the saved model artifact, build_features creates temporal and geographic features, and the demand and supply models score the request.

No direct API call
PredictorService.predict • build_features
5

Produce the explanation layer

InsightService turns the numeric gap into severity, explanation strings, and recommended actions using the threshold rules and peak-hour logic.

No direct API call
InsightService.generate
6

Persist the result and refresh analytics

The dashboard posts the prediction snapshot to MongoDB, then loads hourly trends, location trends, and model validation metrics in parallel.

POST /store-predictionGET /analytics/hourly-trendsGET /analytics/location-trendsGET /analytics/model-validation
storePrediction • getHourlyTrends • getLocationTrends • getModelValidation
7

Render the operational view

PredictionCard, MapView, TrendCharts, and the validation monitor turn the API responses into an analyst-friendly dashboard.

No direct API call
PredictionCard • MapView • BarTrendChart • LineTrendChart

Interactive system map

Explore the full architecture graph. Pan, zoom, and inspect how runtime and offline parts connect.

Input to insight pipeline

FrontendBackendDatabaseAnalyticsOfflineExternal
Drag to pan, scroll to zoom, hover a node for details.
Mini Map

Main runtime

InputForm -> /dashboard -> /predict -> prediction output

Persistence and analytics

storePrediction -> MongoDB -> trends and validation

Offline model lifecycle

generate_ride_data.js -> train_model.py -> model.pkl

External services

MongoDB Atlas and OpenStreetMap tiles

API contracts

Endpoints currently available in the FastAPI backend and their usage in the live dashboard.

GET /predict

used in dashboard

Validates hour, location, and optional coordinates, then returns demand, supply, gap, severity, explanations, and recommendations.

POST /store-prediction

used in dashboard

Writes the prediction snapshot to MongoDB and backfills explanations and recommendations if they are missing.

GET /history

used in dashboard

Returns stored prediction records sorted by newest first.

GET /analytics/hourly-trends

used in dashboard

Aggregates stored predictions into hourly averages, shortage rates, and peak shortage hours.

GET /analytics/location-trends

used in dashboard

Groups stored predictions by location and returns hotspots plus severity labels.

GET /analytics/day-of-week

used in dashboard

Aggregates mismatch metrics by day index (0-6) and identifies peak shortage days.

GET /analytics/gap-distribution

used in dashboard

Returns percentile and bucket distribution of demand-supply gaps.

GET /analytics/time-series

used in dashboard

Returns time-ordered prediction history for charting.

GET /analytics/model-validation

used in dashboard

Evaluates the current model artifact against data/ride_data.csv and returns MAE, RMSE, and anomaly notes.

GET /health

support

Returns the API health status.

Module ownership

Where each responsibility lives in the codebase, with a clear runtime vs offline split.

Frontend runtime

Used by the live UI

Home, dashboard, form, charts, map preview, prediction card, and the typed API wrapper that orchestrates the user flow.

frontend/app/page.tsx

frontend/app/dashboard/page.tsx

frontend/components/InputForm.tsx

frontend/components/CoordinateMapPreview.tsx

frontend/components/PredictionCard.tsx

frontend/components/TrendCharts.tsx

Backend runtime

Active API layer

FastAPI routes, predictor service, feature builder, insight rules, history storage, analytics aggregation, and validation logic.

backend/app/main.py

backend/app/routes/prediction.py

backend/app/services/predictor.py

backend/app/services/preprocess.py

backend/app/services/insights_service.py

backend/app/services/history_service.py

Offline model lifecycle

Manual maintenance flow

The data generator expands ride_data.csv and the training script produces the model.pkl artifact consumed by PredictorService.

data/generate_ride_data.js

models/train_model.py

data/ride_data.csv

models/model.pkl

External services

Runtime dependencies

MongoDB Atlas stores prediction history, and Leaflet renders OpenStreetMap tiles for the preview map and result map.

backend/app/db/mongo.py

frontend/components/CoordinateMapPreview.tsx

frontend/components/MapView.tsx