Note: This post is the second in a four-part series leading to the 20th anniversary of this blog.
I was recently at a conference that was primarily focused on climate risk. One particular panelist caught my attention when talking about analyzing vulnerabilities by first creating a digital twin and then using an AI model to analyze vulnerabilities to a structure and assess their impact. I was reminded of work I participated in over 20 years ago in which we built what would now be called a digital twin of a power plant and created an agent-based modeling system to analyze and assess its vulnerabilities and impacts. The similarity of the workflow and the purpose, despite being articulated in the terminology of the current technology environment, was inescapable.
Twenty years is enough time to watch the surface of a field change over and over again. When I started writing geoMusings in 2006, much of the work still felt closely tied to individual tools. Desktop GIS was the central experience of most users. Web mapping was already underway, but it had not yet fully rearranged expectations about how geospatial capability would be delivered, shared, and consumed. Open source was present, but in many places it was still treated as an alternative rather than part of the foundation.
That, of course, did not last. In the intervening years, our experience completely transformed a few times. Web services matured. APIs became ordinary infrastructure. Databases became more central to geospatial workflows. Cloud platforms changed assumptions about scale and delivery. Open source moved from the margins toward the core. More recently, geospatial work has increasingly been absorbed into broader data engineering, analytics, and AI workflows, often with a new vocabulary attached each time.
Those changes were real and some of them were profound. They altered workflows, architectures, expectations, and even broadened who could participate in the work. But one pattern repeated often enough to become familiar. Each new phase arrived with language suggesting a break from what came before, as if the field had finally become something entirely new.
Sometimes that was partly true. More often, it overstated the discontinuity. The interfaces and preferred architectures changed. The surrounding language certainly changed. But even as the geospatial field repeatedly reintroduced itself, something underneath it remained more stable than the churn suggested.
Stewardship is Core
While quite a lot changed, what persisted underneath was the purpose of the work itself. Methods improved; systems became more capable; some tasks became easier to scale, easier to share, and easier to connect with other forms of data and analysis. But the underlying responsibilities remained familiar.
The work was still about turning messy reality into usable representation. It was still about deciding what to include, what to simplify, what to measure, and what to leave out. It was still about context: where data came from, what assumptions shaped it, how current it was, how well it matched the task at hand, and how much confidence it deserved.
It was also still about connection. Geospatial work has always involved linking things that do not naturally line up on their own: datasets, systems, scales, institutions, and decisions. Some of the tooling got much better. Some of the interfaces became much smoother. But the need to integrate across boundaries never went away.
Neither did judgment. No matter how polished the software became, someone still had to decide whether a result was plausible, whether a layer was fit for use, whether a boundary meant what people assumed it meant, whether a model output deserved trust, and whether the representation being produced was actually useful for the decision in front of it.
And then there is stewardship, which I no longer think of as something surrounding the technical work. If anything, the relationship runs the other direction. Technical work orbits the problems the work exists to solve. Stewardship of those problems maintains the through-line of relevance across each successive round of technical change. Technical systems are concrete manifestations of concepts, abstractions, tradeoffs, and values. They give form to decisions about what matters, what gets represented, what gets measured, what gets preserved, what can be connected, and what kinds of use are being supported. But the implementation is not the whole of the thing. It is an expression of it, and it will always fall short of the full nuance underneath.
Seen that way, provenance, interoperability, maintenance, documentation, accountability, and long-term usefulness are not secondary concerns attached after the fact. They are part of the real work. More than that, they are what make the work real. They express whether the people building and maintaining a system are acting as stewards of something that others will need to trust, interpret, and use over time.
Technical implementation still matters, sometimes enormously. But it is not the highest expression of the work. It is a manifestation of the attempt to get that stewardship right.
That has been true with each generation of tools and it is true now in the early days of AI. The software has evolved but the responsibilities have remained.
Implementation is Ancillary
When I started this blog, I was early in my mid-career. I was very much a practitioner, an individual contributor. The technical work, the manifestation of the problems I was trying to solve, was my primary focus. That was where the fun was. That was where the unanswered questions were. That was where the work felt most immediate.
It was also hard to find documentation on the kinds of technical challenges I was working through. When I did find something useful, it felt like rain in the desert. So I started the blog, in part, to create the kind of content I was looking for in the hope that it might help someone else trying to solve similar problems.
That may sound a little strange now, in an environment shaped by AI chatbots, social media, and Reddit. But much of that did not yet exist, or at least not in forms that shaped daily technical work the way they do now. At the time, a blog and a web search could go a long way toward defining what was findable. So it all began in a very practical place. I was trying to think through difficult technical problems and, with some luck, leave behind something useful.
Over time, though, I came to see those technical details less as the full subject and more as evidence. They were not the deepest layer of the work. They were where the deeper layer became visible. A new tool could expose a shift in assumptions. A change in architecture could reveal a change in priorities. A standard could make a set of values legible. A workflow problem could expose friction between representation and use. Even a seemingly narrow technical decision could point to larger questions about trust, interpretation, maintenance, or institutional responsibility.
That changed my perspective, even if I did not always notice it happening in real time. What had initially looked like a series of technical problems increasingly looked like expressions of practice. Not because the technical details stopped mattering, but because they increasingly pointed to something larger.
I think that is part of what made the work continue to hold my attention. Tools age out, interfaces disappear, programming languages lose support, and architectures get absorbed into whatever comes next. But practice endures, even as it changes shape. The software was never the point. It was how people use technical systems to make sense of the world, and how much responsibility comes with that.
Continuity of Purpose
That continuity matters now because the current cycle has its own language of rupture. The vocabulary, interfaces, and scale are different. AI systems can summarize, generate, classify, extract, and connect information in ways that would have seemed implausible not very long ago. Some of that change is real and significant. It is already altering how technical work is approached, how quickly outputs can be produced, and how broadly certain kinds of capability can be distributed.
But it does not remove the underlying responsibilities. If anything, it sharpens them. Context is a good example. It still matters where data came from, what assumptions shaped it, how current it is, how well it matches the task at hand, and how much confidence it deserves. In a more abstracted environment, those questions do not become less important just because a system can produce plausibly fluent outputs. They become more important, because the distance between source material, technical process, and human interpretation can widen while the results still appear coherent.
The same is true of judgment. A system can make certain kinds of technical work faster. It can assist with representation, classification, summarization, and retrieval. But it does not relieve anyone of the responsibility to decide whether an output is plausible, whether the underlying material is fit for use, whether important nuance has been flattened, or whether a result deserves trust in the context where it will actually be used.
Stewardship does not recede, either. If technical work really does orbit stewardship, then more capable systems increase the importance of stewardship, not lessen it. The more abstracted the interface, the easier it becomes to lose sight of provenance, maintenance, accountability, interoperability, and long-term usefulness. Those are not residual concerns made inconsequential by a more advanced stack. They are core to the work itself.
Tooling alone has a way of leading us back to the same questions in a new vocabulary. Whether it’s devops, or cloud-native, or prompt engineering; functional or OOP; REST or MCP, it is easy to wrap new terminology around the same problem sets and call it innovation. Grounded in stewardship, focused on the problems to be solved, it becomes possible to use that new tooling answer questions better, and to hopefully move past them to better questions.
So while the present moment has its own rhetoric of transformation, I find myself returning to a familiar conclusion. The tools and scale may change dramatically. The technical manifestation of the work may change dramatically. But the need for context, judgment, and stewardship remains unchanged.
