Field notes: the afternoon a cluster of embeddings turned out to be one risk
It started as a sanity check, not a discovery mission. We'd just gotten a batch of site-level embeddings back and wanted to make sure the vectors weren't just reproducing variables we already had on file: year built, roof area, line of business, the usual. So we ran a quick k-means pass over the embedding space, nothing fancy, and sorted the clusters next to our coded attributes to see if anything lined up.
Most clusters did what you'd expect. Warehouses grouped with warehouses, farmland with farmland, dense urban blocks with other dense urban blocks. Boring in the right way. Then one cluster sat there refusing to make sense.
Forty-one sites, pulled from four different cedants, spanning three states and two lines of business we underwrite separately. Nothing in the coded data explained why an embedding model would lump them together. Different occupancy codes, different construction classes on paper, different submission dates going back six years.
We pulled imagery thumbnails for a dozen of the forty-one sites and found a pattern a coded attribute would never catch. Each roof had identical geometry: flat, with shallow retention ponds tucked into the back corner. Each site sat on ground that had been regraded the same way, with a drainage cut running toward a river bend that showed up in three counties but never looked native to any of them. The service roads even angled off in the same direction relative to that bend, like someone had copied a site plan and pasted it across fifteen years of permits.
None of this showed up as flood exposure in the usual sense. The sites sat outside the mapped 100-year zone, protected on paper by a levee system that, from the air, you could see had been built in sections at different times by different jurisdictions. The embedding model had no idea what a levee was. It just noticed that forty-one roofs looked like the same roof, built by the same hand, in the same kind of terrain, and it put them next to each other in vector space because that's what it's built to do.
What we had was a correlation nobody had coded for, because no submission form asks about "built by the same contractor on similarly reclaimed ground near a river bend." It's a construction fingerprint, visible only because we were looking at pixels instead of the fields we'd already decided mattered.
This is the part that's hard to explain to someone outside the trade. We'd set out to check a new data feed for redundancy, and instead tripped over an accumulation we'd have otherwise priced as forty-one independent risks. Run the correlated-loss scenario on that cluster and the tail gets a lot fatter than our flood zone overlays would ever suggest, because the zone overlay doesn't know about shared construction practice. It only knows about elevation and a FEMA line drawn by people who never saw the retention ponds.
The lesson we took away was narrower than "buy more imagery": a similarity signal you didn't ask for can surface a dependency you didn't know to model, and the only way to see it is to let the imagery speak before you force it into your existing taxonomy. That's the case for treating a site's embedding as its own feature, a vector per site that a model builds for itself from the imagery, not a checklist someone fills in once and forgets. We're testing that as an input into the book-level scoring now, which is a longer piece for another month, but the cluster is the reason we started.
If your book has a version of that cluster sitting in it, you'd want a way to find it before renewal season does. Imagery Embeddings is built for exactly that kind of question, and it's worth a look.