Every GeoScreen tier runs on the same idea — an explicit rule behind every rating, not a guess. Tier 2
has been in development for a while now, and it’s worth actually explaining why, rather than leaving it as
“coming soon.”
The obvious answer — it just needs an engineer’s time on top of what Tier 1 already produces — isn’t
really it. That’s part of the picture, but it’s not what’s actually held things up.
The real constraint is the geology. Tier 0 and Tier 1 both run on free, nationally consistent mapping at
1:625,000 scale, which is genuinely fine for a screening-level assessment and openly licensed — which is
why it can be queried live, for every report, in seconds. Tier 2 needs a lot more detail than that —
mapping at 1:50,000, something like twelve times finer, the kind of resolution you actually need to say
where an intrusion sits relative to a site boundary rather than just “somewhere in this general area.”
That data isn’t free, and it isn’t available live.
Which changes more than just where the data comes from. Everything else in GeoScreen — flood risk,
heritage designations, mining legacy — gets pulled from a live public service the moment someone orders a
report, in parallel, and the whole thing’s assembled in under two minutes. Detailed geology at this
resolution doesn’t work that way. It’s licensed, delivered as files rather than a live service, so using
it at the speed GeoScreen runs at means downloading it, storing it, indexing it properly, and querying it
locally — a genuinely different piece of infrastructure, not something you bolt onto what’s already
there.
Realistically, that means a meaningful part of the platform moves toward a proper relational database
sitting behind the report pipeline, rather than the current pattern of firing off live calls to a dozen
public services every time someone orders a report. That’s not a small change. Most of the engineering
effort so far has gone into getting that live-query pattern right — timing it, handling the inevitable API
failures, keeping the whole thing to around ninety seconds end to end. Swapping a chunk of that for
something that has to be downloaded, kept current, and queried locally is closer to a different piece of
software sitting underneath the same reports than a module bolted onto the existing one.
While we’re in that part of the build, it’s opened up a related question worth mentioning honestly, even
though it’s early. Once there’s a proper database layer doing real work, there’s a genuine opportunity to
let a report pull in more than just GeoScreen’s own data. We’ve been looking at whether a customer could
attach other reports they’ve already commissioned — a third-party environmental search, say, or a UXO
report — and have GeoScreen fold the relevant findings into the same document, rather than everything
sitting in separate PDFs someone has to cross-reference by hand. Early thinking, not a committed feature —
but it’s the kind of thing that only becomes realistic once the data layer stops being “live call, use the
answer, move on.”
There’s a commercial question sitting alongside the technical one too. A report an engineer’s actually
reviewed costs more to produce than one that’s fully automated, so Tier 2 will likely be priced
accordingly — the real open question is less “should it cost more” and more whether it makes sense
per-report like the other tiers, or something closer to a subscription for teams ordering regularly, maybe
with the underlying GIS data available separately. Would rather take the time to get that right than ship
whatever’s fastest.
No launch date here — just the honest version of why it’s taking longer than “add more detail” makes it
sound.


