HASTE: Rapid Building Damage Assessment with Post-Disaster Imagery Alone

Paper: 2607.11838 Authors: Caleb Robinson, Anthony Ortiz, Simone Fobi Nsutezo, Cameron Birge, Meygha Machado, Marcelo Duarte, Joaquin Rivero Rodriguez, Anthony Cintron Roman, Kevin White, Inbal Becker-Reshef Categories: cs.CV

The Gap

Existing building damage assessment models work well on benchmarks like xBD, but they assume two things that evaporate in the first hours of a real disaster: (1) you have matched before-and-after satellite imagery, and (2) you have a labeled training set from a similar past event. For a new earthquake or hurricane hitting a region that’s never been imaged at this resolution before, neither assumption holds. The xBD-competition-winning pipelines need pre-event imagery that may not exist, and they need ML engineers to fine-tune models. Meanwhile, humanitarian responders need a damage map now — not after a week of data wrangling.

HASTE fills this gap by combining two approaches that work from post-disaster imagery alone, wrapped in a no-code interface designed for GIS analysts, not ML researchers. The first method lets a user label polygons directly on the post-disaster scene, trains a small segmentation model on those labels, and runs it across the full image. The second — and more interesting — method embeds every building footprint using a frozen foundation model, requires the user to label just a handful of buildings, and fits a logistic regression in the browser. The paper reports preliminary xBD experiments showing this embedding approach matches a fully supervised ResNet-50 baseline with roughly 1/20th of the labels.

Problem: Disaster hits, responders need damage map in hours
    |
    v
Assumption of existing models:
    [before+after imagery] + [training data from similar events]
    |
    v
Reality: Neither available for a new disaster on day one
    |
    v
Gap: No operational tool for "first-day" rapid assessment
    from post-disaster imagery alone by non-ML users
    |
    v
HASTE: Two methods, one no-code interface, post-disaster only
    |
    v
Evidence: Foundation-model embeddings + ~20 labels
    match supervised ResNet-50 with 1/20 labels on xBD
    |
    v
Conclusion: 30+ real-world disaster deployments since 2023,
    results delivered within hours to days

The Increment

One sentence: Before this paper, rapid building damage assessment required either matched before-and-after imagery with supervised models, or ML expertise to build custom pipelines — after it, a GIS analyst with post-disaster imagery and twenty minutes of labeling can produce a usable damage map.

Core Mechanism

HASTE is a web platform with two methods sharing one interface, each suited to different operational conditions.

Method 1 (Pixel-based): The user draws polygons directly on the post-disaster satellite image, labeling regions as damaged or intact. A small semantic segmentation model (the paper doesn’t specify architecture details but implies something lightweight) trains on these on-scene labels, then runs inference over the entire image. The per-pixel predictions are then spatially joined to existing building footprint polygons (e.g., from OpenStreetMap or Microsoft Building Footprints), producing a per-building damage classification.

Method 2 (Embedding-based): Every building footprint in the scene is extracted and its bounding box crop is passed through a frozen pretrained vision foundation model (likely something like a DINOv2 or CLIP vision encoder, though the paper references foundation models generally). This produces a high-dimensional embedding vector for each building. The user labels a small number of buildings (perhaps 20-50) as damaged or intact. A logistic regression model fits on these labeled embeddings directly in the browser — no server round-trip needed. The fitted model then scores every remaining footprint in the scene, producing damage probabilities for the entire area in seconds.

Method 1 (Pixel-based):

  [Post-disaster image] --> [User draws polygons]
       |                         |
       v                         v
  [Small segmentation     [Labels: damaged/
   model trains            intact polygons]
   on single scene]              |
       |                         |
       v                         v
  [Full-image inference] --> [Join to footprint polygons]
                                    |
                                    v
                            [Per-building damage map]


Method 2 (Embedding-based):

  [Post-disaster image] --> [Extract building footprints]
                                    |
                                    v
                            [Crop each footprint bounding box]
                                    |
                                    v
                            [Frozen foundation model]
                            [embeds each crop]
                                    |
                                    v
                            [Embedding vectors per building]
                                    |
       +----------------------------+
       |
       v
  [User labels ~20 buildings] --> [Logistic regression]
       (in browser, seconds)            |
                                        v
                                [Score all buildings]
                                        |
                                        v
                                [Per-building damage map]

The two methods share a key insight: you don’t need to train a damage detector from scratch on a large labeled dataset. Instead, you either let a small model learn what “damage” looks like in this specific scene (Method 1), or you leverage a foundation model that already knows what buildings look like in general and just needs a few examples to calibrate its judgment (Method 2).

Think of it like this. You’re a seasoned building inspector who’s assessed thousands of structures after disasters. You carry a mental library of what damage patterns look like — crushed corners, shifted foundations, collapsed roofs, debris signatures. You don’t need a “before” photo of every building; you know what a building should look like, and you can spot when something’s wrong.

Now imagine you arrive at a new disaster site with a junior inspector who’s never done this work. You (the foundation model) have the expertise. The junior inspector (logistic regression) doesn’t, but they’re fast and can cover the whole area. Here’s how you work together: You walk through a few buildings together. You point to one and say “that roof is caved in — damaged.” You point to another: “intact, just some cosmetic cracks.” After 20 examples, the junior inspector has calibrated their eye to yours. Now they go run through the remaining 5,000 buildings on their own, applying the same pattern.

The foundation model is you — the expert with a deep prior understanding of visual structure. The logistic regression is the junior inspector — simple but fast, once calibrated. The few user labels are the calibration examples. And because the expert’s knowledge (embeddings) is so rich, the junior inspector doesn’t need many examples to get it right.

Key Concepts

