Why I Built VERA
I started this project with a simple question: when environmental data sources disagree, how do we know which information is reliable enough to make a decision?
While researching climate and weather solutions for Africa, I found that there are already many systems for rainfall monitoring, flood warnings, drought detection, satellite observation, and weather dashboards. But I noticed a deeper problem: these systems often depend on data that can itself be incomplete, noisy, locally inaccurate, or difficult to interpret.
This became especially important when I studied satellite rainfall products used across Africa. Satellite data provides enormous geographic coverage, but research has shown that its performance can vary by location, season, and rainfall event. At the same time, ground sensors provide local measurements but can also experience missing values, spikes, flatlines, or sensor disagreement.
That led me to a different approach.
Instead of building another weather dashboard, I decided to build VERA — Verified Environmental Reality & Analytics: a software layer that evaluates environmental observations before they are used for downstream decisions.
What VERA Does
VERA uses local environmental observations from the JKUAT Conduit platform and evaluates whether the measurements are sufficiently trustworthy.
For rainfall, VERA can compare the readings from two local rain gauges, check for missing or suspicious values, examine temporal behaviour, and use other atmospheric measurements such as temperature, humidity, pressure, and wind as supporting context.
It then compares quality-screened local rainfall with satellite rainfall data.
The important part is that VERA does not simply declare one source “correct” and the other “wrong”.
Instead, it explains the evidence:
- Are the local sensors agreeing?
- Is the observation complete and plausible?
- Is there a possible sensor-quality problem?
- Does satellite rainfall differ from the local observation?
- Is there enough confidence to use the observation for a particular decision?
The result is an explainable environmental evidence and confidence layer, rather than another visualization dashboard.
From Data to Action
My goal was to move beyond:
Data → Graph → User
and build:
Data → Validation → Evidence → Confidence → Decision → Action
For example, if two local gauges strongly agree but satellite rainfall is substantially different, VERA does not automatically label the satellite product as wrong. It reports the disagreement and explains that the local measurements provide strong point-level evidence while the satellite represents a larger spatial area.
If the two gauges disagree significantly, VERA reduces confidence in the local observation and can recommend reviewing the station instead of blindly using the measurement as ground truth.
This makes the system useful before environmental data enters applications such as agricultural advisory, flood monitoring, drought analysis, or other climate services.
How I Built It
I designed VERA as a software-first system so that it can work with existing environmental infrastructure rather than requiring new hardware.
The architecture consists of:
- Conduit data ingestion for local environmental observations
- Data normalization and validation
- Rule-based quality-control checks
- Dual-gauge consistency analysis
- Satellite rainfall comparison
- Explainable confidence and reason codes
- Decision recommendations
- Operator feedback and audit logging
- A web interface for viewing the evidence
For the first version, I intentionally chose transparent rules instead of hiding the decision inside a black-box machine-learning model. A user should be able to understand why VERA lowered confidence in a measurement.
What I Learned
The biggest lesson from this project was that more data does not automatically mean better decisions.
A system can have satellites, sensors, APIs, AI models, and beautiful visualizations, but if the user cannot understand the reliability and limitations of the underlying information, the final decision can still be wrong.
I also learned that disagreement between data sources is not necessarily a failure. Sometimes disagreement reveals something important: a sensor problem, a spatial difference, a timing difference, or a limitation of an observation system.
That changed how I thought about environmental technology.
Instead of asking only:
“What does the data say?”
I started asking:
“How much evidence do we have that this data is reliable for this decision?”
Challenges
One of the biggest challenges was designing VERA without pretending that uncertain environmental measurements are absolute truth.
A rain gauge measures rainfall at a point. A satellite product estimates rainfall across an area. Their values can legitimately differ.
Another challenge was designing the quality checks so that unusual weather is not automatically treated as faulty sensor data. A very large rainfall event may be a real event rather than an anomaly.
Because of this, VERA uses language such as “suspected data-quality issue” and “ground–satellite mismatch” rather than making unsupported claims.
What Comes Next
I designed VERA so that rainfall is only the beginning.
The same foundation can eventually support other environmental observations such as heat stress, drought indicators, water conditions, air-quality measurements, and additional satellite products.
As environmental sensing becomes more widespread over the next decade, the amount of environmental data will continue to increase. I believe systems will need not only more observations, but also a way to understand their quality, uncertainty, provenance, and usefulness for decisions.
That is the long-term idea behind VERA:
not another weather application, but a reusable trust and evidence layer for environmental intelligence.
Built With
- chirps
- data
- data-quality
- environmental-monitoring
- fastapi
- google-visualization
- javascript
- numpy
- pandas
- react
- rest-api
- satellite-data
- sqlite
- ython
Log in or sign up for Devpost to join the conversation.