MMontandon NotebooksReproducible disaster analytics

Triggers & integration

Automation & write-back

The same pipeline runs three ways: a user asks for it, a schedule finds a new event, or an event drives a run that feeds its result back into the wider ecosystem — including the International Charter.

Three trigger modes The polling flow Charter integration Extensibility

Use Case 1

On-demand

A user selects a template, an admin area and parameters, and runs it — for one area or a whole administrative level.

  • Fully user-driven
  • Great for planning & preparedness
  • Fan out across a country in one request

Use Case 2

Scheduled poll

A cron job polls Montandon for new events / activations meeting set criteria, then triggers the matching analysis automatically.

  • No human in the loop to start it
  • Maps event type → template + parameters
  • Re-runs as new products arrive

Use Case 3

Event + write-back

Same event trigger, plus the result is published back to Montandon as a STAC collection — consumable by Charter tools.

  • Closes the loop to the Charter
  • Prioritisation available via the STAC API
  • Notifies users with a direct link

Event → analysis

The polling flow

For now, a scheduled poll; webhooks from Montandon are a natural future upgrade so consumers learn of new records instantly.

⏱️

Poll

Cron checks Montandon for new events / activations.

→
🔎

Match

Criteria met? Map event type → template + parameters.

→
⚙️

Run

Enqueue the run; the worker executes & publishes.

→
📨

Notify / write back

Link users to the result; UC3 writes the STAC collection back.

Sequence diagram of the automatic event-triggered run including the UC3 write-back to Montandon
Sequence The event-triggered run — with the UC3 write-back highlighted.
Future

Polling is simple and robust to start. Later, webhooks from Montandon could push new records to consumers, cutting latency between an event appearing and its analysis running.

Closing the loop

Feeding prioritisation back to the Charter

Use Case 3 doesn’t just produce a page — it publishes a data product. The prioritisation becomes a Montandon STAC collection (response-prioritisation): one item per ranked area, carrying the composite score and component values, tied to the event by monty:corr_id, with a derived_from link to the EO response product and a link to the source Charter / CEMS activation.

Because it is correlated to the source activation, the Charter’s own identifier is enough to retrieve, in a single call, the ranked priority areas with their humanitarian context.

🗺️

Charter Mapper overlay

Surface the prioritisation as an overlay on an activation, so operators and value-added providers see — alongside the EO products — which areas the humanitarian analysis flags as highest priority for the next acquisition, mapping and response.

💬

Charter chatbot

A conversational client over the same API: ask “which areas should be mapped or served first for this activation?” in natural language and get the ranked areas with their supporting context.

Two-way value

Value flows both ways: the Charter feeds observed impact into Montandon, and Montandon returns prioritised humanitarian context to the Charter — a feedback loop back to the space-based response ecosystem. The client integrations are downstream; what this use case delivers is the data product and the API methods that make them possible.

Room to grow

Built to extend

Get the basic structure right, and these become incremental rather than rewrites.

New areas on demand

Run any analysis in a new country or with different parameters, without new code.

Arbitrary notebooks

Add new analysis templates over time as methods and data sources mature.

Field observations

Feed EOC reports from National Societies in as one more signal for UC3 — sharpening priority & confidence with ground truth, without changing the method.

Back to the overview Revisit the use cases