- A spatial agent workflow starts with a bounded request and ends with a reviewable result, not a chat response.
- Deterministic tools should calculate geometry, units, topology, and file properties. Models should interpret selected evidence and state uncertainty.
- The system must preserve evidence, decisions, failures, and the next permitted action so work can be checked or resumed.
A useful spatial agent does more than return an answer. It gathers the evidence needed for a bounded spatial question, chooses tools that can perform exact operations, preserves what happened, and leaves a reviewer with enough information to accept, question, or reject the result.
This article describes the workflow as a sequence. The sequence is a design model drawn from applied research and retained implementation work. It is not a claim that every system already provides each step.
The complete path
The working path is:
Request
State the spatial question, the intended decision, the deliverable, and the authority boundary.
Intent and context
Build a bounded task packet with the subject, location, time, sources, restrictions, and unresolved questions.
Governed action
Choose the next permitted retrieval, computation, inspection, or proposal. Keep the authoritative record protected.
Runtime and tool
Run exact spatial operations in a suitable GIS or code environment. Use model judgement only where interpretation is needed.
Evidence and verification
Store source references, intermediate observations, derived geometry, checks, artefacts, and failure states.
Review
Return a proposed result with its evidence and choose Act, Review, Ask for more evidence, or Refuse.
The request
Start with the work someone needs to complete. A request such as “locate the relevant road feature and prepare a proposed update” is not yet an executable task. The system needs to know what counts as a feature, which place and time are in scope, which sources may be used, what output must be produced, and who can approve a change. NIST's AI Risk Management Framework similarly calls for documented context, roles, responsibilities, and human-AI oversight, although it is not specific to spatial work. [5]
A bounded request also states what the system must not do. It may be allowed to collect evidence and prepare a proposal, while the authoritative spatial record remains unchanged until review.
Practical test: give the request to a second practitioner. If they cannot identify the expected deliverable, evidence boundary, and acceptance authority, the system does not have enough context to act.
Intent and context
The next step turns the request into a task packet. This is more than a prompt. It is a bounded record of the spatial subject, location, time, source provenance, requested output, constraints, open questions, and the evidence required for review.
Context should remain inspectable. A short conversational summary can be useful for a person, but it is not enough to resume a workflow or audit a decision. The task packet needs references to the underlying evidence and the assumptions used to interpret it. W3C PROV supplies a public model for connecting entities, activities, and agents; a spatial workflow still has to add its own task and evidence semantics. [4]
Governed action
With context in place, the system selects the next action. It may request another image, run a spatial calculation, inspect a project, compare an artefact, or prepare a proposal. Each action should have a typed input, an explicit output, and a permission boundary.
The agent should not have unrestricted access simply because a tool is available. A governed surface limits the sources, operation, area, output fields, and side effects. It also records why the action was selected and what evidence it is expected to add.
Action record
Runtime and tools
Spatial work crosses several environments. A GIS application can reveal how a project, layer, style, or edit behaves in its native context. Code can calculate geometry and compare structured outputs. Imagery can provide visual evidence. A model can interpret selected evidence and suggest the next question.
The important boundary is the operation itself. Use deterministic computation for a result that has a defined mathematical or file-level answer. Use model judgement for interpretation, ranking competing explanations, or deciding which missing evidence would reduce uncertainty. Keep both results separate in the record. The OGC Simple Features standard defines common geometry concepts, and PostGIS exposes concrete spatial-reference and validity operations that implement part of that exact layer. [1] [3]
Model judgement
Interpret an image, compare competing descriptions, identify a missing question, or explain why evidence is insufficient.
Deterministic computation
Calculate distances, intersections, areas, coordinate transforms, counts, topology checks, and file-level comparisons.
Human authority
Approve a consequential change, resolve an unresolved conflict, or accept a result when the evidence does not settle the question.
A model may propose a coordinate, road attribution, or feature interpretation. That proposal is an observation about the evidence, not a verified spatial fact. Geometry, coordinate transforms, spatial relationships, and output integrity need independent checks.
Evidence and verification
A reviewable result keeps the witnesses visible. The record should distinguish the original source, an observation extracted from it, geometry derived by a tool, an interpretation proposed by a model, and a check performed independently.
Verification should be specific to the output. Depending on the task, inspect geometry validity, coordinate reference system, units, extent, topology, attributes, source lineage, file integrity, rendering, and the result after reopening it in the relevant GIS software. A visual match can support a check, but it does not replace a structured comparison. Format rules also matter: RFC 7946 fixes GeoJSON coordinates to WGS 84 longitude and latitude in decimal degrees, so a different assumption is a detectable contract failure. [2]
Evidence rule: do not count several derived views as independent confirmation when they all come from the same source. Record the provenance and the limits of each check.
Review and disposition
Review is part of the workflow, not a final decoration. The reviewer needs the request, the evidence packet, the proposed result, the checks that ran, the checks that did not run, and the unresolved alternatives.
Act
The defined authority accepts the result and the permitted change can proceed.
Review
The result is useful but a person must resolve an uncertainty or approve a side effect.
Ask for more evidence
The available sources do not settle the question, but a specified next source may help.
Refuse
The task exceeds the evidence, permission, safety, or validation boundary.
This separation keeps a plausible proposal from becoming an operational fact. It also gives the system a useful outcome when the answer is incomplete. Asking for evidence or refusing is part of doing spatial work safely.
State and recovery
Long-running spatial work cannot depend on the last chat message. A durable checkpoint should preserve the task identity, request, evidence references, hypotheses, completed actions, tool outputs, budgets, failures, reviewer decisions, and next permitted action.
The checkpoint does not need to store every raw input in one place. It does need stable references, enough metadata to reproduce the interpretation, and a clear distinction between an authoritative source and a temporary proposal.
The evidence does not identify the object
Record the competing hypotheses and request the next useful source or inspection. Do not turn a plausible interpretation into a confirmed feature.
The runtime cannot perform the requested operation
Save the failure, environment details, and permitted alternatives. A retry should be deliberate and idempotent, not an unbounded loop.
The structured result is invalid
Reject it at the schema boundary, preserve the raw output for diagnosis, and ask for a corrected proposal without changing the source record.
A check disagrees with the proposal
Keep both the proposal and the check visible. Route the item to review or request new evidence instead of hiding the disagreement.
The workflow is interrupted
Resume from the last durable checkpoint with its evidence references, completed actions, open questions, budget, and next permitted action.
How to test the workflow
A useful test covers the complete path, not just the model response. Use a known task packet and a small, inspectable fixture. Define the expected evidence, the deterministic checks, the review boundary, and the valid failure states before running the system.
Can another person reconstruct the request and intended output?
Does every tool action name its inputs, output schema, permission, and retry rule?
Are model interpretations separate from geometry and file calculations?
Can a reviewer inspect the source, proposal, checks, and unresolved alternatives?
Can the workflow resume after an interruption without repeating a side effect?
Does it return Review, Ask for more evidence, or Refuse when the evidence is insufficient?
When not to use this
This workflow adds setup and review work. Use a direct GIS operation when the task is simple, one-off, and already well understood. Do not introduce an agent when there is no suitable evidence, no person who can review the result, or no safe way to constrain its actions.
A direct GIS command is easier to inspect and repeat.
The task depends on undocumented judgement that has not been captured.
The source data has unresolved quality, CRS, schema, or geometry problems.
A wrong result could affect safety or a consequential decision without a meaningful review boundary.
The proposed evidence cannot support the requested level of certainty.
What this method establishes
A spatial agent is easier to evaluate when the system exposes the path from request to review. The useful unit is the complete workflow: evidence, context, governed actions, runtime, tools, state, checks, failures, and authority.
This method does not make an uncertain observation certain. It makes the uncertainty visible, gives exact operations a suitable place to run, and leaves a record that another person can inspect. That is the minimum needed before a proposed spatial result can become trusted work.
Sources and boundary
The six-stage workflow is an Axis Spatial research model, not a published industry standard or a measured product result. The sources below support the externally checkable geometry, provenance, validation, and governance concepts. They do not prove that this complete workflow is implemented or effective for every task.
Related research
The research programme collects the current questions, methods, and evaluation boundaries behind this work.