Crisis & Disaster Intelligence Powered by Inkanyamba

The Disaster Cycle

One connected decision system — from baseline conditions through shock, response, assistance, recovery, and governance.

Preparedness & Warning

01Baseline & Preparedness What normal looks like before a shock. Locality profiles, infrastructure, markets. 02Early Warning Signals that feasibility assumptions may be changing before the shock fully lands. 03Emergency Response What changed, what broke, and which delivery constraints are now binding.

Response & Recovery

04Humanitarian Assistance Where the cycle becomes a delivery decision. Cash, vouchers, in-kind, hybrid. 05Recovery & Transition When constraints shift and the modality question changes again.

Analyses & Evidence

Structured feasibility assessments by context. Every verdict is traceable to evidence, scored against five constraint dimensions, and fully auditable.

Analyses

All Analyses Feasibility assessments by context, modality set, and constraint profile. Publication Standards Rules governing what gets published, how, and under what caveats.

Evidence

Evidence Method How sources are selected, assessed, weighted, and applied to scoring. Source Index 14 sources tracked. 12 QA passed. Full index with confidence notes.

Engine & Framework

Deterministic. Reproducible. Auditable. Every result can be re-run from the same inputs and will return the same output.

◆ Inkanyamba

Named after a storm-force from Southern African tradition — Inkanyamba appears when systems are under stress and decisions cannot wait. That is exactly the context this engine is built for.

Engine

How Scoring Works How INKANYAMBA computes feasibility verdicts across five constraint dimensions. Input / Output Contract What the engine accepts and what it returns as structured output.

Framework

Feasibility Dimensions Access · Market · Financial · Regulatory/Operational · Protection Classification Logic How dimension scores produce verdicts — Feasible, Conditional, Constrained, Not Advised.

About CDI

A crisis and disaster decision-intelligence platform. Built for judgment under pressure, not for reporting after the fact.

Project

Mission What CDI is built to do — and what it explicitly is not. Governance & Corrections How errors are identified, corrected, and logged publicly. Blog Updates, method notes, and field observations from the CDI project.

Contact

Get in Touch Questions, collaboration requests, and general outreach. Submit a Correction Found an error in an analysis or source? Submit it for public review.

Engine Specs

Engine Specs

The CDI platform runs a deterministic set of engines across the six disaster‑cycle phases. Each engine is described by a CycleEngineSpec data class (see hadip_engine/cycle_engines.py). The table below is the public‑facing summary.

Phase	Engine ID	Engine Label	Status	Role	Core Question
Baseline & Preparedness	`baseline_readiness_engine`	Baseline Readiness Engine	planned	source	What was already fragile, functional, or prepared before the shock?
Early Warning	`signal_reassessment_engine`	Signal Reassessment Engine	planned	trigger	Which assumptions have changed enough to require a new feasibility run?
Emergency Response	`shock_delta_engine`	Shock Delta Engine	planned	transform	What changed, and which constraints are now binding?
Humanitarian Assistance	`inkanyamba_modality_engine`	INKANYAMBA Modality Feasibility Engine	implemented	decision	Which assistance modalities are feasible, constrained, or not advisable here, and why?
Recovery & Transition	`transition_reassessment_engine`	Transition Reassessment Engine	planned	reassessment	When should modality assumptions be revised for recovery or transition programming?
Method & Governance	`governance_audit_engine`	Governance Audit Engine	planned	governance	Is this output traceable, reviewed, caveated, and safe to publish?

How to use this page

Developers: call list_cycle_engines() from hadip_engine/cycle_engines.py to get a JSON‑serialisable version of the same data.
Funders & partners: read the table to understand what each phase does and where the decision‑support logic lives.