October 2026: Making the Earth Machine-Readable
Reviewed and revised:
We can observe almost any location on Earth. That does not mean a machine can understand what is happening there.
Satellites collect optical, radar, and spectral data. Aircraft and drones measure terrain. Ground sensors record environmental conditions. Positioning systems track vessels, vehicles, and other assets.
More data is being collected. More of it is available through APIs. More AI models can analyse individual datasets.
Yet a question as simple as which industrial sites expanded in the last six months? can still require manual searches, image purchases, data preparation, interpretation, and reporting.
We have made the Earth observable. We have not made it consistently machine-readable.
A digital image is not an answer
Consider two requests.
Show me satellite imagery of this port from the past six months.
Tell me which facilities at this port have changed, when the changes became visible, and what evidence supports the conclusion.
The first is a data retrieval problem. The second requires a system to identify physical features, compare observations over time, distinguish genuine change from sensor differences, and return a structured result.
A machine may be able to open a GeoTIFF, classify pixels, or detect an object. None of those capabilities alone makes the physical world machine-readable.
A usable result needs to identify what was observed, where it was observed, when it was observed, how the observation was produced, and how certain the interpretation is.
That information needs to survive as data moves between systems. Otherwise, the next application starts the interpretation process again.
Location is the common reference. Time gives it meaning.
Geospatial information can connect datasets that were never designed to work together.
Take a mining site. Satellite imagery shows surface disturbance. LiDAR describes terrain. Weather data records rainfall. Equipment telemetry provides operational context. Land tenure records establish permitted boundaries. Each describes a different part of the same physical environment.
Connected through geographic location and time, they can support a more useful question: has activity changed outside the permitted area, and what observations establish that change?
But coordinates are not enough. A detection at a known location is not necessarily a verified object. Two observations may disagree because of cloud, viewing angle, resolution, calibration, or an actual physical change.
And a condition observed last month is not necessarily the condition today.
A machine-readable representation needs to preserve those differences instead of smoothing them into a false picture of certainty.
The missing layer is infrastructure
This is not something an AI model can solve on its own.
The work starts before inference and continues after it. The infrastructure has to connect the complete information lifecycle:
- Discover. Find relevant observations across providers, sensors, locations, and dates.
- Acquire. Retrieve existing data or request new collection where coverage is insufficient.
- Normalise. Account for differences in resolution, projection, units, calibration, and processing.
- Interpret. Extract features, associate observations with physical objects, and detect meaningful changes.
- Preserve evidence. Retain timestamps, source information, model versions, uncertainty, and processing history.
- Deliver. Expose structured results through governed APIs, applications, and event workflows.
If these steps are disconnected, every use case becomes a separate integration project.
A system that detects a new structure but cannot retrieve its historical observations is incomplete. A system that produces an alert without recording its source is difficult to audit. A system that identifies change but cannot deliver a usable result into the customer's workflow remains dependent on manual effort.
The sensor produces an observation. The infrastructure connects it to everything needed to use it.
The standards already provide part of the foundation
We do not need to invent a universal geospatial file format.
STAC provides a common way to describe and discover spatial and temporal assets. Cloud Optimized GeoTIFF supports efficient access to raster imagery. GeoParquet supports interoperable geospatial feature data. OGC API standards provide consistent interfaces for geospatial resources.
These standards solve important parts of the access and exchange problem. They do not, by themselves, tell us whether a vessel has departed, a construction site has expanded, or a flood has affected a road.
That requires additional semantics, historical context, interpretation, verification, and operational logic.
It also requires an interoperable architecture. Data providers should not have to surrender ownership of their data for other systems to discover and use authorised information.
The goal is not one central database claiming to contain the whole planet. It is a network of connected, traceable observations and services.
Move from ordering images to asking questions
The larger change is from image-centric workflows to event-centric ones.
A port operator may want to know when activity changes around a berth. An environmental agency may want to identify new clearing in a protected area. A mining company may want to monitor surface disturbance. An emergency service may want to know which roads intersect an observed flood extent.
These users are not fundamentally asking for files. They are asking for changes in the physical world.
A machine-readable system should be able to maintain that question as new data arrives. It should decide whether existing observations are sufficient, identify relevant new evidence, update the result, and indicate what remains unknown.
When confidence is inadequate, the next useful action may be another observation rather than another model-generated answer.
That is where automated tasking, multi-sensor orchestration, normalisation, fulfilment, controlled distribution, and audit become part of the same problem.
Do not confuse inference with fact
The most dangerous failure would be to make the Earth's condition look more certain than the available evidence permits.
If a structure appears between two satellite acquisitions, the system may establish a period in which construction occurred. It cannot automatically identify the construction date. If a vessel is not detected, that does not prove it was absent.
Every derived result should preserve the distinction between observation, classification, inference, and verification.
It should also retain source provenance, data freshness, access permissions, and a way to correct the record when better evidence arrives.
This matters for every industry, and particularly where machine-readable outputs support safety, regulatory, emergency, or defence decisions.
What this means for EODI
Earth Observation Data Infrastructure is one part of this larger transition.
Before a machine can reliably interpret the world, it needs repeatable access to the observations on which that interpretation depends. It needs consistent metadata. It needs an accountable path through tasking, processing, normalisation, delivery, and access control.
The EODI standard addresses that operational foundation. It does not claim to provide a complete semantic model of the planet or replace specialist analysis.
Its role is to reduce the fragmentation between observation and use, so other systems can build on reliable data operations instead of reconstructing them for every application.
The next meaningful test of progress is not how many images we can acquire, or how many models can describe them.
It is whether another machine can ask a question about the physical world, receive a result with traceable evidence, and use that result without a person rebuilding the entire workflow.
We have built systems that let people look at the Earth. The next task is building infrastructure that lets machines understand what has changed, how we know, and what should happen next.