What to Do When an AI-Assisted Result Looks Wrong

If an AI-assisted result in Geobble looks wrong, do not start by asking for the same operation again.

First determine what is wrong:

• the input data;

• the geographic interpretation;

• the requested operation;

• an assumption such as distance, units, or filtering;

• the generated result;

• or only the way the result is displayed.

Then correct the relevant part of the workflow.

A useful review sequence is:

Unexpected result
      ↓
Check objective
      ↓
Check input data
      ↓
Check geographic assumptions
      ↓
Check operation
      ↓
Check result
      ↓
Check presentation
      ↓
Correct, reject, rerun, or restore

The fact that a result was generated successfully does not mean that it is geographically or analytically correct.

Start with the question you actually asked

Return to the original objective.

Ask:

What did I intend this operation to answer or produce?

For example:

Which settlements are more than 30 minutes from a hospital?

is different from:

Which settlements are more than 30 kilometres from a hospital?

And:

Which districts have the fewest hospitals?

is different from:

Which districts have the lowest number of hospitals per resident?

A result can be technically valid while answering a different question from the one you intended.

Before debugging the map, make sure the objective itself is clear.

1. Check the Sources used

One of the most common causes of an unexpected result is the wrong input data.

Inspect the Sources available to the Project and ask:

• Is this the intended dataset?

• Is the geographic coverage correct?

• Is the reference date appropriate?

• Does it contain the features I expected?

• Are the required attributes present?

• Is there another similarly named Source in the Project?

• Is this a derived result rather than the original dataset?

For example, a Project might contain:

Population Census 2015
Population Estimate 2025
Population Projection 2030

A request such as:

Compare population by district.

is ambiguous unless the intended population Source is clear.

If the result appears wrong, verify which data should be used before changing the analysis itself.

2. Inspect the Source independently

If you suspect the input data, open the Source itself.

Check:

• feature locations;

• geographic extent;

• feature count;

• geometry type;

• important attributes;

• null or missing values;

• metadata and limitations.

For example, if an accessibility result looks strange because several hospitals appear to be missing, determine whether those facilities exist in the Source before blaming the accessibility calculation.

The problem may be upstream:

Incomplete Source
      ↓
correct analysis
      ↓
incomplete result

A correct operation cannot recover features that are absent from its input.

3. Check whether the right field was used

Datasets often contain several fields with similar meanings.

For example:

population_2015
population_2025
population_density
households

or:

operator
owner
manager
facility_type

A result using the wrong property can still look plausible.

If the analysis depends on an attribute, verify that the chosen field actually represents the concept you intended.

Do not rely only on the field name.

Where needed, inspect representative values and the Source metadata.

4. Check filters

A filter can radically change a result while leaving the map visually convincing.

Suppose a health-facility Source contains:

status = operational
status = closed
status = planned

A request to analyse healthcare access may intend only operational facilities.

If the filter was omitted, the resulting accessibility may be too optimistic.

The opposite can also happen: an unintended filter may remove most of the features.

When a layer appears unexpectedly sparse or dense, ask:

Is a filter excluding or including features I did not intend?

5. Check geographic scope

Make sure the analysis is being performed over the intended area.

For example:

Find schools within 10 km of these settlements.

may produce an unexpected result if the wrong settlement Source covers the whole country while you intended only one region.

Likewise, a map may simply be showing the wrong viewport.

Before changing the underlying analysis because you cannot see an expected feature, check:

• the current extent;

• layer visibility;

• zoom range;

• filters;

• Source extent.

Sometimes the feature exists but is outside the current view or hidden at the current zoom level.

6. Check place-name ambiguity

Geographic names are often ambiguous.

A place name may refer to:

• several settlements;

• a district and a city;

• similarly named features in different countries;

• different administrative levels.

For example:

Victoria

or:

Bafang

may require more context than the name alone.

If a result appears in the wrong location, check whether the place itself was resolved correctly.

Useful clarification can include:

• country;

• region;

• administrative level;

• nearby places;

• coordinates.

Instead of:

Analyse Buea.

prefer, where ambiguity matters:

Analyse Buea, South-West Region, Cameroon.

Do not correct a bad geographic match by merely moving the map camera to where you expected the result to appear.

7. Check distance and measurement assumptions

Distance questions are especially easy to misunderstand.

For example:

Which villages are within 10 km of a hospital?

could mean:

• straight-line distance;

• road-network distance;

• travel distance;

• travel time.

