an intelligent layer over enterprise spatial data

organisations hold decades of spatial data — asset registries, service boundaries, inspection histories, parcel records. it is complete, current, and effectively unavailable. answering “which transformers near a school predate 1995?” means locating someone fluent in both the schema and spatial sql, and waiting for their attention.

the goal is not to replace those systems. the databases, the coordinate systems and the operational processes around them are correct and hard-won. what is missing is a layer above them that turns a question into the right query, performs the analysis the question implies, and shows its work — so that asking becomes as cheap as reading a dashboard, without anyone giving up the system of record.

two properties make that layer harder than a text-to-sql box. spatial questions usually require more than one operation — a containment test feeding a density calculation, a geocode feeding a radius filter. and spatial results are difficult to check by eye: a query returning fifty rows where four are correct still returns fifty plausible rows on a map that renders normally. the architecture below is shaped by both.

the model is not given a database connection. it is given four operations, and each one is validated before it runs and observable after. a turn is a loop over those operations, capped at eight steps, with results fed back so the model can revise — a failed query is an observation, not a dead end.

the boundary matters more than the loop. sql is validated select-only and single-statement before execution; the engine itself is opened read-only, with a statement timeout and a row cap; python runs in an isolated subprocess with resource limits and an audit hook that denies network, filesystem and process spawning. analysis code only ever touches rows handed to it, so denying everything else costs nothing legitimate.

the operations above compose into three delivered stages. each stage changes what the system is, not merely what it can do: the first makes a database answerable, the second makes it analytical, the third lets it reason beyond the data the organisation owns.

the harness drives a running instance over http — the same request path a browser uses — so routing, authorisation, the agent loop and map materialisation are all under test together. every expected answer is computed directly from the underlying data. none is taken from a previous model run, which would only measure consistency with an earlier mistake.

assertions go well past substring matching. a case can require an exact feature count, a maximum geographic spread across rendered points, specific map actions, forbidden strings, or a minimum number of reasoning steps. the assertions that caught real defects were rarely the obvious ones: a spread limit caught an origin that had geocoded to the wrong continent; an exact count caught a predicate off by one at a polygon boundary.

questions were written to be adversarial rather than demonstrative — two-level computations where taking the wrong extreme still yields a plausible winner, ordering questions where inversion is a single character, and coverage questions whose correct answer is a refusal.

each of these is a real case from the harness. the third is included because it fails.

a full run of the default suite passed 41 of 52 executed cases. three further cases could not run — a host filesystem fault took the sqlite fixture offline mid-run — and are excluded rather than counted as failures, since nothing about the system under test was exercised.

the aggregate is less interesting than its composition. classified by what actually went wrong:

the composition matters more than the total. most failures produced an answer rather than an error, which is why the harness asserts on values and rendered output rather than on execution success — a suite that only checked whether the query ran would have scored this same run near-perfect and taught nothing.

the two control failures share a single cause: the agent occasionally ends a turn by claiming the data is absent without running a step. it is not a spatial defect, it predates this work, and it is the highest-value thing left to fix.

each of these produced a plausible wrong answer in testing. each is now handled deterministically, below the model, because instruction alone proved insufficient — the model followed the guidance most of the time, and most of the time is not a guarantee.

the generalisation: where a wrong result is indistinguishable from a right one at the interface, the check belongs in the system, not the prompt. prompts shape a distribution; guards establish an invariant.

trust is not a confidence score. every response carries a recipe: the plan, the exact query that ran, the engine and the mode it ran in, the sources, the coordinate reference system, and a timestamp. a reader can audit the method without reading the code.

the recipe stores the shape of the map rather than its contents, which means an answer can be re-executed against the current database without invoking the model again. it functions as a citation and a refresh mechanism at the same time — and it makes the correctness question answerable by inspection rather than by trust.

many operational questions concern things no enterprise table contains — the pharmacies near an asset, the transit stops inside a service area. these are fetched live from openstreetmap, with categories drawn from a curated vocabulary rather than allowing free-form query generation: predictable cost, no syntax errors consuming agent steps, and an unrecognised category fails with the valid list instead of returning nothing.

public results arrive in the same row shape as database results, so the operations compose: a query locates the asset, a fetch retrieves nearby public features, and a python step applies a true radius. the project's own tables take precedence — and judging that turned out subtle. a restaurant-licensing table contains businesses with “pharmacy” in their trading name and none with a pharmacy category. matching on name looks like coverage and is not.

the system is developed against a seven-stage model where each stage changes what it is, not merely what it can do. three stages are shipped and measured; the rest are stated as unbuilt rather than aspirational.

what i would not claim is uniform reliability. the harder multi-step cases pass roughly two runs in three, and the cause is the control failure noted above rather than any spatial defect. capability is broadly present; consistency is not, and reporting the aggregate without that distinction would be the same error this report is about.