Cases/Case Report

Case at a glance

1. The GIS delivery chain

Publishing GIS data involves more than uploading a file. A system identifies the format, resolves the coordinate reference system, processes data, generates a style, registers resources with GeoServer, configures caching, and verifies the resulting map service.

The following fields appear throughout the workflow.

Each value is produced upstream and consumed downstream. A changed name or coordinate may reject a request or publish a map in the wrong place.

The original process crossed desktop GIS, GDAL, PostGIS, GeoServer, and GWC. Engineers remembered sequence and parameters. After repeated runs, it became difficult to identify which run and stage introduced a fault.

2. Two production failures changed the design

The first involved S-57 electronic navigational charts. Importing a chart set into PostGIS can create more than one hundred feature-class tables. The workflow then creates stores, publishes layers, and assembles a layer group. When the group used OPAQUE_CONTAINER, member layers could disappear from the WMS listing. A direct GetMap request returned LayerNotDefined, yet the ServiceException still carried HTTP 200. A status-only check recorded a false success.

The second failure appeared in WMTS tile requests. GetTile returned 400 with / by zero in the response. A metatile size of 0x0 caused the division error. The official documentation did not describe that consequence; the team learned it through platform testing.

These incidents produced two requirements:

1. The publishing API cannot grade its own final result.
2. Tested platform behavior has to enter rules that a later run can consume.

3. Why the runtime does not call a model

The team considered exposing GeoServer REST operations as tools and asking a model to choose calls and parameters at runtime. That path did not enter the main system. workspace, store, layer, SRS, and bbox have exact provenance, and regeneration introduces avoidable drift.

Input intent is also available in the data. A directory containing .000 files selects the S-57 pipeline; .tif selects a raster pipeline. An unmatched signature returns an explicit error.

Open-ended work happens during pipeline design: a coding agent drafts the pipeline, an engineer reviews it and triggers a first full run, and a person certifies it after the system records the evidence. Runtime execution then uses certified rules.

The contributor calls this reasoning assetization: an open design decision becomes a pipeline declaration or an error rule that repeated runs can reuse.

"No LLM at runtime" describes this bounded input space. It is not a general objective for agent systems.

4. One publication runs through six stages

Each stage runs as a separate subprocess. The orchestrator consumes exit status, structured output, and error signatures.

The current path is sequential. A concurrent test once produced a transient verification run with zero successful tile requests for one dataset. At the current scale, the team accepts queueing in exchange for reproducibility. This choice should be revisited when queue delay threatens the service objective.

5. Why state lives on disk

Stages exchange files and do not share in-process objects.

run/
  metadata.json       # input signature, pipeline, processed facts, publish coordinates
  run-state.json      # current stage, retry count, state transitions
  verify_report.json  # real requests, screenshots, acceptance outcome

validate writes identification facts. process adds the coordinate system and bounding box. Downstream stages read those values and do not recompute them. The case calls this the disk fact plane and follows one rule: one fact has one authoritative writer.

The design survives process exit, supports restart from persisted stages, lets the frontend and CLI share contracts, and loads current code in a new subprocess. Its costs are equally concrete. Every state file needs a schema version. Timestamp precision must remain aligned between the CLI and frontend. An error prefix used as a rule signature becomes part of the contract.

A multi-host, multi-tenant system with concurrent writers would need transactional and isolated storage in place of these files.

6. Verify the map from the consumer side

verify does not accept a success field from publish as final evidence. It sends a real GetMap or GetTile request and checks at least three conditions.

1. The HTTP status is expected.
2. content-type is image/*, and the body is not an XML ServiceException.
3. A screenshot or image check observes meaningful map content.

ADPS calls this mechanism an external acceptance probe. The same structure applies when the final fact lives in a database readback, delivered file, payment receipt, or deployed page.

7. Convert one failure into a rule for the next run

Runtime handles only known signatures. Available actions are retry, abort, and skip. A missing spatial reference or a broken chart-update sequence stops the run; the system does not invent the missing value.

A new failure enters a five-part card after human review.

signature: "GetTile=400 and body contains '/ by zero'"
root_cause: "metatile size was configured as 0x0"
fallback: "disable the invalid metatile setting and rerun verify"
fixed_by: "set a safe SDK default"
related_rules: ["wmts-metatile-zero"]

The card preserves the symptom, root cause, immediate action, permanent fix, and runtime rule. Later runs consume a compact signature and action; an engineer can still follow source back to the full incident record.

8. How a new capability earns automatic execution

When the current pipeline version differs from the certified version, the system returns it to candidate. A code change cannot keep an earlier certification silently.

During development, the model creates scaffolding and a person certifies the pipeline; runtime accepts only active versions. This preserves review evidence without requiring approval for every routine run.

9. Why this still belongs in an agent case catalog

The classification does not depend on an LLM call in every run. This system senses input signatures, selects a capability, changes an external system, verifies the result, applies bounded recovery, and expands its capability set through failure cards and pipeline lifecycle.

Its autonomy is deliberately narrow: unknown signatures are rejected, and accepted work must leave a verifiable result and queryable state. If the implementation were only one fixed script without sensing, selection, external acceptance, or capability lifecycle, the agent label would add little explanatory value.

10. A seven-step transfer method

1. Select a repeated delivery workflow with limited input types and observable failure.
2. Divide it into stages; define one authoritative output and error signature per stage.
3. Mark exact parameters that downstream stages must read rather than regenerate.
4. Add an acceptance check outside the publishing process: a real request, database readback, or delivered-file inspection.
5. Record three real failures before deciding which may retry and which must abort.
6. Give capabilities draft, candidate, and active states; revoke certification after code changes.
7. Measure sequential operation before adding concurrency, dynamic planning, or a runtime model.

The structure can support media transcoding, model deployment, report publication, static-site release, and other repetitive delivery workflows.

Original runtime views

How the console carries dataset facts and failure knowledge forward

11. Failure signals and evidence gaps

The current material supports file-signature routing, the HTTP-200 false-success failure, the metatile root cause, and the lifecycle mechanism. It does not establish superiority under large-scale concurrency. A later report should add per-pipeline run count, success and takeover rates, false successes found by verification, rule hit rate, and recertification time.

12. ADPS mapping

Contributor and citation

Case contributor: Yuke Xiong, Xuanxu Technology.

Suggested citation: ADPS and Yuke Xiong, "Xuanxu Technology's GIS Publishing Agent: Turn Runtime Experience into Verifiable Pipelines," ADPS Engineering Case Reports, Case Report 02, v0.4, 2026.

Edit source · Published source · Review process