ANASSA：从高层框架到低层架构的空间智能体人工智能

# ANASSA: From High-Level Framework to Low-Level Architecture for Spatial Agentic AI
Source: [https://arxiv.org/html/2610.14382](https://arxiv.org/html/2610.14382)
\\@ACM@balancefalse

CCS:Information systems Geographic information systemsCCS:Computing methodologies Artificial intelligenceCCS:Computing methodologies Multi\-agent systems© none

###### Abstract\.

Agentic AI systems operating over geospatial data require more than autonomous reasoning and tool use; they must also support explicit orchestration, spatial validation, governance, provenance, failure handling, and human decision authority\. Prior work introduced ANASSA, an agentic AI orchestration framework for spatial intelligence that established high\-level components and responsibility boundaries for governed agentic execution\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. However, the framework did not specify how those high\-level responsibilities should be systematically decomposed into an implementation\-facing low\-level architecture\.

This paper addresses that gap by applying Design Science Research \(DSR\) to refine the ANASSA framework from high\-level architectural \(HLA\) responsibilities into a low\-level architecture \(LLA\)\. The resulting design preserves the responsibility boundaries of the foundational framework while translating them into executable architectural structures, including 47 logical roles, versioned task graphs, capability\-based agent selection, typed contracts, explicit runtime states, spatial validation mechanisms, governance controls, failure and recovery paths, and provenance records\.

The architecture is demonstrated through an end\-to\-end execution trace and analytically evaluated for requirements traceability, internal consistency, responsibility preservation, and technology independence\. The resulting high\-level\-to\-low\-level design provides an implementation\-facing bridge between the ANASSA framework and future system implementations, defining how governed spatial agentic workflows can be made inspectable, reconstructable, and testable without binding the architecture to a specific AI model, geospatial platform, communication protocol, or deployment environment\.

###### Keywords:

geospatial agentic AI, spatial intelligence, design science research, software architecture, multi\-agent orchestration, high\-level architecture, low\-level architecture, task graphs, typed contracts, spatial validation, provenance, governance

## 1\.Introduction

Geospatial operations increasingly depend on AI systems that can interpret objectives, reason over spatial and temporal context, invoke analytical capabilities, validate claims, and coordinate actions across heterogeneous data and execution environments\. Recent geospatial\-agent research demonstrates the value of structured workflows, specialized roles, tool invocation, retrieval, and feedback\-driven execution, while also exposing persistent limitations in tool sequencing, spatial grounding, parameter inference, heterogeneous data handling, and long\-chain robustness\([Wang et al\., 2024](https://arxiv.org/html/2610.14382#bib.bib9);[Xi and others, 2023](https://arxiv.org/html/2610.14382#bib.bib10);[Hashemi and Züfle, 2026](https://arxiv.org/html/2610.14382#bib.bib5);[Hu et al\., 2025](https://arxiv.org/html/2610.14382#bib.bib6);[Bao et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib2);[Bhattaram et al\., 2025](https://arxiv.org/html/2610.14382#bib.bib3);[Liang et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib8);[Yu et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib11)\)\. These limitations are not only model limitations\. They are system\-design problems concerning how intent, reasoning, execution, evidence, governance, validation, recovery, and learning are connected\.

Papantoniou and Hilton introduced ANASSA \(Autonomous Neural Agents for Spatial Systems Architecture\) as an agentic AI orchestration framework for spatial intelligence and established the framework\-level architecture used as the starting point for this study\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. Rather than restating that specification, the present study treats its component boundaries, governance and evidence constraints, interface requirements, and evaluation limits as inherited design inputs, specifically, as high\-level architectural \(HLA\) responsibilities\. The new work begins where that baseline stops: at the systematic refinement of those responsibilities into an implementation\-facing low\-level architecture \(LLA\)\.

The remaining design problem is therefore not whether ANASSA should contain these capabilities, but how the high\-level framework should be transformed into a coherent design solution that is precise enough to guide implementation while preserving its geospatial, governance, and traceability properties\. A high\-level architecture identifies responsibility boundaries and major relationships\. An implementation\-facing design must additionally specify logical roles, interface contracts, runtime states, capability resolution, failure semantics, validation paths, policy controls, and provenance records\. It must also remain independent of a particular model provider, geospatial platform, cloud, or protocol so that the architecture does not collapse into a vendor\-specific implementation\.

This paper addresses that design problem using Design Science Research \(DSR\)\. DSR is appropriate when research advances knowledge through the purposeful creation and evaluation of artifacts that address a relevant problem\([Hevner et al\., 2004](https://arxiv.org/html/2610.14382#bib.bib13);[Peffers et al\., 2007](https://arxiv.org/html/2610.14382#bib.bib14);[Gregor and Hevner, 2013](https://arxiv.org/html/2610.14382#bib.bib15)\)\. Following the DSR process of problem identification, objectives for a solution, design and development, demonstration, evaluation, and communication\([Peffers et al\., 2007](https://arxiv.org/html/2610.14382#bib.bib14)\), this study treats the inherited ANASSA framework as kernel knowledge and a design input\. The research artifact is the HLA\-to\-LLA refinement design: the responsibility interpretation, decomposition method, implementation\-facing LLA, contracts, runtime semantics, and evaluation criteria that make the refinement explicit and testable\.

The paper makes five contributions:

1. \(1\)It applies a DSR methodology to translate the foundational ANASSA framework into an implementation\-facing design artifact with explicit problem, objectives, requirements, design principles, demonstration, and evaluation criteria\.
2. \(2\)It derives functional and non\-functional design requirements for governed geospatial agentic AI and formalizes eight design principles that constrain how ANASSA responsibilities are decomposed\.
3. \(3\)It interprets the inherited four\-layer C1–C11 structure as an HLA responsibility model, making ownership, governance and evidence boundaries, and implementation surfaces explicit without redefining the foundational framework\.
4. \(4\)It specifies an implementation\-facing LLA that refines the inherited architecture through logical\-role decomposition, versioned task graphs, capability resolution, a canonical contract schema, observable runtime states, spatial validation, policy controls, bounded recovery, and provenance\.
5. \(5\)It evaluates the design artifact through requirements\-to\-design traceability, internal consistency analysis, an end\-to\-end synthetic demonstration, and technology\-independence analysis while reserving empirical performance evaluation for a subsequent reference implementation\.

The contribution is therefore the systematic refinement design and its implementation\-facing specification, not a performance claim\. The foundational ANASSA study defines the framework\-level baseline\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\); the present study explains how that baseline is refined into a coherent HLA\-to\-LLA system design, while subsequent work can instantiate and benchmark the design\.

## 2\.Related Work and Architectural Positioning

Recent geospatial\-agent systems increasingly use structured workflows, specialized roles, and runtime tool execution, but they emphasize different parts of the autonomy problem\. Spatial\-Agent formalizes geospatial question answering as concept transformation into executable GeoFlow graphs and demonstrates the value of scientifically grounded DAG representations\([Bao et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib2)\)\. GeoFlow makes tool\-calling objectives explicit inside generated geospatial workflows and reports improved execution success and token efficiency\([Bhattaram et al\., 2025](https://arxiv.org/html/2610.14382#bib.bib3)\)\. GeoAgentic\-RAG integrates specialized retrieval, spatial\-analysis, reasoning, and supervisory roles over vector, raster, and multimodal data\([Liang et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib8)\)\. GeoAgentBench shifts attention to dynamic execution by evaluating parameter selection, runtime feedback, and error recovery across multi\-step geospatial tasks\([Yu et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib11)\)\.

These systems motivate ANASSA but do not make the same architectural object the unit of contribution\. The foundational ANASSA study focused on integrating reasoning, execution, spatial validation, governance, authoritative evidence, provenance, uncertainty, and human authority at the framework level\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. The present paper focuses on the implementation\-facing execution architecture needed to preserve those properties across task decomposition, component boundaries, runtime failure, and replanning\. Table[1](https://arxiv.org/html/2610.14382#S2.T1)summarizes this positioning; “not a reported architectural focus” does not imply that a system cannot support the capability through implementation choices\.

Table 1\.Positioning of the ANASSA LLA relative to representative geospatial\-agent work\.From a DSR perspective, these works provide important kernel knowledge for task graphs, tool\-augmented reasoning, specialist coordination, runtime feedback, and recovery\. The ANASSA contribution is positioned at the architecture\-design level: it assembles these capability classes with explicit geospatial evidence, governance, policy, provenance, and deployment boundaries into a design artifact whose elements can later be instantiated and evaluated\. This positioning follows DSR guidance that the artifact and the knowledge embodied in its design should be made explicit rather than presented as an undifferentiated implementation\([Hevner et al\., 2004](https://arxiv.org/html/2610.14382#bib.bib13);[Gregor and Hevner, 2013](https://arxiv.org/html/2610.14382#bib.bib15)\)\.

## 3\.Design Science Research Methodology

### 3\.1\.DSR Framing and Research Artifact

Design Science Research focuses on the purposeful creation and evaluation of artifacts that address relevant problems and contribute reusable design knowledge\([Hevner et al\., 2004](https://arxiv.org/html/2610.14382#bib.bib13)\)\. This paper follows the six\-activity DSR process described by Peffers et al\.: problem identification and motivation, definition of objectives for a solution, design and development, demonstration, evaluation, and communication\([Peffers et al\., 2007](https://arxiv.org/html/2610.14382#bib.bib14)\)\. Gregor and Hevner further emphasize the need to make the artifact, its level of abstraction, and its knowledge contribution explicit\([Gregor and Hevner, 2013](https://arxiv.org/html/2610.14382#bib.bib15)\)\.

The research artifact in this study is theANASSA HLA\-to\-LLA refinement design\. The foundational ANASSA framework serves as kernel knowledge and a design input rather than as a new contribution\. The artifact consists of: \(1\) functional and non\-functional requirements for implementation\-facing refinement; \(2\) eight LLA\-focused design principles; \(3\) an HLA responsibility interpretation; \(4\) the HLA\-to\-LLA decomposition method; \(5\) the LLA role, task, contract, state, validation, governance, recovery, and provenance models; and \(6\) traceability and evaluation criteria that make the refinement testable in a later implementation\.

Table[2](https://arxiv.org/html/2610.14382#S3.T2)maps the DSR activities to this paper\.

Table 2\.Application of Design Science Research Methodology to the ANASSA architecture design\.
### 3\.2\.Problem Identification and Motivation

The design problem is fragmentation across reasoning, geospatial data, tool execution, governance, authoritative evidence, and organizational decision authority\. A model can produce a plausible plan while still losing coordinate reference information, relying on stale evidence, selecting an unavailable capability, violating policy, or failing without a reconstructable recovery path\. The architecture must therefore do more than coordinate agents: it must carry the context and controls required to move safely from intent to validated action\.

The foundational ANASSA study provides the starting architecture and eight design requirements\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. This paper treats those requirements as inherited constraints and refines them through a product/system design lens: who or what is responsible, what information crosses each boundary, what can fail, how the system recovers, what must be observable, and which responsibilities must remain replaceable across technology choices\.

### 3\.3\.Objectives for the Design Solution

Five design objectives guide the artifact:

- •DO1 – Implementation precision:define responsibility and interface boundaries precisely enough to guide a reference implementation\.
- •DO2 – Observable orchestration:make task construction, capability selection, state transition, failure, retry, replanning, policy decisions, validation, and escalation observable\.
- •DO3 – Geospatial integrity:preserve spatial reference, geometry, temporal context, source authority, quality, and uncertainty across component boundaries\.
- •DO4 – Governed autonomy:allow machine\-paced operation within policy while preserving explicit human authority where risk, consequence, uncertainty, or regulation requires it\.
- •DO5 – Deployment independence and reproducibility:separate logical capabilities from specific model, platform, cloud, and protocol implementations while retaining sufficient provenance to reconstruct a completed cycle\.

### 3\.4\.Functional and Non\-Functional Design Requirements

The functional requirements describe what ANASSA must do; the non\-functional requirements describe the system qualities the design must preserve\. They derive from the foundational ANASSA requirements, failure modes identified in related geospatial\-agent work, and the design objectives above\.

Table 3\.Functional and non\-functional requirements for the ANASSA design solution\.
### 3\.5\.Design and Development Procedure

The architecture is developed through constrained decomposition rather than by enumerating agents first\.Step 1: freeze inherited invariants\.The four layers, C1–C11 boundaries, C5 sequence, C7/C8 authority relationships, and DR1–DR8 are treated as fixed inputs\.Step 2: assign product/system responsibilities\.Each HLA component is defined by the responsibility it owns and by the responsibilities it must not absorb\.Step 3: decompose responsibilities into capabilities and logical roles\.A role is created only when it has a distinguishable responsibility, contract, policy scope, or observable state\.Step 4: define interfaces before implementations\.Cross\-boundary exchanges receive typed payload, spatial/temporal context, provenance, policy, validation, and failure semantics\.Step 5: define runtime behavior\.Task\-graph revision, capability resolution, state transitions, policy controls, validation, recovery, and provenance are specified\.Step 6: evaluate traceability and closure\.Every requirement must map to identifiable HLA/LLA elements, and an end\-to\-end cycle must be reconstructable without relying on hidden model reasoning\.

This procedure is intentionally technology\-agnostic\. References to language or multimodal models, retrieval, vector databases, APIs, agent\-to\-agent protocols, geospatial software, and cloud infrastructure identify capability classes rather than required vendors\. A logical role may be implemented by an AI agent, deterministic service, workflow engine, human\-controlled function, or combination of these as long as the defined responsibility and observable records are preserved\.

### 3\.6\.Demonstration and Evaluation Strategy

The artifact is demonstrated using a synthetic geospatial workflow that intentionally encounters a coordinate\-reference mismatch and then exercises graph revision, policy evaluation, evidence\-based validation, uncertainty retention, output packaging, and provenance closure\. The evaluation is analytical rather than performance\-based\. Four criteria are used:E1 requirements coverage,E2 internal consistency,E3 end\-to\-end design closure, andE4 technology independence\. Empirical accuracy, latency, cost, and scalability remain evaluation targets for a subsequent reference implementation\.

## 4\.ANASSA Design Principles

The design principles translate the objectives and requirements into rules that constrain HLA\-to\-LLA refinement\. They operationalize and extend the framework\-level principles established in the foundational ANASSA study\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\); they are not presented as a replacement for that earlier set\. The principles are intended to remain stable even when specific tools, models, runtimes, or deployment technologies change\.

Table 4\.ANASSA design principles used to guide HLA\-to\-LLA refinement\.The principles are not independent slogans\. DP1 and DP5 preserve domain integrity; DP2–DP4 define the control and interface structure; DP6 constrains autonomy; DP7 defines failure behavior; and DP8 closes the system around accountability and reproducibility\. Together they provide the design logic connecting the DSR objectives to the two architecture levels presented next\.

### 4\.1\.Requirements\-to\-Design Traceability

Table[5](https://arxiv.org/html/2610.14382#S4.T5)connects the inherited ANASSA requirements to design principles, HLA responsibility owners, LLA mechanisms, and observable evidence\. This traceability is the primary analytical check that the LLA remains a refinement of the HLA rather than an unrelated implementation design\.

Table 5\.Traceability from inherited ANASSA requirements through design principles to HLA/LLA mechanisms\.

## 5\.ANASSA HLA Responsibility Model

### 5\.1\.Four Layers and Eleven Components

Figure[6](https://arxiv.org/html/2610.14382#S6)uses the component identifiers and four\-layer boundary model inherited from the foundational ANASSA framework\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. The present study interprets this structure as an HLA responsibility map rather than re\-specifying it component\-by\-component\. For design purposes, the responsibilities form four ownership classes: external context and operating surfaces \(C1–C3 and C6\), orchestration and cognitive execution \(C4–C5\), governance and evidence authority \(C7–C8\), and process/output closure \(C9–C11\)\. This grouping makes the subsequent decomposition explicit without changing the inherited component boundaries\.

The L0–L4 notation inside C4 is intentionally separate from the four top\-level ANASSA layers\. L0–L4 describe the internal execution stack of one HLA component; they do not introduce additional framework layers\. This distinction is important because the HLA remains stable while implementation detail can evolve beneath C4\.

### 5\.2\.From Component Boundaries to Implementation Surfaces

The HLA is intentionally compact\. For implementation, each component boundary becomes one or more surfaces that must be made explicit\. A surface may carry intent, data, model context, a policy decision, an execution request, a validation result, a human decision, a learning update, or a final intelligence artifact\. The LLA therefore expands each component in three directions:*role decomposition*\(which agent or service is responsible\),*interface definition*\(what is exchanged\), and*runtime semantics*\(what states and controls govern the exchange\)\.

This expansion preserves the original architecture while avoiding a common failure mode in agentic systems: allowing the foundation model to become the implicit architecture\. In ANASSA, models are replaceable substrates inside explicit control, data, and validation boundaries\.

## 6\.HLA\-to\-LLA Design Decomposition

The HLA and LLA are not independent diagrams\. The LLA is derived from the HLA through a repeatable refinement sequence:

\(1\)HLA Responsibility\\displaystyle\\text\{HLA Responsibility\}→Capabilities→Logical Roles\\displaystyle\\rightarrow\\text\{Capabilities\}\\rightarrow\\text\{Logical Roles\}→Contracts→Runtime Behavior\.\\displaystyle\\rightarrow\\text\{Contracts\}\\rightarrow\\text\{Runtime Behavior\}\.
For each HLA component, the design asks five questions:What outcome or control does the component own? What capabilities are required to fulfill that responsibility? Which responsibilities require separate logical roles? What information must cross the boundary? What states, policies, validation, and failures must be observable at runtime?This sequence prevents the design from beginning with an arbitrary agent count or vendor stack\.

C4 illustrates the method\. At the HLA, C4 owns orchestration across the distributed geospatial system\-of\-systems\. That responsibility decomposes into intent/task decomposition, capability resolution, sequencing, scheduling, policy enforcement, execution monitoring, recovery, and output synthesis\. Those capabilities are organized into the L0 Orchestrator and L1–L4 supporting layers\. The same method is applied to C1–C3, C5–C8, and C10, while C9/C11 retain their process\-flow responsibility\.

Three design rules control the refinement\. First,responsibility continuity: every LLA role must trace to an HLA owner\. Second,boundary preservation: decomposition may refine a component but may not silently move governance, evidence authority, or human authority into an unrelated component\. Third,implementation substitutability: LLA roles and contracts describe what must be provided, while concrete models, geospatial tools, services, and runtimes remain replaceable\.

Refinement is considered complete only when four architecture\-review gates are satisfied\.Ownership closurerequires every logical role and state transition to have an HLA owner\.Interface closurerequires every cross\-boundary dependency to be represented by an explicit contract rather than hidden prompt context or undocumented coupling\.Control closurerequires policy decisions, validation results, failure states, and escalation paths to be observable at the same boundary where the corresponding action occurs\.Substitution closurerequires a provider, model, tool, or runtime to be replaceable without changing the upstream logical task and contract semantics\. These gates turn the HLA\-to\-LLA transformation into a reviewable design procedure rather than a diagramming exercise\.

The output of the decomposition is therefore a consistent design package for each HLA owner: a responsibility statement, capability inventory, logical\-role assignment, contract boundary, runtime\-state and failure behavior, and evidence/provenance obligation\. A component is not considered implementation\-ready when any of these elements is missing\. The same closure criteria are reused in Section[12](https://arxiv.org/html/2610.14382#S12)as part of the DSR artifact evaluation, connecting the design procedure directly to its evaluation rather than assessing the architecture after the fact\.

During architecture review, a failed closure gate returns the component to refinement\. A pass requires inspectable evidence: an owning component, role mapping, contract, state transition, control hook, bounded failure route, and provenance link\. This makes the transformation auditable and prevents operational dependencies from being hidden in prompts or adapters\. In product\-design terms, HLA approval establishes ownership; LLA approval establishes executable, observable, governable, and replaceable boundaries\.

## 7\.Implementation\-Facing Low\-Level Architecture \(LLA\)

### 7\.1\.LLA Overview

Figure[8\.3](https://arxiv.org/html/2610.14382#S8.SS3)summarizes the low\-level design artifact\. Its decomposition is constrained by DP1–DP8 and the HLA\-to\-LLA derivation rules in the preceding section\. The LLA therefore refines component responsibilities without redefining the HLA: it makes roles, contracts, task structures, states, policy checks, validation, recovery, and provenance explicit at the level required for implementation\.

### 7\.2\.C1–C3: Intent, Domain Context, and Deployment

C1 converts human or organizational participation into machine\-actionable intent while retaining identity, authorization, role, and collaboration context\. Its logical roles include Participant Engagement, Collaborative Workflow, UX and Access, Community Mapping, and Multi\-Stakeholder Coordination\. These roles do not perform the full spatial analysis; they establish who is asking, what objective is being pursued, what data exposure is permitted, and which competing stakeholder constraints must be carried into planning\.

C2 binds the workflow to sector\-specific semantics\. The LLA distinguishes Earth and space sectors and assigns roles for Industry Requirements, Regulatory and Compliance, Industry Workflow Automation, Domain Knowledge and Insight, and Sector Reporting and Communications\. The important architectural property is not the enumerated sector list itself but the existence of a domain\-context interface\. Planning at S3 must be able to retrieve the applicable standards, tolerances, regulatory constraints, and output expectations without embedding them as untraceable prompt assumptions\.

C3 represents deployment environments—enterprise, cloud, edge, hosted\-service integration, desktop, and field/mobile—rather than a product classification of ANASSA\. It assigns roles for Solution Recommendation, Deployment Monitoring and Optimization, Scalability and Performance, and Legacy Migration and Modernization\. C3 receives approved execution from S5 and provides the runtime environment in which geospatial services, APIs, databases, models, and external operational systems are invoked\.

### 7\.3\.C4: Distributed Geospatial System\-of\-Systems

C4 is the execution backbone of the low\-level architecture\. Its internal Layer 0 is the ANASSA Spatial Agentic AI Orchestrator, while L1–L4 provide the model, specialist\-agent, integration, and infrastructure capabilities through which tasks are executed\. The Orchestrator serves as the central orchestration control plane rather than as a message router\. It owns the lifecycle of the workflow graph and maintains the coordination state that connects participant intent to evidence\-bound output\.

Layer 0 contains six core responsibility classes represented in Figure[8\.3](https://arxiv.org/html/2610.14382#S8.SS3): task\-graph decomposition, agent sequencing, workflow monitoring, governance enforcement, output synthesis, and hallucination/validation escalation\. An implementation may realize these functions as separate services or as modules inside one orchestration service, but their state transitions must remain distinguishable\.

The supporting C4 stack is organized as follows:

- •L1 – Multi\-Model Language Gateway:language and multimodal model access, natural\-language interface, query decomposition, prompt/instruction construction, and response synthesis\.
- •L2 – Specialized Geospatial AI Agents:spatial analysis, cartography, remote sensing, workflow orchestration, and system\-connectivity capabilities\.
- •L3 – Geospatial Platform Integration:model/tool interoperability interfaces such as Model Context Protocol \(MCP\), agent\-to\-agent interfaces, enterprise geospatial software, SDKs, REST APIs, IoT connectors, legacy adapters, and OGC\-aligned services\.
- •L4 – AI Infrastructure:compute, model hosting/registry, vector and spatial indexes, retrieval infrastructure, caching, and supporting runtime services\.

The L0–L4 decomposition separates orchestration policy from vendor implementation\. A task may be reasoned over by one model, executed by a geospatial service from another vendor, retrieve evidence from an enterprise spatial database, and publish through a third platform without changing the top\-level ANASSA component model\.

### 7\.4\.C6: Multimodal Spatial Data

C6 is the preparation and streaming boundary between heterogeneous spatial observations and the Cognitive Loop\. The LLA groups inputs into Earth data, space/orbital data, and real\-time streams\. These include vector and raster data, terrain, LiDAR and point clouds, imagery, voxel and 3D data, CAD/BIM, multidimensional cubes, orthorectified imagery, SAR, multispectral and hyperspectral data, orbital telemetry, space weather, IoT networks, traffic, GNSS, volunteered geographic information, drone and vehicle telemetry, emergency feeds, and industrial sensors\.

Logical roles cover ingestion, quality and validation, ETL and transformation, streaming, spatial data fusion, metadata and catalog management, classification and labeling, and compression and optimization\. The LLA requires C6 to emit prepared bundles with explicit spatial reference, time, source identifiers, quality metadata, and provenance\. Missing coordinate systems, stale observations, incompatible resolution, or insufficient metadata are therefore visible before S1 rather than silently inferred downstream\.

### 7\.5\.C5: Geospatial AI Cognitive Loop

The LLA does not redefine the six C5 stages established in the foundational ANASSA framework; it gives those stages implementation\-facing exchange semantics\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. S1 emits an observation/event record, S2 a structured interpretation with selected capabilities, S3 a versioned task\-graph proposal, S4 a validation and policy disposition, S5 an execution record bound to the approved graph, and S6 a governed learning update or change proposal\. These records convert the inherited cognitive cycle into explicit interfaces that can be validated, replayed, and audited\.

S6 \(Learn and Adapt\) produces bounded learning updates for permitted subscribers\. S6 may update approved preference, capability, performance, and coordination state, but it may not autonomously modify C7 governance policy, C8 certification criteria, authorization privileges, or other protected control state; changes to those controls are emitted as proposals requiring authorized approval\.

S3 and S4 are explicit human\-authority control points\. The LLA does not require a human to block every machine\-paced transaction\. Instead, C7 evaluates the workflow’s risk class, policy, consequence, uncertainty, and evidence state to determine whether execution is auto\-permitted, conditionally permitted, or held for explicit human authorization\. Human decisions become provenance\-bearing events rather than off\-system approvals\.

### 7\.6\.C7, C8, C9–C11: Governance, Evidence, Process Flow, and Output

The foundational ANASSA framework defines C7 governance and C8 evidence responsibilities; the LLA refines them into runtime control surfaces rather than repeating their high\-level definitions\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. C7 exposes policy evaluation, authorization, audit, escalation, and monitoring decisions at scheduling and validation boundaries\. The responsible logical roles produce machine\-readable dispositions that can permit, deny, condition, or hold an action, with each decision linked to the task and provenance record\. This treatment is consistent with lifecycle\-oriented AI governance in which problem definition, data quality, model behavior, human oversight, and operational monitoring are connected controls\([Cognilytica, 2019](https://arxiv.org/html/2610.14382#bib.bib4)\)\.

C8 exposes evidence retrieval, source certification metadata, authority/applicability checks, and security/sovereignty controls\. The LLA requires evidence responses to carry jurisdiction, temporal validity, resolution or accuracy support, provenance, and applicable uncertainty rather than returning an unqualified “ground truth” value\. S4 can therefore distinguish supported, uncertain, conflicting, insufficient, and rejected evidence conditions using the same contract structure\([International Organization for Standardization, 2023](https://arxiv.org/html/2610.14382#bib.bib7)\)\.

C9 and C11 remain process\-flow connectors\. C9 carries data and intent downward into the architecture, while C11 returns learning, validation, and release state\. C10 assembles the externally consumable release package from approved intelligence artifacts, machine\-readable decision/provenance records, and the validation status attached to each spatial claim\. C10 does not independently re\-validate claims; it publishes results whose validation and governance dispositions are already explicit\.

## 8\.Logical Roles and Orchestration Semantics

### 8\.1\.Five\-Tier Logical Role Hierarchy

The LLA inventories 47 logical roles across five functional tiers \(Table[6](https://arxiv.org/html/2610.14382#S8.T6)\)\. The functional hierarchy identifies ownership of orchestration, cognitive\-cycle behavior, domain work, governance, and foundation services\.

Table 6\.Five\-tier ANASSA logical role hierarchy\.The hierarchy is deliberately compatible with heterogeneous runtimes\. A “logical agent” is defined by a responsibility, input/output contract, policy scope, and observable state\. It need not correspond one\-to\-one with a process, container, model instance, or vendor agent object\. This prevents implementation details from collapsing the architecture into a particular software framework\.

### 8\.2\.Task\-Graph Representation

Participant intent is not dispatched directly to a tool\. C4 first translates the objective into a versioned executable task graph\. For graph revisionrr, ANASSA represents the workflow as

\(2\)Gr=\(Vr,Er\),G\_\{r\}=\(V\_\{r\},E\_\{r\}\),where each nodevi∈Vrv\_\{i\}\\in V\_\{r\}is a typed task and each edgeei​j∈Ere\_\{ij\}\\in E\_\{r\}is a declared dependency\. A single graph revision is acyclic so that scheduling and provenance are well defined; the higher\-level C5 Cognitive Loop is cyclic because failure, validation, and learning may produce a new graph revisionGr\+1G\_\{r\+1\}\.

A canonical task node is represented logically as

\(3\)vi=⟨\\displaystyle v\_\{i\}=\\langlei​d,r​o​l​e,c​a​p​a​b​i​l​i​t​y,i​n​p​u​t,s​p​a​c​e,t​i​m​e,\\displaystyle id,role,capability,input,space,time,policy,validation,recovery,output⟩\.\\displaystyle policy,validation,recovery,output\\rangle\.The fields carry the task/cycle identifier, requesting/executing role, required capability, input contract, spatial and temporal context, governance policy, validation rules, retry/replan behavior, expected output, and provenance pointer\. Edges are typed as*data*,*control*,*validation*, or*governance*dependencies\. Parallel branches are permitted only when their dependencies and policy/evidence constraints are satisfied\.

Replanning never overwrites the prior graph\. Instead, an observed runtime condition generates a new graph revision with a recorded reason and lineage to the superseded node\(s\)\. This preserves the difference between an adaptive workflow and an untraceable sequence of model\-generated actions\. The representation extends graph\-based geospatial\-agent work\([Bao et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib2);[Bhattaram et al\., 2025](https://arxiv.org/html/2610.14382#bib.bib3)\)by binding execution structure to spatial contracts, governance, evidence, typed runtime state, and provenance\.

### 8\.3\.Capability Resolution and Agent Selection

For each task node, the Orchestrator resolves a capability rather than selecting an agent by name alone\. The registry entry for a capability records the available implementation\(s\), supported geometry/data types, coordinate/reference constraints, and input/output schemas\.

Table 7\.Inventory of 47 logical roles mapped to HLA responsibility owners\. The count is not a requirement for 47 runtime processes\.C9 and C11 remain process\-flow functions and C10 remains an output\-packaging responsibility; they are represented through contracts and runtime records rather than counted as separate logical agents\. The eight C7 logical roles refine rather than replace the governance domains inherited from the foundational framework: at the LLA, governance responsibilities are decomposed where separate policy scope, observable state, or validation behavior is required\.

The registry also records permitted tools, credentials, expected latency class, resource requirements, and governance scope\. A selection decision can therefore be explained as a match between task requirements and registered capabilities\.

If no compatible capability is available, the task does not silently degrade\. C4 returns a typed state such as*capability\-unavailable*,*unsupported\-data\-type*,*authorization\-denied*, or*constraint\-conflict*\. The planner may then recompose the graph, request clarification, or escalate according to policy\.

### 8\.4\.Runtime State Model

The LLA defines a compact runtime state model for every task\. A normal path is:

> RECEIVED→\\rightarrowPRECONDITION\_CHECK→\\rightarrowREADY →\\rightarrowSCHEDULED→\\rightarrowRUNNING→\\rightarrowVALIDATING →\\rightarrowCOMPLETED\.

Table 8\.Additional ANASSA task runtime states\.WaitingWAITING\_FOR\_DATA; WAITING\_FOR\_POLICY; WAITING\_FOR\_HUMANRecovery / terminalRETRYABLE\_FAILURE; REPLANNING; REJECTED; ESCALATED; TERMINATEDEvery transition records the cause, the actor or policy that triggered it, a timestamp, the graph revision, and relevant evidence\. This makes recovery behavior observable instead of burying it in model\-generated reasoning text\.

## 9\.Inter\-Component Contracts and Runtime Controls

### 9\.1\.Canonical Contract Schema

The foundational ANASSA specification defined architecture\-level contract contents and typed failure states for reproducible interfaces\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. The LLA refines those elements into the canonical schema \(Table[9](https://arxiv.org/html/2610.14382#S9.T9)\)\. The schema is intentionally logical; JSON, protocol buffers, database rows, event envelopes, or other encodings may implement it\.

Table 9\.Canonical ANASSA inter\-component contract fields\.A contract is accepted only when preconditions are satisfied\. This is important for geospatial systems because a syntactically valid payload may still be operationally invalid: geometry may use the wrong axis order, a raster may be stale, a route may cross a jurisdiction not covered by the policy, or a positional\-accuracy claim may exceed the source evidence\.

Table 10\.Illustrative contract instance used in the worked trace\.
### 9\.2\.Logical Interaction Patterns

To keep interface semantics independent of transport technology, the LLA defines a compact set of logical interaction patterns:

- •AGENT\-INVOKE:synchronous request/response mediated by the Orchestrator;
- •EVENT\-PUB:asynchronous publication to a declared subscriber set;
- •DATA\-READ/WRITE:versioned access to C8 or governed operational stores;
- •STREAM:windowed real\-time ingest for telemetry and continuously updated observations;
- •POLICY\-EVAL:C7 evaluation returning permit, deny, or permit\-with\-conditions;
- •HITL\-GATE:a blocking or time\-bounded human\-authorization request when policy requires it;
- •OUTPUT\-ATTEST:evidence assembly and attestation used by C10 to publish a validation\-qualified output package\.

This vocabulary separates semantic interface types from transport choices\. For example,EVENT\-PUBmay be implemented by a message broker, webhook, event bus, or database notification without changing the logical contract\.

### 9\.3\.Execution Controls

Runtime execution is bounded by tool allowlists, parameter ranges, credential/data\-access scope, timeout and retry limits, idempotency expectations, error classification, and rollback or compensating\-action rules\. The Orchestrator may dispatch only tasks whose preconditions and policy checks are satisfied\. A downstream component receives both the produced artifact and its execution record so that later reasoning is grounded in observed execution rather than assumed success\.

For side\-effecting operations, the contract must also indicate whether the operation is reversible, repeatable, compensatable, or non\-idempotent\. This becomes especially important when S5 triggers downstream enterprise workflows rather than merely producing maps or analytical layers\.

### 9\.4\.Failure Taxonomy and Recovery

Runtime failures are grouped into five classes\.Input failuresinclude schema, CRS, topology, metadata, freshness, or missing\-data defects\.Capability failuresinclude unavailable tools, unsupported operations, resource constraints, or incompatible models\.Execution failuresinclude parameter errors, timeout, downstream\-service failure, and partial completion\.Validation failuresinclude insufficient evidence, authoritative\-source conflict, tolerance violation, and rejected spatial claims\.Governance failuresinclude authorization denial, residency/privacy conflict, unapproved risk, or human rejection\.

Recovery follows an evidence\-driven sequence: classify the observed failure; determine whether a bounded retry is permitted; if not, determine whether the task graph can be replanned with different capabilities or parameters; if not, evaluate whether human adjudication is required; otherwise terminate with a typed failure\. The key architectural rule is that replanning is triggered by recorded runtime evidence, not by unconstrained model speculation\.

## 10\.Spatial Validation, Governance, and Provenance

### 10\.1\.Spatial Validation Pipeline

S4 operationalizes the spatial\-validation requirements established in the foundational ANASSA specification\. Candidate outputs are evaluated for coordinate\-reference compatibility, geometry/topology, positional accuracy, scale and resolution, temporal validity, uncertainty, jurisdiction, source authority, and conflicting authoritative evidence\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12);[International Organization for Standardization, 2023](https://arxiv.org/html/2610.14382#bib.bib7)\)\. These checks can be performed by different services, but the result must be assembled into one validation record before an output is released or a consequential downstream action is authorized\.

The LLA distinguishes*claim validation*from*artifact validation*\. Artifact validation asks whether the dataset, geometry, map, route, or model output satisfies structural and quality requirements\. Claim validation asks whether a specific spatial assertion—for example, a boundary, coordinate, containment relation, risk intersection, or location\-dependent recommendation—is supported by admissible evidence\. This distinction allows a technically valid dataset to be rejected for a particular decision context when its authority, age, accuracy, or jurisdiction is insufficient\.

### 10\.2\.Evidence States

Consistent with the foundational ANASSA specification, the validation result is not binary\. A claim may be*validated*,*validated with uncertainty*,*conflicting authoritative evidence*,*insufficient evidence*, or*rejected*\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. Each state carries the checks performed, evidence identifiers and versions, applicable tolerances, uncertainty information, and any human adjudication\.

This state model matters for autonomous workflows because “unknown” and “conflicting” are operationally different from “false\.” A governed agentic system must be able to stop, escalate, or communicate uncertainty without manufacturing a definitive spatial answer\.

### 10\.3\.Risk\-Adaptive Human Oversight and Authorization

The C7 Human Authority and Validation role evaluates whether S3 or S4 requires explicit human authorization\. A policy may consider consequence level, output type, jurisdiction, data sensitivity, evidence conflict, uncertainty, financial or safety impact, and whether the workflow is acting on external systems\. The result is one of three broad modes:*auto\-permit within policy*,*permit with conditions*, or*human authorization required*\. The human record includes approver identity/role, timestamp, decision, optional modification, evidence viewed, and the task\-graph revision being authorized\.

This approach preserves accountable human authority while allowing policy\-approved low\-risk execution to proceed without inserting a universal manual approval step, consistent with human\-AI interaction guidance emphasizing appropriate control, visibility, and recoverability\([Amershi et al\., 2019](https://arxiv.org/html/2610.14382#bib.bib1)\)\.

### 10\.4\.Provenance Record

Each completed cycle produces a first\-class provenance record containing the objective and C1/C2 context; data, model, and tool versions; task\-graph revisions; parameters and intermediate artifacts; execution and validation states; retries and failures; policy and human decisions; learning updates; and final disposition\. The record supports decision reconstruction, repeated\-run comparison, and attribution of divergence to data, model, tool, or policy changes\.

## 11\.Architecture Integration and Principal Flows

### 11\.1\.Principal Component Flows

The LLA consolidates twenty principal component relationships \(Table[11](https://arxiv.org/html/2610.14382#S11.T11)\)\. The matrix does not prohibit additional implementation\-specific flows\. Its purpose is to identify the architectural pathways that must remain visible across deployments\.

Table 11\.ANASSA principal connection matrix\.

## 12\.DSR Demonstration and Design Evaluation

### 12\.1\.Synthetic End\-to\-End Architecture Demonstration

To check that the LLA mechanisms close into one coherent execution path, Table[12](https://arxiv.org/html/2610.14382#S12.T12)instantiates a synthetic, non\-performance trace for the objective:*identify facilities within 5 km of a current flood\-warning polygon and release only spatial claims supported by admissible evidence*\. The trace is intentionally small; its purpose is to exercise task/contract identity, a spatial precondition failure, graph revision, policy evaluation, evidence\-based validation, C10 packaging, and provenance closure\.

Table 12\.Synthetic architecture trace demonstrating failure, recovery, validation, and provenance\. Times are logical offsets, not measured latency\.The worked trace is an architecture\-level consistency demonstration, not an empirical result\. It shows that a spatial mismatch becomes a typed contract failure rather than a hidden prompt correction; replanning creates a new DAG revision; policy controls can permit a low\-consequence analytical path without mandatory human latency; S4 retains uncertainty instead of forcing a binary verdict; and the final C10 package can be reconstructed from the cycle record\.

### 12\.2\.Analytical Evaluation Criteria

The design artifact is evaluated against four criteria established in the DSR methodology\.

Table 13\.Analytical evaluation of the ANASSA design artifact\.This evaluation establishes design completeness and internal coherence, not operational superiority\. Claims of execution accuracy, latency, cost, throughput, resilience, or scalability require an implemented system and controlled comparison\.

### 12\.3\.Reference Implementation Readiness

A conforming reference implementation does not need to reproduce every diagram element as a separate service\. It must expose enough state to verify the design artifact\. At minimum, an implementation should provide: \(1\) stable identifiers for cycles, tasks, contracts, roles, and graph revisions; \(2\) explicit spatial/temporal context on task inputs; \(3\) a capability registry; \(4\) machine\-readable policy decisions; \(5\) typed execution and validation states; \(6\) evidence/provenance pointers; \(7\) observable retry, replanning, and escalation events; and \(8\) a final C10 decision record linking the output to its supporting execution path\.

Technology independence should be tested at component boundaries rather than by requiring a single platform\. C4\-L3 is therefore a critical implementation surface: the same logical task and contract should be bindable to alternative geospatial services or tools while preserving the orchestration semantics above the adapter layer\.

## 13\.Discussion

### 13\.1\.Generalizable Design Knowledge

The primary design contribution is not the visual form of the HLA or LLA\. It is the set of reusable design decisions that connect geospatial intent to governed execution: geospatial context travels with the task; intent is separated from execution; capabilities are resolved independently of vendors; cross\-boundary exchanges are typed; validation is part of the runtime path; autonomy is policy\- and risk\-adaptive; failures become evidence for bounded recovery; and released decisions remain reconstructable\. These principles can guide implementations that differ substantially in models, tools, platforms, and deployment topology\.

### 13\.2\.System Architecture Implications

The architecture follows a product/system design discipline in which user and organizational objectives are translated into requirements before implementation technologies are selected\. C1/C2 express user, stakeholder, sector, and policy context; C4/C5 translate those objectives into governed execution; C6/C8 provide data and evidence; C7 constrains autonomy; C3 isolates deployment choices; and C10/C11 make outputs and decision history consumable\. This separation is important because a successful geospatial agentic system must optimize more than model quality: it must also support interoperability, observability, failure recovery, security, accountability, and change over time\.

### 13\.3\.Relationship to the Foundational ANASSA Framework

The foundational ANASSA study established the framework\-level architecture, component boundaries, architectural requirements, and evaluation variables\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\)\. The present study extends that baseline through systematic HLA\-to\-LLA refinement, explicit logical roles, versioned task graphs, capability resolution, canonical contracts, runtime states, recovery behavior, and analytical design evaluation\. The next research stage should instantiate a minimal vertical slice and evaluate architecture conformance before broader domain benchmarking\. This separation preserves design quality and empirical performance as distinct research questions\.

## 14\.Limitations, Threats to Validity, and Future Work

The design remains an architecture artifact rather than an implemented production system\. It does not establish that 47 logical roles are optimal, that one task\-graph representation will suit every geospatial workload, or that every workflow needs all twenty principal flows\. The role inventory may be consolidated or extended during implementation provided that responsibility and audit boundaries remain observable\. Likewise, the interaction\-pattern vocabulary is a design abstraction rather than a requirement for a specific transport protocol\.

The LLA also does not prescribe distributed\-runtime consistency semantics such as exactly\-once versus at\-least\-once delivery, global ordering, backpressure, leader election, distributed locking, cancellation propagation, or recovery after an Orchestrator process failure\. Those properties depend on the selected transport and runtime\. A reference implementation must therefore declare its delivery, ordering, idempotency, checkpoint, and partial\-failure guarantees and demonstrate that they preserve the logical task/contract semantics defined here\.

Because the evaluation is analytical and author\-conducted, it can establish traceability and internal coherence but not external validity, operational effectiveness, or superiority over alternative architectures\. The synthetic trace exercises selected failure and governance paths rather than the full space of geospatial workloads, and the 47\-role inventory has not yet been empirically optimized\. These limitations motivate implementation\-based conformance testing and comparative evaluation\.

Future work should proceed in three stages\. First, implement a minimal vertical slice of C4/C5/C7/C8/C10/C11 and measure architecture conformance through contract completeness, trace reconstruction, typed\-failure capture, graph\-revision correctness, policy\-decision observability, and evidence\-chain completeness\. Second, demonstrate DP3 deployment independence by binding the same logical task/contract to more than one geospatial execution adapter\. Third, benchmark reasoning, tool sequencing, spatial validation, failure recovery, human escalation, reproducibility, and scalability against geospatial\-agent baselines such as GeoAgentBench and related systems\([Liang et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib8);[Yu et al\., 2026](https://arxiv.org/html/2610.14382#bib.bib11)\)\.

## 15\.Conclusion

This paper presents an ANASSA HLA\-to\-LLA refinement design for spatial agentic AI\. Starting from the framework\-level architecture established in the foundational ANASSA study\([Papantoniou and Hilton, 2026](https://arxiv.org/html/2610.14382#bib.bib12)\), it derives implementation\-facing requirements, formalizes eight LLA\-focused design principles, interprets the inherited structure as an HLA responsibility model, and systematically refines those responsibilities into the LLA\. The resulting artifact includes a five\-tier hierarchy of 47 logical roles, versioned task graphs, capability resolution, typed contracts, observable runtime states, risk\-adaptive governance, spatial\-validation pathways, evidence\-driven recovery, provenance records, and principal component flows\.

The central design proposition is that governed geospatial agentic AI should not be organized around a particular foundation model or geospatial product\. It should be organized around stable responsibilities, replaceable capabilities, explicit contracts, observable state, governed evidence, and reconstructable decisions\.

## References

- Amershiet al\.\(2019\)S\. Amershi, D\. Weld, M\. Vorvoreanu, A\. Fourney, B\. Nushi, P\. Collisson, J\. Suh, S\. Iqbal, P\. N\. Bennett, K\. Inkpen, J\. Teevan, R\. Kikin\-Gil, and E\. HorvitzGuidelines for human\-AI interaction\.InProceedings of the 2019 CHI Conference on Human Factors in Computing Systems,CHI ’19,New York, NY, USA,pp\. 1–13\.External Links:[Document](https://dx.doi.org/10.1145/3290605.3300233)Cited by:[§10\.3](https://arxiv.org/html/2610.14382#S10.SS3.p2.1)\.
- Baoet al\.\(2026\)R\. Bao, C\. Yang, D\. Yu, Z\. Tang, G\. Mai, and L\. ZhaoSpatial\-agent: agentic geo\-spatial reasoning with scientific core concepts\.InProceedings of the 64th Annual Meeting of the Association for Computational Linguistics \(Volume 1: Long Papers\),San Diego, California, United States,pp\. 14896–14911\.External Links:[Document](https://dx.doi.org/10.18653/v1/2026.acl-long.679),[Link](https://aclanthology.org/2026.acl-long.679/)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1),[Table 1](https://arxiv.org/html/2610.14382#S2.T1.2.2.1.1.1),[§2](https://arxiv.org/html/2610.14382#S2.p1.1),[§8\.2](https://arxiv.org/html/2610.14382#S8.SS2.p3.1)\.
- Bhattaramet al\.\(2025\)A\. Bhattaram, J\. Chung, S\. Chung, R\. Gupta, J\. Ramamoorthy, K\. Gullapalli, D\. Marculescu, and D\. StamoulisGeoFlow: agentic workflow automation for geospatial tasks\.InProceedings of the 33rd ACM International Conference on Advances in Geographic Information Systems,SIGSPATIAL ’25,New York, NY, USA,pp\. 1150–1153\.External Links:[Document](https://dx.doi.org/10.1145/3748636.3763217)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1),[Table 1](https://arxiv.org/html/2610.14382#S2.T1.2.3.1.1.1),[§2](https://arxiv.org/html/2610.14382#S2.p1.1),[§8\.2](https://arxiv.org/html/2610.14382#S8.SS2.p3.1)\.
- Cognilytica \(2019\)CognilyticaCPMAI: cognitive project management for AI methodology\.Note:Cognilytica ResearchExternal Links:[Link](https://www.cognilytica.com/cpmai-methodology/)Cited by:[§7\.6](https://arxiv.org/html/2610.14382#S7.SS6.p1.1)\.
- Gregor and Hevner \(2013\)S\. Gregor and A\. R\. HevnerPositioning and presenting design science research for maximum impact\.MIS Quarterly37\(2\),pp\. 337–355\.External Links:[Document](https://dx.doi.org/10.25300/MISQ/2013/37.2.01)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p4.1),[§2](https://arxiv.org/html/2610.14382#S2.p3.1),[§3\.1](https://arxiv.org/html/2610.14382#S3.SS1.p1.1)\.
- Hashemi and Züfle \(2026\)M\. Hashemi and A\. ZüfleA comprehensive survey of agentic AI for spatio\-temporal data\.Note:PreprintsExternal Links:[Document](https://dx.doi.org/10.20944/preprints202601.2236.v1)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1)\.
- Hevneret al\.\(2004\)A\. R\. Hevner, S\. T\. March, J\. Park, and S\. RamDesign science in information systems research\.MIS Quarterly28\(1\),pp\. 75–105\.External Links:[Document](https://dx.doi.org/10.2307/25148625)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p4.1),[§2](https://arxiv.org/html/2610.14382#S2.p3.1),[§3\.1](https://arxiv.org/html/2610.14382#S3.SS1.p1.1)\.
- Huet al\.\(2025\)J\. Hu, L\. Sun, and X\. LiuGeoAgent: an agentic AI framework for spatial query understanding and interactive geospatial intelligence\.InProceedings of the 1st ACM SIGSPATIAL International Workshop on Generative and Agentic AI for Multi\-Modality Space\-Time Intelligence,GeoGenAgent ’25,New York, NY, USA,pp\. 54–60\.External Links:[Document](https://dx.doi.org/10.1145/3764915.3770719)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1)\.
- International Organization for Standardization \(2023\)International Organization for StandardizationISO 19157\-1:2023 geographic information — data quality — part 1: general requirements\.Technical reportISO\.External Links:[Link](https://www.iso.org/obp/ui/en/#iso:std:iso:19157:-1:ed-1:v1:en)Cited by:[§10\.1](https://arxiv.org/html/2610.14382#S10.SS1.p1.1),[§7\.6](https://arxiv.org/html/2610.14382#S7.SS6.p2.1)\.
- Lianget al\.\(2026\)C\. Liang, Y\. Cui, R\. Shi, G\. Zha, X\. Yin, M\. Xiao, D\. Xu, X\. Duan, and B\. HuangGeoAgentic\-RAG: a multi\-agent framework for autonomous geospatial reasoning and visual insight generation with LLM\.International Journal of Applied Earth Observation and Geoinformation147,pp\. 105195\.External Links:[Document](https://dx.doi.org/10.1016/j.jag.2026.105195)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1),[§14](https://arxiv.org/html/2610.14382#S14.p4.1),[Table 1](https://arxiv.org/html/2610.14382#S2.T1.2.4.1.1.1),[§2](https://arxiv.org/html/2610.14382#S2.p1.1)\.
- Papantoniou and Hilton \(2026\)C\. Papantoniou and B\. HiltonANASSA: an agentic AI orchestration framework for spatial intelligence\.External Links:2609\.14824,[Link](https://arxiv.org/abs/2609.14824)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p2.1),[§1](https://arxiv.org/html/2610.14382#S1.p6.1),[§10\.1](https://arxiv.org/html/2610.14382#S10.SS1.p1.1),[§10\.2](https://arxiv.org/html/2610.14382#S10.SS2.p1.1),[§13\.3](https://arxiv.org/html/2610.14382#S13.SS3.p1.1),[§15](https://arxiv.org/html/2610.14382#S15.p1.1),[Table 1](https://arxiv.org/html/2610.14382#S2.T1.2.6.1.1.1),[§2](https://arxiv.org/html/2610.14382#S2.p2.1),[§3\.2](https://arxiv.org/html/2610.14382#S3.SS2.p2.1),[§4](https://arxiv.org/html/2610.14382#S4.p1.1),[§5\.1](https://arxiv.org/html/2610.14382#S5.SS1.p1.1),[§7\.5](https://arxiv.org/html/2610.14382#S7.SS5.p1.1),[§7\.6](https://arxiv.org/html/2610.14382#S7.SS6.p1.1),[§9\.1](https://arxiv.org/html/2610.14382#S9.SS1.p1.1),[Abstract\.](https://arxiv.org/html/2610.14382#abstract1.1)\.
- Pefferset al\.\(2007\)K\. Peffers, T\. Tuunanen, M\. A\. Rothenberger, and S\. ChatterjeeA design science research methodology for information systems research\.Journal of Management Information Systems24\(3\),pp\. 45–77\.External Links:[Document](https://dx.doi.org/10.2753/MIS0742-1222240302)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p4.1),[§3\.1](https://arxiv.org/html/2610.14382#S3.SS1.p1.1)\.
- Wanget al\.\(2024\)L\. Wang, C\. Ma, X\. Feng, Z\. Zhang, H\. Yang, J\. Zhang, Z\. Chen, J\. Tang, X\. Chen, Y\. Lin, W\. Zhao, Z\. Wei, and J\. WenA survey on large language model based autonomous agents\.Frontiers of Computer Science18\(6\),pp\. 186345\.External Links:[Document](https://dx.doi.org/10.1007/s11704-024-40231-1)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1)\.
- Xiet al\.\(2023\)Z\. Xiet al\.The rise and potential of large language model based agents: a survey\.External Links:2309\.07864,[Document](https://dx.doi.org/10.48550/arXiv.2309.07864)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1)\.
- Yuet al\.\(2026\)B\. Yu, C\. Yang, D\. Hou, C\. Liu, J\. Liu, C\. Wang, Z\. Zhang, H\. Li, and W\. YangGeoAgentBench: a dynamic execution benchmark for tool\-augmented agents in spatial analysis\.External Links:2604\.13888,[Link](https://arxiv.org/abs/2604.13888)Cited by:[§1](https://arxiv.org/html/2610.14382#S1.p1.1),[§14](https://arxiv.org/html/2610.14382#S14.p4.1),[Table 1](https://arxiv.org/html/2610.14382#S2.T1.2.5.1.1.1),[§2](https://arxiv.org/html/2610.14382#S2.p1.1)\.