Every GeoScreen report today is built the same way: the moment someone orders one, the platform fires
off live calls to around seventeen 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. Nothing is stored ahead of time. Nothing is
pre-fetched. Every report starts from nothing and pulls fresh data on the spot.

That’s worked well, and it’s worth explaining why rather than assuming it’s obviously the right call. A
live-API pattern 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. 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.