M Montandon NotebooksReproducible disaster analytics

Proposal walkthrough

Turn crisis data into reproducible, discoverable analytics.

A set of analysis templates — Jupyter notebooks that take an admin area, a hazard and an event as parameters — run automatically or on demand, and publish as static HTML anyone can browse, share and reproduce. A thin Django app indexes them and orchestrates the runs.

See the walkthrough Technical architecture
3use cases: risk → impact → action
1Django app + worker pipeline
∞static, cacheable outputs
A rendered notebook showing an interactive 3D exposure map with floating widgets
Illustrative notebook output — an interactive lonboard map + manywidgets, rendered to static HTML.

One system, three questions

Risk → Impact → Action

The three use cases build on one another — from who is at risk before an event, to who was hit when it strikes, to where to act first. Same app, same pipeline, same notebooks; only the parameters and the trigger change.

Three linked stages: Use Case 1 Risk Exposure (before), Use Case 2 Impact Estimation (during), Use Case 3 Response Prioritisation (after)
For everyone The narrative arc of the three Montandon use cases. Explore each in depth →

The whole idea

Author once, generate many, distribute as static files

An analyst writes a notebook template that declares its parameters. The Django app orchestrates a worker that runs the notebook with real parameters, renders it to HTML, and publishes it to object storage. Users browse and open the results — the heavy analysis has already happened.

  • The heavy lifting (downloading data, computing exposure) runs once per notebook.
  • Distribution is just static HTML on object storage — cacheable, cheap, durable.
  • Anyone can re-run the same notebook locally with standard Jupyter tooling.
How it works under the hood
Four steps: author a template, orchestrate a run, publish static HTML, discover in the app
Overview The four-step pipeline, end to end.

Two ways in

Clear for users. Clear for developers.

🧭

For users & responders

Follow the journey — author or pick an analysis, choose an admin area and parameters, run it, and open the published result. No code required.

Walk through the app →
⚙️

For technical teams

Django API + notebook index, Celery workers running papermill, MyST rendering to static HTML, object storage, and event-driven triggers — on the IFRC GO stack.

See the architecture →

Design principles

Why it’s built this way

🧮

Compute once

The expensive analysis runs a single time per notebook. Outputs are frozen artifacts.

🗄️

Static distribution

Results are HTML files on object storage — served directly, bypassing the app and database.

🪶

Thin metadata layer

Django stores only light metadata & links. Notebook content never touches the database.

🔁

Reproducible

Every output is a real notebook. Re-run it locally, swap data sources, change parameters.

Explore the plan

Everything in this walkthrough

How it works

The end-to-end user journey: author → browse → select → generate → view → notify.

Open →

Use cases

Risk exposure, post-disaster impact, and response prioritisation — data, method and triggers.

Open →

Architecture

Django, Celery, papermill, MyST, object storage, the data model, and the sharp edges.

Open →

Automation & integration

On-demand, scheduled polling, and event-driven runs that write back to Montandon & the Charter.

Open →