NËBB

What problem does NËBB solve?

Bargny and Diamniadio/Sébikotane concentrate much of Senegal's heavy industry. Residents can see the pollution; nobody measures it. Reference-grade monitoring stations cost tens of thousands of euros each — you do not cover a territory with those.

The way out is the low-cost sensor. But a low-cost sensor drifts: temperature, humidity and ageing all shift its readings. Publishing its raw values means publishing something false with the authority of a number.

What constraints does that impose?

The heart of the project is therefore not collection, it is trust in the data. Four models each answer one facet of it.

Calibration with Random Forest. The cheap sensor is tamed by learning the gap between its readings and a reference instrument, conditioned on temperature and humidity. The model corrects the drift instead of inheriting it.

PM2.5 forecasting with LSTM and Prophet. The LSTM is in PyTorch, in a full and a lightweight variant depending on available compute. Two approaches in parallel — a recurrent network and seasonal decomposition — because a pollution alert exists to anticipate, not to confirm. Forecasts are published with a 95% confidence band: an alert that hides its uncertainty is an alert people eventually ignore.

Anomaly detection with Isolation Forest. Unsupervised, because no labelled examples of a failing sensor exist. It separates a genuine pollution spike from a sensor going bad.

Spatial interpolation with kriging. A dozen sensors do not cover a territory. Kriging produces a continuous heat map and its variance — so we know where the map is reliable and where it is extrapolating.

How is NËBB architected?

Ten containerised services, split across three Docker Compose files — infrastructure, application, pipeline — so the processing can be restarted without touching the database or the broker.

MQTT ingestion through Mosquitto, whose certificates are generated by script: the channel between sensors and platform is authenticated on both ends.

Three stores, each for what it does well. InfluxDB 2.7 for time series, with Flux tasks that downsample hourly and daily, compute the daily air-quality index and monitor data freshness. PostgreSQL 16 with PostGIS and pgvector for geospatial, business data and vector search. Redis 7.2 for caching and alert counters.

The FastAPI service exposes eleven routers — sensors, AQI, predictions, alerts, map, reports, export, pipeline, administration. Three middlewares sit in front: audit logging, request identifiers and security headers.

The pipeline is orchestrated by Prefect 3, with APScheduler for periodic triggers. Seven flows: feature engineering, predictions, kriging, retraining, monitoring and natural-language processing of citizen reports. Nothing runs inside a request cycle.

Nineteen screens on the React side: citizen dashboard, map, sensor grid, zone comparison — but also model detail, flow detail, worker detail and logs. A genuine supervision centre, not a dashboard.

Production-grade security from the design stage: JWT, RBAC, rate limiting, TOTP as a second factor, mTLS on the MQTT channel. A platform publishing health data is a target: if the data can be forged, the tool becomes dangerous.

A sensor simulator completes the setup: the whole chain can be tested without deployed hardware.

What was my role on NËBB?

Lead of a team of six spanning three disciplines — AI & Big Data, Telecoms, and Information Security. I owned the models and the backend architecture, and above all the translation work between people who did not share a technical vocabulary.

What did NËBB teach me?

The hard part was none of the four models taken alone. It was deciding what to publish when you are not sure. Showing a wrong value confidently does more harm than showing nothing: the whole architecture follows from that single constraint.