Those are not interchangeable.

Similarly:

5 km buffer

is different from:

5 minute drive-time area

When distance-related output looks wrong, identify the measurement method before adjusting the result.

8. Check the units

Always verify units when the result depends on:

• distance;

• area;

• speed;

• time;

• population density;

• other derived measurements.

For example:

500

has no useful meaning by itself if one part of the workflow interprets it as metres and another as kilometres.

A suspiciously large or small result is often a reason to check units.

Ask explicitly when necessary:

Recalculate this using a 5 kilometre buffer.

rather than:

Make the buffer 5.

9. Check the CRS assumptions

Coordinate reference systems can affect distance, area, and positional interpretation.

If a geometric operation produces surprising dimensions or locations, check whether the underlying geographic assumptions are appropriate.

Examples of warning signs include:

• buffers much larger or smaller than expected;

• features appearing in the wrong country;

• areas that seem implausible;

• coordinates interpreted in the wrong order;

• geographic and projected units being confused.

Do not assume that a geometrically valid result is automatically meaningful simply because it renders.

10. Check the operation itself

Make sure Geobble performed the type of spatial operation you intended.

For example:

Filter

answers a different question from:

Spatial intersection

and:

Buffer

answers a different question from:

Travel-time reachability

Likewise:

Join

can mean different relationships depending on how the data should be matched.

If the result is unexpected, reformulate the operation precisely.

Instead of:

Combine these datasets.

try:

Join each health facility to the district polygon that contains it.

Or:

Keep only settlements that intersect the 5 km facility buffers.

Specific spatial relationships are easier to verify than vague requests.

11. Check aggregation assumptions

Summary results require particularly careful review.

Suppose a Project reports:

District A has the highest number of facilities.

Ask:

• Were facilities counted by location?

• Were duplicate features present?

• Were closed facilities included?

• Were facilities joined to exactly one district?

• Is raw count actually the measure you need?

• Should the result be normalised by population or area?

The arithmetic can be correct while the analytical interpretation is inappropriate.

For example:

50 hospitals

does not automatically imply better coverage than:

25 hospitals

if the first district has ten times the population.

12. Distinguish an analytical problem from a styling problem

Sometimes the data is correct and only the map looks wrong.

For example:

Correct polygons
+
poor colour scale
=
misleading-looking map

or:

Correct points
+
layer hidden below polygons
=
apparently missing data

Presentation problems can involve:

• layer order;

• opacity;

• classification;

• colours;

• labels;

• visibility;

• zoom ranges;

• legend;

• popups.

Use Studio when the result is analytically correct but needs direct cartographic correction.

See How to Continue Project Work in Studio.

Do not use styling to hide an analytical problem

The reverse is equally important.

If a buffer was calculated using the wrong distance, changing its colour does not fix the analysis.

If the wrong Source was joined, hiding the suspicious layer does not make the result correct.

Use this distinction:

Wrong data or computation
→ fix the analysis

Correct data, poor visual presentation
→ fix the map

13. Ask Geobble to clarify or revise the operation

When the problem is in Project-assisted work, describe what appears wrong and what you expected instead.

For example:

This appears to include closed facilities. Recalculate using only facilities whose status is operational.

or:

These buffers look too large. Confirm the distance and units used, then recreate them as 5 kilometre buffers.

or:

The result seems to use the 2015 population Source. Use the 2025 estimate instead.

or:

I meant travel time on the road network, not straight-line distance.

A correction is more effective when it identifies the suspected assumption.

Avoid repeatedly saying:

That's wrong. Try again.

without explaining what looks wrong.

14. Inspect Project history after an unwanted map change

Project map changes are recorded in History.

History entries can identify:

• the version;

• type of change;

• whether it was authored by AI or a user;

• when the change occurred;

• available description of the change.

This can help answer:

Which change made the map stop looking correct?

For example:

v14  Spec patch      AI
v13  Spec patch      User
v12  Resource added  User

can make it easier to locate the point before an unwanted map modification.

15. Restore an earlier map state when appropriate

If a Project map change is clearly undesirable and an earlier history entry contains the state you want, use:

Restore to this version

Geobble asks for confirmation before restoring.

The restore creates a new history version containing the restored map specification rather than deleting the later history.

Conceptually:

v10 → correct map
v11 → unwanted change
v12 → another unwanted change

Restore v10
      ↓
v13 → restored state

This preserves a record of what happened.

History restore is not a universal undo button

