A vector for every site in your book, from imagery.
Imagery Embeddings computes a learned vector per site and hands it back keyed to your own identifiers. It goes into your scoring model as one more feature. You don't write an attribute list first, and we don't score anything.
Your own pipeline
- 01Deciding what to extract
- 02Getting imagery for the schedule
- 03Turning pixels into columns
- 04Joining back to the book
- 05Refreshing
- 06Testing whether it helps
With Imagery Embeddings
- 01Send the site list
- 02Imagery is captured per site
- 03A vector is computed for each site
- 04The file comes back
- GSD
- ≤0.5 m (VHR)
- Cadence
- Annual
- Platform
- VHR satellite / aerial
- Spectral
- RGB
Where a new signal gets stuck
You want to know whether something visible from above adds to the tabular exposure data already in the model. So the team agrees an attribute list, finds imagery for the schedule, tags it or trains a detector per attribute, and joins the output back to the site IDs. All of that happens before anyone learns whether the column helps.
The list also fixes in advance what the team thought mattered, and the next signal means running the pipeline again. An idea can die at the pipeline stage without the feature ever having been tested.
Your pipeline and this one, step by step
| Step | Your own pipeline | With Imagery Embeddings |
|---|---|---|
| 01Deciding what to extract | The team agrees an attribute list up front, such as roof shape, vegetation close to the building or a pool. | No list. The vector is learned from the imagery, so it carries whatever is visible at the site. |
| 02Getting imagery for the schedule | You source imagery site by site, or buy a layer and find out which sites it leaves uncovered. | You send the site list and we capture imagery for each site. Sites without a usable pass are flagged. |
| 03Turning pixels into columns | Someone tags images or trains a detector for each attribute, then maintains them as the imagery changes. | One learned representation is computed per site and delivered as numbers. |
| 04Joining back to the book | Detector output is matched to site IDs by location, with the clean-up that involves. | The file arrives keyed to your own site identifiers. |
| 05Refreshing | The pipeline is rerun by hand ahead of each model rebuild. | A new vector per site each year, timed to your portfolio review. This is early access, so the first cycles are scoped with you. |
| 06Testing whether it helps | You add the column to the training set and see what the model does with it. | You do exactly the same with ours. |
| Still yoursThe model, the validation, the choice to keep or drop the feature, and every claim about peril or loss. | ||
What arrives in the pilot
- 01CSV
Per-site embedding file
One row per site in your list, one column per vector dimension, keyed to your identifiers. It loads into Python or R and joins to your training table. This serves the joining and refresh rows of the ledger.
Ledger row
- 02Documentation
Structure notes
A short write-up of how the vector was made and how many dimensions it has, enough for your team to put it in a model and describe it in the model documentation.
Ledger row
- 03Yearly file
Annual refresh
A new file each year for the same site list, lined up with your portfolio review. Sites added to the book join the next cycle.
Ledger row
- 04Flag per site
Coverage flags
Sites where we couldn't get a usable pass come back marked, so you can see which rows to leave out of a training run.
Ledger row
How it works
- 01
Send the site list
Your identifiers and a location for each site. You keep the rest of the schedule.
- 02
Imagery is captured per site
We capture or pull VHR imagery at 0.5 m or finer for each location. Cloud or a poor pass can delay a site.
- 03
A vector is computed for each site
A learned representation of what is visible at the site, written as a fixed-length list of numbers.
- 04
The file comes back
Vectors keyed to your identifiers, with the flags and the structure notes. Test it against your own model the way you'd test any new input.
Where it fits in your workflow
One more column group in the training table
The vectors sit next to your tabular exposure data, not in place of it. They are an input to the model you already own.
05Limits
- L1
It is an input, not a score
The vector has no loss meaning of its own. It says nothing about any peril until your model learns that from your data.
- L2
Validation is on your side
We haven't validated the vectors for any peril, line or loss type. Whether they help is for your holdout tests to show.
- L3
Resolution floor
At 0.5 m a pixel is about 20 inches across. A building and its surroundings show up as shapes and layout. A small fitting on a roof or a fence line may not. The vector summarises what that pixel size can see.
- L4
Clouds and bad passes
Optical imagery needs a usable pass. A site under cloud, or caught badly, can come back late or with a lower-confidence vector for that cycle.
- L5
What the old pipeline does better
A named attribute is easy to explain to a regulator or an underwriter. A vector dimension isn't. If your reviewers need "roof shape" as a column, tag it yourself.
- L6
Annual, not live
One refresh a year. It won't show a change made to a site between cycles.
06Who it's for
Switch if
- You own or feed a portfolio scoring model and want to test imagery as a feature without building a pipeline first
- You have a site list with locations and your own identifiers
- You're happy to validate a new input against your own data
Stay with your pipeline if
- You need named attributes such as roof type as explainable columns
- You want a finished risk score, rating or loss estimate
- You need imagery that refreshes more than once a year
- You need a product that's off the shelf today
Questions before you ask for access
Q01Is this a risk score?
No. It's a feature you feed into your own model. We don't score anything and we don't rate a site.
Q02What does the vector represent?
A learned numerical summary of what's visible in the imagery at that site. It isn't labelled to any single attribute.
Q03How do we check it against what we already use?
Put the vectors into the same training set as your current features and run your usual holdout and stability tests. Send a subset of the book first if you want to look before committing.
Q04What do we send and what comes back?
A site list with identifiers and locations. A file comes back with one row per site, plus flags for sites without a usable pass.
Q05Which model does it suit?
Anything that takes numeric columns. We don't tune it to a model type, and we don't build the model for you.
Q06What happens when a site has no good imagery?
It's flagged, and the vector for that cycle may be delayed or lower confidence. Leave those rows out or handle them as you would any missing feature.
Q07Who owns the imagery and the vectors?
Rights and licence terms are agreed in writing at the start of the pilot. If your legal or data-governance team needs them sooner, ask.
Q08How is it bought and priced?
Price depends on the number of sites and the imagery used. Tell us the size and nature of your book and we'll scope it to that.
Q09How often is it refreshed?
Once a year, in line with a typical portfolio review.
Test imagery on your book without building the pipeline.
Tell us roughly what your book looks like and what model the vectors would go into. We'll say what a pilot could cover.