• Foundation model embeddings: Imagine you could take any photograph and compress it into a list of 768 numbers that capture everything meaningful about what’s in it — shapes, textures, spatial relationships, semantic content. That’s an embedding. A foundation model like DINOv2 or CLIP has been trained on hundreds of millions of images and has learned to produce these rich summaries automatically. For building damage assessment, the embedding of a damaged building will naturally land in a different region of this 768-dimensional space than an intact building, even though nobody explicitly taught the model about “damage.” The model learned general visual structure, and damage happens to be a structurally distinct visual phenomenon. This is why you can separate damaged from intact buildings with just a handful of labeled examples — the hard work of representation learning is already done.

• Few-shot classification in practice: “Few-shot” gets thrown around a lot in ML papers, often meaning “we trained on a lot of data and then fine-tuned on a little.” HASTE’s use is closer to the literal meaning: a human labels maybe 20 buildings, and a simple classifier (logistic regression) learns to separate the two classes in embedding space. The reason this works here and often fails elsewhere is that the embedding space is already well-structured by the foundation model. If you imagine the 768-dimensional space, all the damaged buildings cluster in one region and intact ones in another — you just need a handful of points to find the boundary between clusters. This is the practical sweet spot between “zero-shot” (no labels, relies entirely on model priors) and “fully supervised” (thousands of labels, trains a custom model).

• No-code operational tool: This isn’t a research notebook or a command-line script. It’s a web application where a GIS analyst clicks buttons, draws polygons, labels buildings from a dropdown, and gets a damage map. The ML happens invisibly — the segmentation model trains on the backend, the logistic regression runs in the browser, the user never sees an embedding vector or a loss curve. This design choice is arguably the paper’s most important contribution, because the best damage assessment model in the world is useless if the people who need it (emergency responders, humanitarian organizations) can’t operate it.

Framework Shift

Before (mainstream approach):         After (this paper):

[Pre-disaster image]                  [Post-disaster image]
       +                                      |
       v                                      v
[Post-disaster image]                 [Foundation model]
       |                                     |
       v                                     v
[Image registration]                  [Embedding per building]
       |                                     |
       v                                     v
[Supervised model                     [User labels ~20 buildings]
 trained on 1000s                         |
 of labeled pairs]                        v
       |                             [Logistic regression]
       v                                  (in browser)
[ML engineer deploys                       |
 and maintains]                            v
                                    [Per-building damage map]
       v                                  (minutes)
[Per-building damage map]
  (days to weeks)

From two-image supervised pipelines to foundation-model embeddings over post-disaster footprints, the core shift is eliminating the before-image dependency and most labeling through pretrained visual understanding.

Expert Assessment

Problem choice: This is a genuine and important gap. The ML-for-disaster-response community has produced impressive benchmark results (xBD challenge winners, various segmentation papers), but there’s a persistent disconnect between benchmark performance and operational utility. The assumptions baked into competition setups — matched before/after imagery, large labeled datasets, compute for training — rarely hold when a disaster strikes a new area. HASTE addresses the “day one” problem head-on, which is where humanitarian need is most acute and existing tools are weakest. It’s not a manufactured gap.

Method maturity: The embedding-based approach (Method 2) is the real contribution, and it’s more clever engineering than scientific novelty. Using frozen foundation model embeddings + a simple classifier is a well-known recipe in the broader ML community (it’s essentially what CLIP-style zero/few-shot pipelines do). Applying it to satellite imagery damage assessment with a focus on operational deployment is the insight. Method 1 (scene-specific segmentation training) is less novel but operationally valuable as a fallback when foundation models aren’t available or suitable. The simpler approach being overlooked? Maybe just using the foundation model directly in a zero-shot manner (prompt-based classification), which the paper mentions as a future direction under “vision-language assessment.”

Experimental integrity: This is the paper’s weakest section. The xBD experiments are described as “preliminary,” and the details are thin. The claim that foundation-model embeddings match a supervised ResNet-50 with 1/20th of the labels is compelling but needs more rigor: What’s the variance across disaster events? How sensitive is the method to the choice of which buildings the user labels? What happens on the hardest damage categories (e.g., distinguishing “minor” from “major” damage)? The 30+ real-world deployments are the strongest evidence, but the paper doesn’t report accuracy metrics from those deployments — presumably because ground truth wasn’t available in operational conditions. This is understandable but leaves the reader without a complete picture.

Writing quality: The paper reads like a system description with a brief experimental appendix, which is fine for what it is, but the experimental section (Section 4) is underdeveloped. If the authors expanded it with per-disaster breakdowns, ablation studies on number of user labels, and honest failure mode analysis, the paper would move from “interesting system” to “important reference.” The platform design and engineering sections are well-written and practical.

Verdict: weak accept — The operational impact (30+ real disaster deployments, humanitarian partners receiving results within hours) is the strongest argument for this paper. The research contribution is incremental but occupies an important niche. The experimental section needs work, but the real-world deployment track record compensates.

Takeaways

The embedding + linear classifier recipe transfers directly. If you’re working on any remote sensing classification task where labeled data is scarce, try: freeze a pretrained vision model, embed your image patches, label a few dozen examples, fit a logistic regression. You’ll be surprised how often this matches or beats a fully supervised model, especially in satellite imagery where pretrained features are rich.

Build for the user who has the problem, not the user who built the model. The no-code interface design is the reason HASTE has been deployed 30+ times. Most ML papers produce code for other ML researchers. If your work has a real-world beneficiary, invest in the tooling — it’s the difference between a paper and an impact story.

When foundation models are good enough, skip fine-tuning. The paper demonstrates that a frozen embedding + simple classifier can match a fine-tuned ResNet-50 for this task. In practice, this means faster iteration, simpler deployment, and easier maintenance. Before reaching for fine-tuning, check if embeddings alone get you 90% of the way there.