Use restore carefully.

The current Project restore operation restores the saved map specification associated with that history version.

Do not assume it reverses every external consequence of earlier work.

For example, restoring a map state should not be treated as automatically:

• deleting a Source that was created elsewhere;

• reversing an enrichment committed to a Source;

• undoing an external PostGIS change;

• restoring resource access;

• undoing a published Map.

Those are separate resources and workflows.

Use History for restoring Project map state—not as a substitute for understanding what changed elsewhere.

16. Review extraction candidates before saving them

For Extract Features, unexpected AI output should normally be handled in the review stage.

A candidate can be:

• corrected;

• approved;

• rejected.

Check:

• the evidence;

• feature identity;

• geometry resolution;

• extracted attributes.

Do not save a candidate merely because it was successfully generated.

For example:

Document says:
"Hospital in Buea"

Candidate resolves:
Buea, another country

The extraction is not correct simply because a point was produced.

Correct the match or reject the candidate.

See How to Extract Geographic Features from a Document.

17. Review enrichment values before committing them

The same principle applies to Enrich Source.

Compare:

Current

with:

Proposed

and inspect the evidence.

If the proposed value is wrong:

• edit it when the correct value is supported;

• reject it when unsupported;

• do not approve it simply to complete the review queue.

For example:

Current operator:
Ministry of Public Health

Proposed:
Private

could indicate:

• a genuine change;

• outdated evidence;

• incorrect feature matching;

• different definitions;

• extraction error.

Investigate before replacing the existing value.

See How to Enrich an Existing Source.

Review-first workflows are easier to correct before Save

Extraction and enrichment intentionally separate:

generation

from:

commit

The safest time to catch an AI-assisted error is before approved results are saved into a Source.

Use the review controls.

Do not treat approval as administrative housekeeping.

It is part of the data-quality workflow.

18. Check evidence provenance

When AI-assisted work depends on evidence, ask:

Is the evidence itself reliable enough?

A model can correctly interpret a document that is outdated or wrong.

For example:

2022 report:
Facility A is operational

does not prove:

Facility A is operational in 2026

Likewise, two sources may disagree.

Consider:

• publication date;

• source authority;

• geographic scope;

• definitions;

• whether the evidence refers to the same entity.

The AI cannot make weak evidence authoritative simply by extracting it accurately.

19. Check derived-result lineage

When a Project creates a derived geographic result, remember that the result inherits assumptions from its inputs and operation.

Conceptually:

Source A
+
Source B
+
filter
+
spatial operation
+
parameters
      ↓
Derived result

If the result looks wrong, inspect that chain.

Changing only the final layer styling may leave the original error untouched.

Useful questions include:

• Which Sources created this result?

• What operation was performed?

• What distance or threshold was used?

• Which filters were active?

• Was this a preview or a durable derived result?

• Does the resulting feature count make sense?

20. Compare against a small known example

When possible, test the logic against an example whose expected result you already understand.

Suppose you are unsure whether a spatial join is behaving correctly.

Instead of immediately trusting the nationwide output, choose:

• one district;

• several known facilities;

• one boundary;

• a small subset.

Then ask:

Do these known features produce the expected relationship?

Small examples make mistakes easier to see.

Once the logic is verified, apply it to the larger dataset.

21. Use independent checks for important results

For consequential analysis, do not rely exclusively on visual plausibility.

Where appropriate, compare with:

• known totals;

• an authoritative dataset;

• a GIS calculation performed independently;

• representative records;

• published statistics;

• manual spot checks.

For example, if a result says a district contains:

2 health facilities

and an authoritative registry lists:

27

that discrepancy deserves investigation before publication.

The purpose is not to distrust every generated result.

It is to match the level of verification to the importance of the decision being made.

A plausible map can still be wrong

Maps are particularly good at making results look convincing.

A clean choropleth, attractive symbols, and a polished legend can create a sense of confidence even when:

• the wrong field was used;

• a join duplicated records;

• data is outdated;

• the wrong units were applied;

• a place was misidentified.

Treat visual quality and analytical validity as separate questions.

Ask both:

Does the map look clear?

and:

Is the map actually showing the correct thing?

22. Do not publish an unresolved result

If you cannot explain an unexpected result, keep it in the working Project.

Do not make uncertainty disappear by publishing the map.

Before publication, you should be able to explain:

• what the result represents;

• which data produced it;

• the important assumptions;

• known limitations.

If the answer is still:

