Source data
- Sentinel-1 and Sentinel-2
- ERA5 and CHIRPS weather
- GPS-locked field observations
- Farm and crop records
Flagship project · Built end to end
RaDa Intelligence
A satellite-to-field intelligence platform for smallholder agriculture. It combines Earth observation, weather history, and field evidence so agricultural teams can monitor crop conditions, investigate risk, and decide where attention is needed.
The problem
Farm decisions arrive before perfect data does.
Smallholder farms generate very little structured operational data. Satellite products can help, but a pixel alone doesn’t explain whether a weak signal came from crop stress, cloud cover, irrigation, planting dates, or a field boundary that was wrong in the first place.
RaDa was built around that gap. The system brings remote sensing and field observations into one evidence trail. It gives field teams a practical way to collect ground truth, ties those observations to farms and pixels, and feeds validated evidence back into the model workflow.
System architecture
Four clear layers keep the platform understandable. Each layer owns one kind of work and communicates through explicit data contracts and events.
Data backbone
- Earth Engine processing
- Farm and pixel mapping
- BigQuery warehouse
- Event-driven ingestion
Intelligence
- Feature engineering
- Vertex AI training
- Crop and stress models
- Rules and confidence checks
Product surfaces
- Backend APIs
- Android field application
- Web tools and alerts
- Cooperative dashboards
Validated field observations return to the dataset → weak spots become the next labeling and model-improvement priorities
Data pipeline
From raw observation to usable evidence.
The difficult work is alignment: different resolutions, different clocks, incomplete fields, and real-world observations captured on imperfect connections.
Ingest
Collect satellite, weather, farm boundary, and field-event data from independent sources.
Normalize
Standardize time, geometry, identifiers, and quality flags before records move downstream.
Map
Attach observations to farms and pixel anchors so every derived signal keeps its provenance.
Build features
Create temporal and geospatial features from vegetation, moisture, rainfall, and field history.
Serve
Expose trusted results through APIs, field workflows, dashboards, and decision summaries.
AI pipeline
Training is one part of the system.
Model work starts with the evidence contract and ends with user feedback. The pipeline is designed to make uncertainty visible, not bury it behind a confident interface.
Curate labels
Review field observations, location quality, crop context, and image usefulness.
Split spatially
Hold out locations, not only random rows, to reduce geographic leakage during evaluation.
Train
Run managed training workflows on Vertex AI with versioned inputs and reproducible configuration.
Evaluate
Compare model behavior across crops, locations, confidence bands, and known failure cases.
Close the loop
Route uncertain or high-value cases back to field teams for fresh evidence and review.
Engineering decisions
Choices I would still defend.
These decisions added some work at the start. They made later decisions easier, especially once mobile capture, analytics, and model workflows began moving at different speeds.
Separate data and inference from the applications.
The Android and web surfaces depend on stable contracts, not a particular model. Models can change without forcing every client to change with them.
Treat ground truth as a product.
The field application doesn’t merely collect forms. It captures location, context, and review signals that determine whether an observation is fit for model training.
Keep a deterministic layer beside ML.
Business rules and explicit quality checks handle facts the model shouldn’t guess. This makes failures easier to trace and high-risk outputs easier to stop.
Design for interrupted connectivity.
Field work can’t assume stable data service. Capture and synchronization are separate concerns, with clear states instead of silent loss.
Trade-offs
What the architecture costs.
There is no serious architecture without a bill. These are the compromises I chose deliberately.
Managed cloud services
Gain: faster delivery, scaling, and operational visibility for a small team.
Cost: tighter dependence on GCP services and more care needed around portability.
Event-driven boundaries
Gain: auditable workflows and services that can evolve independently.
Cost: more moving parts, idempotency work, and harder end-to-end debugging.
Offline-capable field capture
Gain: the product remains useful where connectivity is unreliable.
Cost: synchronization, conflict handling, and honest status design become first-class engineering work.
Human review
Gain: weak evidence is caught before it becomes a confident recommendation.
Cost: the system doesn’t pretend every decision can be fully autonomous.
Results
What exists because it shipped.
RaDa is still evolving. These are concrete outputs from the system, not forecasts about what it might become.
18,507 labeled samples
A growing crop dataset linked to field evidence and designed for iterative model improvement.
Field and web workflows
Working surfaces for data collection, farm monitoring, agronomy review, and cooperative use.
Reusable services
Data and inference capabilities can support more than one interface without duplicating the underlying logic.
Traceable outputs
Signals retain their farm, pixel, time, and source context so users can understand where an answer came from.
Lessons
What changed my thinking.
Field conditions are architecture. Connectivity, GPS accuracy, device constraints, and the time a person has to capture an observation shape the system as much as the model does.
Data quality compounds. A better evidence trail improved debugging, evaluation, product trust, and future model work at the same time.
Confidence needs a user interface. A score hidden in a payload is not enough. People need to see whether a recommendation is strong, provisional, or waiting for field confirmation.
Clear boundaries pay for themselves. The platform grew from one model workflow into multiple products. Separating concerns made that expansion possible without turning the original implementation into a permanent constraint.
The short version
I built the platform, not only the model.
RaDa is the clearest example of how I work: own the problem, make the system legible, ship a useful version, and improve it with real evidence.