Every GeoScreen report today is built much the same way: the moment someone orders one, the platform fires
off live calls to around twenty different public data sources in parallel — Environment Agency flood
mapping, BGS geology, Natural England’s ecological designations, and so on — and assembles whatever comes
back into a report, typically inside ninety seconds. Most of that data isn’t stored anywhere ahead of
time. Each report starts from scratch and pulls it fresh on the spot.

There are exceptions, and they’re the interesting part. A handful of sources are already held locally
rather than queried live — the national heritage registers, the environmental permitting registers, a
historical map gazetteer of over a million labels, and OpenStreetMap infrastructure data. Some of those
were never offered as a live service in the first place. One of them, OpenStreetMap, we moved deliberately:
the public query service we’d been using accounted for the large majority of our data-retrieval failures
over a three-week stretch, and because the platform handles a missing source gracefully, those failures
were nearly invisible. Downloading the data and holding our own copy removed the dependency entirely. But
these are flat files read from disk, not a database — which turns out to be the distinction that matters.

The live-API pattern has worked well, and it’s worth explaining why rather than assuming it’s obviously
the right call. It means the data is always current — there’s no refresh job to run, no risk of serving
something stale, no database to maintain at all. For openly available public datasets, that’s about as
low-maintenance as this kind of platform gets.

It hasn’t been free of cost, though. Public government data services aren’t really built for the kind of
concurrent, real-time querying a product like this depends on — several of them are genuinely slow, some
drop connections under load, and a few have needed real resilience work over time just to behave
predictably: retries, longer timeouts, fallbacks for when a call doesn’t come back in time. None of that
shows up to someone reading a finished report, but it’s been a real, ongoing part of keeping this
architecture working properly.

The limit isn’t reliability, though — it’s that not every dataset worth having is available live at all.
Some genuinely useful data is licensed rather than open, and it’s delivered as files you download once,
not a service you query per request. There’s no live endpoint to call. And it’s a different order of thing
from the flat files we already hold: detailed geology at 1:50,000 across a nation isn’t something you read
top to bottom for every report. Using data like that means a different pattern entirely: download it, store
it properly, index it, and query it locally instead of live — a real database sitting behind the report
pipeline, not a small addition bolted onto the existing one.

That’s the actual distinction worth drawing out. A live API call is simple exactly because there’s
nothing to maintain on our end — the tradeoff is total dependence on someone else’s service being up, fast,
and unchanged. A database flips that: you take on the work of keeping the data current and the
infrastructure running, but in return you get data a live API was never going to offer — either because
it’s licensed and never was available as a service, or because you can ask it questions a single per-report
query can’t easily answer.

Once a real data layer like that exists behind part of the pipeline, it’s natural to start weighing what
else it could be used for beyond the one thing it was built for. Nothing here is decided or scheduled, but
it’s worth being honest about the kind of thing we’re actually looking at. Whether a report could
eventually pull in more than just our own findings — a third-party environmental search or survey a
customer’s already commissioned, folded into the same document rather than sitting in a separate PDF — is
the one we’ve mentioned before and are still genuinely looking at. Beyond that, having structured, locally
held data opens up things a live-only architecture can’t really do — comparing a site against historical
patterns, running checks across many sites at once — none of it committed, just the natural direction a
database opens up that live calls on their own don’t.

No specific plans to announce, and nothing here changes what GeoScreen does today. It’s just a genuinely
different way of building the same kind of product, not a small technical detail.