I'm not sure why Geobble produced this.

the work is not ready for an audience.

See How to Publish an Interactive Map.

Example: a buffer looks much too large

Suppose you ask:

Create a 5 km buffer around these facilities.

The resulting polygons appear enormous.

Review in this order:

1. Check the Source

Are the facilities in the expected location?

2. Check the request

Did you clearly specify:

5 kilometres

rather than an ambiguous numeric value?

3. Check the resulting operation

Is it genuinely a 5 km spatial buffer rather than another type of distance result?

4. Compare with a known scale

Does the result make geographic sense relative to a known distance?

5. Correct the operation

Ask Geobble to recreate the result with the intended distance and units.

Do not solve the problem by reducing polygon opacity.

Example: an accessibility map seems too optimistic

Suppose almost every settlement appears easily accessible to hospitals.

Check:

1. Were closed facilities included?

2. Is the correct hospital Source being used?

3. Is accessibility based on straight-line distance or road travel time?

4. Is the road network appropriate?

5. Is the time threshold correct?

6. Are settlements represented correctly?

7. Were missing or inaccessible network areas handled as expected?

Only after reviewing those assumptions should you conclude that the underlying accessibility pattern itself is surprising.

Example: enrichment wants to replace a trusted value

Suppose:

Current:
Central Government

Proposed:
Municipal Council

Before accepting:

1. inspect the evidence;

2. verify the feature match;

3. compare evidence dates;

4. check whether “operator” and “owner” are being confused;

5. edit or reject the proposal if necessary.

Do not approve a replacement merely because the enrichment system found a different value.

Example: the AI changed the map in an unwanted way

Suppose you ask:

Make the facilities easier to see.

and the resulting map changes more than you intended.

First, tell the assistant specifically what should be corrected.

For example:

Keep the facility styling change, but restore the previous district styling and layer order.

If the map state is substantially wrong, inspect History.

Find the last known-good version and, where appropriate, restore that map specification.

Then make a narrower request.

Better correction requests

When correcting AI-assisted work, describe the difference between:

what happened

and:

what you intended

Good:

The analysis used all facilities. I only want records where status is operational. Keep the same 30-minute travel-time threshold and rerun it.

Good:

The labels are correct, but the district polygons should remain unchanged. Revert only the polygon styling.

Good:

This point appears to resolve to the wrong Bafang. Use Bafang in West Region, Cameroon.

Less useful:

Wrong.

or:

Try again.

Precise corrections reduce the chance that a second attempt introduces another unrelated change.

A practical diagnostic order

When something looks wrong, use this order:

1. Objective

What was the intended result?

2. Inputs

Were the correct Sources, fields, dates, and geographic features used?

3. Geographic interpretation

Were places, units, distances, CRS assumptions, and spatial relationships interpreted correctly?

4. Computation

Was the intended filter, join, buffer, aggregation, or accessibility method used?

5. Output

Does the resulting geometry or table match the operation?

6. Presentation

Is the result merely obscured or misrepresented by styling, labels, layer order, or zoom?

7. Recovery

Should you revise the request, reject a proposal, rerun an operation, or restore an earlier Project map state?

That order avoids spending time restyling the wrong data.

When to report a product problem

A result may indicate a Geobble problem rather than an input or interpretation problem when:

• the same well-defined operation repeatedly produces an inconsistent result;

• a known-good Source is processed incorrectly;

• the requested parameters are clearly correct but the output contradicts them;

• Project behaviour does not match the operation that was confirmed;

• a reproducible failure persists after the inputs have been verified.

When reporting it, include useful context such as:

• Project or Source involved;

• approximate time;

• what you requested;

• what you expected;

• what happened instead;

• relevant non-sensitive screenshots;

• whether the problem is reproducible.

Avoid sharing passwords, database connection strings, private credentials, or sensitive data that is unnecessary to reproduce the problem.

Quick review checklist

When an AI-assisted result looks wrong:

• I restated the intended objective.

• I checked the Source or Sources being used.

• I checked relevant fields and representative values.

• I checked filters.

• I checked geographic scope and place resolution.

• I checked distance method and units.

• I checked important CRS assumptions.

• I confirmed the intended spatial operation.

• I checked aggregation and join assumptions.

• I distinguished computation problems from styling problems.

• I inspected evidence for extraction or enrichment proposals.

• I compared important results with known examples where possible.

• I used Project History when an unwanted map-specification change needs recovery.

• I resolved uncertainty before publishing.