Why Hindsight Matters When Satellite Analysis Needs Evidence

Lakshmi Chaitanya — Mon, 28 Sep 2026 15:45:34 +0000

A satellite image can show you where something happened. The harder problem is getting a computer to understand what you are actually asking about.

If I ask, “Where has vegetation decreased between these two images?”, I am not really asking for a sentence. I am asking for an analysis, a spatial result, and an explanation of that result.

That distinction shaped how I approached SatQuery AI.

The Problem With Text-Only Satellite Analysis

SatQuery AI is a conversational intelligence layer for Earth-observation and satellite-image analysis. The idea is straightforward: instead of forcing users through a sequence of GIS operations, they describe what they want in natural language.

A conventional workflow might look like:

Select Dataset
      ↓
Preprocess
      ↓
Choose Model
      ↓
Configure Parameters
      ↓
Run Analysis
      ↓
Interpret Results

SatQuery tries to put a conversational interface in front of that complexity:

Ask a Question
      ↓
Receive an Analysis

A user can ask:

“Where has vegetation decreased in this area?”

Or:

“What changes occurred between these two satellite images?”

Or:

“Detect buildings in this region.”

The important part is that the language model is not supposed to simply generate an answer and call it analysis.

That would create a dangerous boundary.

A model can produce a perfectly reasonable-sounding explanation without actually establishing what changed in the imagery.

For SatQuery, the language model determines what the user wants. The underlying analysis produces the evidence.

Separating Language From Evidence

I think of the architecture as a sequence of boundaries:

Natural Language
      ↓
Query Understanding
      ↓
Analysis Planning
      ↓
Remote-Sensing Processing
      ↓
Evidence
      ↓
Visualization
      ↓
Natural-Language Explanation

That separation is more important than the chat interface itself.

Suppose the user asks:

“Show me where vegetation decreased between these images.”

The system needs to understand several things hidden inside that sentence.

There are two images involved. The subject is vegetation. The requested operation involves comparison and change detection. The output needs to identify where the change occurred.

Conceptually, the query can become something like:

analysis = {
    "target": "vegetation",
    "operation": "change_detection",
    "comparison": True,
    "output": "spatial_regions"
}

That structure is then useful to the analysis layer.

The important thing is that the final result does not originate from the language model's imagination. It comes from processing the imagery.

The AI can explain the result, but the result needs to exist independently of that explanation.

Two Very Different Systems

There is a fundamental difference between these two architectures.

The first is:

User Question
     ↓
Language Model
     ↓
Textual Answer

The second is:

User Question
     ↓
Query Understanding
     ↓
Analysis
     ↓
Evidence
     ↓
Visualization
     ↓
Explanation

The second architecture is what SatQuery is designed around.

If the system concludes that vegetation decreased, I want the user to be able to see the regions associated with that conclusion.

The system can produce things such as detected regions, change areas, percentages, confidence information, object counts, and other geospatial information depending on the analysis being performed.

That gives the conversation something concrete to refer to.

Instead of:

“Vegetation appears to have decreased in the northern region.”

the user can see the corresponding region highlighted on the imagery.

The explanation and the visualization reinforce each other.

Why Visualization Is Part of the Evidence

Geospatial information has an awkward property: location is part of the meaning.

Knowing that an object was detected is useful.

Knowing where it was detected is often more useful.

The same applies to change detection. A statement such as “vegetation decreased” leaves several questions unanswered:

Where?

How much?

Compared with what?

Which pixels or regions produced that conclusion?

SatQuery therefore treats visualization as part of the analytical loop rather than merely decoration around the result.

The conceptual pipeline is:

Question
   ↓
Analysis
   ↓
Detected / calculated evidence
   ↓
Map or satellite-image visualization
   ↓
Natural-language explanation

This also gives the user a way to inspect the result instead of accepting a generated explanation blindly.

Then the Conversation Gets Interesting

The next problem appears when users ask follow-up questions.

Imagine the interaction starts with:

User: Show me where vegetation decreased between these images.

SatQuery performs the analysis and highlights the relevant regions.

Then:

User: How large are those areas?

The phrase “those areas” is meaningless without the previous context.

The user could have said:

“How large are the regions where vegetation decreased in the previous comparison?”

But humans do not normally talk like APIs.

The next question might be:

