Earth observation pipelines that hold up to review
Satellite analysis is easy to demonstrate and hard to defend. The provenance, validation and versioning practices that make a published layer auditable.
Conceptual visualization only
Article
Provenance before modelling
A published map layer is a claim about the world, and someone will eventually ask where it came from. Every output we publish records the scene identifiers, acquisition dates, cloud and orbit filters, the coordinate reference system, the processing code version and the run timestamp.
This is unglamorous work that pays off the first time a result is challenged. Without it, the only honest answer is that the layer cannot be reproduced.
Validation sets the ceiling on your accuracy claim
Reported accuracy is a statement about your reference data as much as your model. If historical extents were digitised inconsistently, no model can be shown to beat that noise. We curate and document the reference set before quoting any figure, and we report accuracy per region or land cover class rather than as one headline number.
- Document how reference data was collected and by whom
- Report per-class accuracy: urban water behaves nothing like open water
- Keep a held-out region the model never trains on
- State the confidence interval, not just the point estimate
Versioned layers, not overwritten ones
Overwriting a published layer destroys the ability to explain a decision made last quarter. We version outputs and keep a change log, so a planner can retrieve exactly the layer that was on screen when they made a call.
Storage is cheap compared with the cost of an unexplainable decision in a regulated setting.
Where models genuinely help
Thresholding and index-based methods remain strong baselines and should always be run first. Learned segmentation earns its place in mixed land cover, built-up areas and where sensor noise defeats simple thresholds. It should be shown to beat the baseline on the same validation set before it ships.
Key takeaways
Related reading
When not to use an AI agent
Most workflows that get pitched as agentic are better served by a scheduled job, a form or a rules engine. A practical filter for deciding which is which.
Evaluating agents before you put them in front of users
A demo proves an agent can succeed once. Evaluation tells you how often it fails and how badly. What we measure, and how the evaluation set gets built.
Designing human approval steps people actually use
Approval gates fail in two directions: too many and reviewers rubber-stamp, too few and nobody trusts the system. How to place them deliberately.
Ready to scope your AI initiative?
Share your objective and constraints. A specialist reviews every request before any recommendation is issued.

