The challenge
A property owner opens their dashboard and sees a flood risk score of 68 out of 100. Then what? The score is accurate, and on its own it is unusable. To act on it, the owner has to know which parts of the building are exposed, which of the available adaptation products fit that building type and that hazard, and what any of it means for the CSRD disclosures their lender or insurer will ask for.
- The existing route to that answer was a long static questionnaire.
- Most owners never finished it.
- The ones who did still received a product list rather than an explanation.
What we built
We built an AI advisor that sits between the risk data and the product catalogue and holds a conversation instead of serving a form. It covers five hazard classes — flood, heat, wind, drought and wildfire — reads live property risk data from Climatiq and Open-Meteo, normalises both sources into one schema, and matches hazards against a catalogue of 97 adaptation products.
- Two or three questions, not a questionnaire. Where a property has no assessment on file, the agent picks a small number of high-impact questions rather than presenting the full form.
- Consistent with the existing platform. Answers map back to the same question tags the original form used, so product selection stays consistent with the platform's existing logic.
- CSRD/ESRS E1 export. Any conversation can be exported as a climate risk and adaptation report: eight sections covering scope, methodology, hazard exposure, materiality, adaptation measures, financial relevance, review, and a mapping table against ESRS E1 requirements.
- Multilingual. Replies in the language it was addressed in — currently English, German, French, Spanish and Dutch — and holds that language across a conversation.
How it works
Three specialised components handle a query.
- Asset BrainProperty data, risk scores and building characteristics
- Platform BrainSemantic search across the product catalogue, using pgvector and 768-dimension embeddings
- General BrainIntent classification and response generation
The hard part was latency. A naive implementation waits for intent classification, then retrieval, then generation, and the user watches a blank screen for five seconds. We run intent detection in parallel with response generation and stream tokens over Server-Sent Events from the first moment, appending product detail when retrieval resolves.
Results
0.81s
time to first byte, down from 5.05s — six times faster
5
hazard classes: flood, heat, wind, drought and wildfire
97
adaptation products matched against live property risk data
Engineering decisions worth noting
- No vendor lock-in. The LLM and embedding layers sit behind a provider interface with implementations for Google, OpenAI, Anthropic and local Ollama. Switching models is a config change.
- Reproducible output. Generation runs against a pinned seed, so the same question against the same property returns the same answer — which matters when the output feeds a regulatory document.
- Scoped to the property. An off-topic intent class catches prompt injection and questions unrelated to the building, its climate risks or its surroundings.
- Grounded. Google Search grounding is available for queries where the catalogue and risk data alone are not enough.
Outcome
A working system that takes a property, its live climate-risk data and a plain question, and returns a specific set of adaptation products with the reasoning behind them, plus a regulator-shaped PDF at the end of the conversation. Product matching was validated against the platform database to confirm parity with the existing questionnaire's selection logic.
What comes next
The current build assesses one property at a time. The architecture — a normalised risk schema, tag-based matching and templated reporting — was designed to extend to portfolio-level analysis and to tracking adaptation measures over time. Neither ships today.
Technology
- FastAPI
- PostgreSQL with pgvector
- Google Gemini 2.5 Flash
- text-embedding-004
- Server-Sent Events
- ReportLab