User: Now compare them with the previous region we analyzed.

Now the system needs to understand references to multiple pieces of previous analytical context.

This is where Hindsight becomes an important part of the architecture.

Adding Hindsight to the Conversation

SatQuery AI uses Hindsight as its agent-memory layer.

The purpose is not simply to remember that a conversation happened.

The useful question is:

What information from the conversation should still matter when the user asks something later?

For example, a previous interaction might establish the imagery being compared, the region being discussed, the type of analysis being performed, or the result that the user wants to reference later.

A simplified conceptual flow looks like this:

context = recall_relevant_memory(current_query)

analysis = plan_analysis(
    query=current_query,
    context=context
)

result = run_analysis(analysis)

retain_useful_context(
    query=current_query,
    result=result
)

The memory layer sits alongside the analytical pipeline rather than replacing it.

That distinction matters.

Hindsight provides conversational context. It does not turn remembered context into ground truth.

The actual satellite analysis still has to produce the evidence.

Hindsight's documentation describes its approach to agent memory, while Vectorize's explanation of agent memory provides the broader context for why persistent memory is useful for agents.

Before and After Memory

Without useful memory, the interaction can degrade into repeated clarification:

User: Show me where vegetation decreased.

System: Here are the detected regions.

User: How large are those areas?

System: Which areas are you referring to?

The user has to reconstruct context that was already established.

With relevant memory available:

User: Show me where vegetation decreased.

System: Here are the detected regions.

User: How large are those areas?

The system can use the previous analytical context to interpret “those areas” and continue the interaction.

The difference is small from a UI perspective, but significant architecturally.

The system has moved from handling isolated requests to handling an evolving analytical conversation.

Memory Has Its Own Failure Mode

Adding memory does not automatically make the system correct.

In fact, it introduces another thing that can go wrong.

If the system recalls irrelevant context, a perfectly reasonable current query could be interpreted against the wrong previous analysis.

For example, imagine a user analyzed vegetation in one region, then moved to another region and asked a similar question. If the system incorrectly carries the old region into the new request, the conversational experience becomes misleading.

That is why I would treat memory as context for reasoning, not unquestionable truth.

The current request and the actual analytical evidence still need to determine what the system ultimately does.

This is one of the more important architectural boundaries in SatQuery:

Remembered Context
        +
Current Query
        ↓
Analysis Planning
        ↓
Actual Evidence

Memory helps the system understand the conversation. The analysis determines what the imagery actually shows.

What I Learned

1. A generated explanation is not an analytical result

The language model should help interpret and explain the user's request and the resulting evidence. It should not be the only source of that evidence.

2. Geospatial results need spatial context

For satellite analysis, showing a number or sentence without showing where it applies throws away important information.

3. Conversational interfaces need more than conversation history

Follow-up questions often depend on earlier analytical decisions and results. Persistent agent memory gives the system another mechanism for carrying useful context forward.

4. Memory should inform analysis, not override it

A recalled memory can help resolve “those areas” or “the previous region,” but it should not be treated as proof that the current imagery contains a particular result.

5. The architecture matters more than the chatbot

The chat interface is the visible part of SatQuery. Underneath it are several separate responsibilities: understanding language, planning analysis, producing evidence, visualizing results, explaining them, and maintaining useful memory.

Keeping those responsibilities separate makes the system easier to reason about.

Building Toward an Earth Observation Control Room

The broader vision for SatQuery is an Earth Observation Control Room where users can communicate with geospatial information naturally.

The underlying complexity does not disappear.

Remote-sensing analysis still requires appropriate processing. Computer vision models still have limitations. Geospatial data still needs to be handled carefully.

What changes is the interface between the user and that complexity.

Instead of asking users to learn the machinery first, SatQuery starts with the question.

And the architecture I keep coming back to is simple:

Ask
 ↓
Understand
 ↓
Analyze
 ↓
Verify
 ↓
Visualize
 ↓
Explain

Hindsight adds another dimension to that loop:

          ┌──────────────┐
          │   Hindsight  │
          │    Memory    │
          └──────┬───────┘
                 ↓
Ask → Understand → Analyze → Verify → Visualize → Explain

The goal is not to make satellite imagery talk.

It is to make the entire analytical process easier to navigate while keeping the evidence visible underneath the conversation.

DEV Community: Lakshmi Chaitanya