Making Parcel Data AI-Ready: What 30 Years of Data Experience Taught Us
AI Can Read Your Data. Can It Understand It?
By Mike Schiewe
VP, Products and Services
For most of its history, geospatial data has been built to be machine-readable. It is structured, indexed, queryable. That was never really the problem.
The problem is that machine-readable and machine-understandable are not the same thing. A field can be perfectly structured and still be meaningless to anything, human or AI, that hasn't been trained on what that field represents. AI encounters data differently than the applications data has traditionally been built for: it doesn't arrive already knowing the schema. Increasingly, that same data needs to explain itself to a system encountering it for the first time and that's a different bar than "machine-readable" ever required.
When a Field Name Requires a Translator
Here's a small example that says a lot. Somewhere in almost every parcel dataset, you'll find a field like ADDR_SCR. If you've worked in this industry for a while, you probably already know that stands for an address quality score. If you haven't, there's no way to know that from the field name alone, you'd need documentation, a colleague, or trial and error.
That's fine for a person who's been staring at the same schema for years. It's a dead end for a language model that's never seen it before.
So we went through our parcel attributes and gave them names that carry their own meaning:
| Legacy Field | AI-Ready Field |
|---|---|
| ADDR_SCR | property_address_quality_score |
| FIPS | fips_code |
| STATE | state_code |
None of these changes are clever and that's the point. The value isn't in the sophistication of the rename, it's in removing the need for a translator at all.
AI-Ready Means More Than Renaming Columns
It would be easy to stop at field names and call the job done. We don't think that's accurate, and it's worth being precise about why.
There are really three layers to whether data is AI-ready:
Structure → Can the system reliably access the field?
Semantics → Can it understand what the field represents?
Context → Does it know how to interpret the value?
Renaming a column solves the second layer. It doesn't solve the third. A field called property_address_quality_score is a big improvement over ADDR_SCR, but a model still benefits from knowing what that score represents and how it should be interpreted. That's why we've paired the new field names with plain-language metadata descriptions. For property_address_quality_score, that description spells out how the score is calculated and what a low value should mean for how much weight to put on the address not just that the field exists.
It's also important to note that this isn't a schema overhaul. The underlying data hasn't been replaced, and customers can continue to work with it in familiar formats such as shapefiles. What's changed is that the same information now carries more of its own explanation for the people using it and for the systems increasingly sitting alongside them.
Thirty Years of Data Experience Matters
It would be fair to ask why this took real effort, rather than a find-and-replace on a column list. The honest answer is that renaming a field correctly requires knowing what it actually means, how it was constructed, how it relates to the fields around it, and how customers have historically used it.
This is where three decades of working with parcel data actually shows up. It's not just that we have a lot of records. It's that we've watched how these attributes get used, where their meaning can be misunderstood, and what questions customers ask when something doesn't line up. AI-readiness, done properly, depends on that kind of provenance. You can't document what you don't understand, and understanding is the part that doesn't come from a script. A field name that looks cryptic is often that way for a structural reason: shapefiles cap attribute names at 10 characters, which is how you end up with something like ADDR_SCR instead of a name that actually explains itself. That format made sense when shapefiles were the standard, but it's a poor fit for how data gets used today. Renaming a field properly means moving past that legacy constraint, not just running a find-and-replace on the old name. It's part of why we think AI-ready data needs to leave the shapefile-era limitations behind rather than work around them.
Better AI Starts With Better Data
Making data easier for AI to understand doesn't make the underlying data any better. The foundation still matters. Better labels don't compensate for gaps in the underlying data. AI-readiness still depends on the depth, coverage, and context of the dataset itself.
This is where the depth of the underlying coverage matters. Our lots, tracts, and quarter-quarters data, most recently expanded across Minnesota — nearly 1.7 million new polygons — is a good example. That level of detail exists because land records in this country weren't built on a single uniform grid, and representing those different land descriptions requires understanding the systems states and counties have used to describe land over time. Making that data AI-ready doesn't change what it took to build it. It just means the effort is easier to draw on.
The New Question to Ask Your Data Provider
If there's one shift we'd want readers to take from this, it's a change in the question they ask when evaluating data.
For years, that question was largely: can I get this data into my system? That's still necessary, but it's no longer sufficient. The better question is: does this data carry enough meaning and context for a system to actually understand it, without someone standing between the data and the model to translate?
That's the standard we're applying to the next generation of Whitestar data. The less time people and systems spend figuring out what the data means, the more time they can spend using it.