Demand alone does not tell the whole story. Our team built a prototype that compared synthetic demand with available resource units across ten Bengaluru zones.
Our team placed third nationally.We presented the prototype to Deepinder Goyal.
Read this as a synthetic-data study. The project dates to 2019. This report reconstructs its artifacts in 2026. It does not measure real orders, fleet size, earnings or operational improvement.
10Bengaluru demo zones
3Synthetic daily scenarios
10 minProfile resolution
28 daysSynthetic training sequence
01 / Explore the demonstration
The same demand can create different pressure.
Choose a scenario and time. The score is synthetic demand divided by configured resource units. It is a relative signal, not a probability of receiving an order.
Ten locations, not service boundaries.
Bengaluru
Circle size and colour show the selected measure. Numbers identify zones in the table below. The coordinates come from the archived database. The map does not show delivery routes or travel time.
Supply is the archived configuration, held constant as the time changes. The 492 units are not 492 verified drivers.
Inspect all ten zone values at the selected time.
Synthetic demand and demo resource units
Zone
Demand
Resource units
Score
02 / Read the data
Different profiles create different decisions.
The daily profiles contain 144 intervals each. These are constructed scenarios, not observations collected on specific calendar dates.
Daily demand profiles
Sum across ten columns
MondaySundayNew Year
The New Year file starts at 12:00 and wraps through the day. This report sorts its 24-hour labels. It does not reinterpret a noon peak as midnight.
How demand varies by zone and hour
Monday
Each cell is the mean of six ten-minute values. Darker cells indicate higher synthetic demand. Column-to-zone pairing follows the original demo's ID order; the files do not establish learned geographic relationships. Scroll within the chart on a small screen.
Four weeks of constructed demand
SyntheticData2.csv
Bars show each day's total. The shaded final week is reserved for the new baseline comparison. Day numbers are sequence positions, not calendar dates.
A simple forecasting benchmark
2026 retrospective check
Lower mean absolute error is better. The final 1,008 rows contain 10,080 target values. These are rolling one-step baselines; earlier observed values are available. They are not held-out results from the archived LSTM.
03 / Test the idea
Moving supply changes both ends of the journey.
Transfer demo resource units between two zones. This arithmetic experiment keeps the total at 492 and leaves demand unchanged. It does not simulate trips or predict what drivers would do.
Scores use demand / max(resource units, 1), matching the demo. A zero-resource zone therefore uses a denominator of one. That convention prevents division by zero but is not an operational forecast.
04 / Method and engineering
Separate the working demo from the model experiment.
Android clientRequests locations and displays weighted map points.
→
Django + DRFValidates requests and reads a selected CSV interval.
→
SQLite + CSVStores demo supply and ten-zone demand profiles.
What the repository contains
Three daily CSV profiles contain 432 rows and 4,320 synthetic demand values in total.
Two training CSVs each contain 4,032 rows and ten features. The notebook uses SyntheticData2.csv.
The SQLite snapshot defines ten zones, 492 resource units and only two driver-location records.
The original presentation and Android screenshot document the hackathon concept.
What the model experiment establishes
The Keras notebook uses a one-step look-back, ten LSTM units, 0.5 dropout and a ten-output dense layer.
Training uses Adam, mean absolute error, 100 epochs and a batch size of 20.
The notebook trains on the full constructed sequence. It contains no held-out evaluation.
The API reads CSV values. It does not call the saved LSTM. Model quality and current model compatibility remain unverified.
How this report was produced
Read the original files. Python's csv, sqlite3 and statistics modules export the profiles, zone configuration and baseline errors. The original database is opened read-only.
Align the demonstration. Normalised clock labels put each profile in time order. Zone IDs establish the same ten-column pairing used by the demo.
Make comparisons explicit. Demand totals describe synthetic profiles. Scores divide demand by the archived resource configuration. Baselines use lags of one interval, one day and one week.
Keep the report portable. Plain HTML, CSS, JavaScript and SVG power these charts. Pillow prepares the cached map image. There is no chart framework, live backend or tracking script.
New drivers retain their requested ID. Invalid inputs and insufficient origin supply return explicit errors.
Exact clock matching replaces ambiguous substring matching. File paths no longer depend on the working directory.
The local CSV demo runs on Django 5.2 without loading TensorFlow. Live inference returns an explicit unsupported response.
The Android source now parses JSON, checks permissions, uses actual location callbacks and refreshes after a successful update.
Limits that still matter
Synthetic data cannot establish real demand, earnings, service quality or the value of relocation.
Nearest-coordinate matching ignores roads, traffic, travel time and service-area boundaries.
Drivers moving towards the same hotspot could create a new imbalance. This prototype does not model that response.
The resource weights of seven and ten are inherited demo mechanics, not individual driver counts.
The Android project uses a legacy Instant App toolchain. Source fixes are not a verified Android build or runtime test.
05 / Conclusion
The useful idea is the comparison, not an accuracy claim.
What this project demonstrates
A zone with more demand is not necessarily the zone with the greatest demand per resource unit.
A map can make that comparison visible while leaving the relocation decision with the workforce.
The reconstructed demo makes the data flow inspectable, from CSV values through API scoring to the map.
What would need evidence next
Real, time-aligned demand and availability data would be needed before evaluating the scoring rule.
A forecast should beat simple seasonal baselines on unseen real data before it supports operational decisions.
A relocation policy would need travel costs, capacity constraints and a controlled evaluation of service outcomes.
The achievement here is a nationally placed team prototype and a clear product experiment. The archived evidence does not support a claim of production deployment or measured business impact.
