Feature store or flat CSV: versioning a site embedding across treaty years

When you're deciding how to bolt an imagery-derived feature onto a portfolio risk model, the interesting question isn't the embedding itself. It's where the thing lives between renewals. A feature store and a flat file solve different problems, and for a feature that updates once a year and gets joined into a scoring model you already own, the answer is less exotic than the tooling vendors would have you believe.

What a flat CSV actually gets you

A CSV or parquet file keyed to your site list does three things well: it joins cleanly against whatever you already run in SQL or pandas, it's trivial to diff year over year, and versioning it is just a dated filename or a tagged commit in whatever repo holds your model inputs. No schema registry, no serving layer, no on-call rotation for a database that's answering one query a year.

For a book where the embedding refreshes annually and feeds a batch scoring run rather than a real-time quote engine, that's most of what you need. Discipline handles the failure modes people worry about with a CSV: lost lineage, no audit trail, silent overwrites. Keep every vintage, never overwrite a file in place, and store the embedding model version as metadata next to the vectors instead of trusting anyone to remember it.

Where a feature store earns its keep

Feature stores exist to solve a different cluster of problems: point-in-time correctness across many training runs, serving features online at low latency, and coordinating a dozen teams pushing features into the same system without stepping on each other. If your firm already runs one because underwriting, pricing, and cat modeling all pull from it, feeding your imagery vector into that system is a reasonable thing to do, and you should just do it rather than stand up a parallel CSV pipeline.

But if you're asking the question because you're trying to justify standing up a feature store for this one feature, that's usually a sign the infrastructure is being matched to the tooling trend rather than the problem. One annual-cadence vector per site doesn't need an online store. It needs a join key that doesn't break.

The join key is where this actually goes wrong

The join key is what bites people a year or two in, long after the storage-format decision stops mattering. Your site list isn't stable across treaty years: risks drop off, new locations bind, a cedant re-codes its asset register and half your IDs change shape. If the embedding file is keyed to anything other than a durable site identifier (and ideally carries a geocode as a fallback), a left join drops unmatched rows without flagging them, or mismatches a 2024 vector to a 2025 risk that happens to share a row number.

A naming and keying convention handles this. Every annual file carries the site key your risk model already uses, plus a vintage column (capture year, or refresh date), and each year's file stays immutable once it's used in a production scoring run. When the book renews, join the current site list against the latest vintage using the site key, since row position shifts year to year and can't be trusted to line anything up. Keep every prior vintage around so you can reconstruct what the model saw in any given treaty year. That reconciliation step is the actual engineering work; the storage format barely matters.

A pattern that holds up

In practice: one file per refresh cycle, keyed to site ID, columns named generically (the values aren't human-interpretable anyway, so dim_000 through dim_n is honest labeling), a metadata row or sidecar noting the embedding model version, and a left join against your current book that leaves gaps for new sites until the next annual pass fills them in. No registry, no serving SLA, no team dedicated to keeping it running.

If you want to try this against your own site list, Imagery Embeddings delivers exactly that file: a vector per site, keyed to the IDs you already use, refreshed annually, built to plug into a risk model you're already running rather than replace it.

Worth testing against a slice of your book before deciding whether the feature earns a permanent column in the model.