Generating scenario…
Destination readiness is computed as a weighted average of seven factor scores. Two factors — Security and Local Authority Consent — are designated gatekeepers and receive double weight, reflecting their role as non-substitutable prerequisites under IHL: a destination that is physically dangerous or legally inaccessible cannot be made viable by strong food supply or willing hosts.
| Status | Score | Rationale |
|---|---|---|
| Operational | 1.0 × conf | Fully functional; confidence-scaled |
| Partial | 0.5 × conf | Degraded function; confidence-scaled |
| Blocked | 0.0 | Non-functional; gatekeeper triggers cap |
| Unknown | 0.30 × (0.5 + 0.5·conf) | Epistemic conservatism — see §2 |
Uncertainty operates at two levels:
Factor-level confidence — each factor carries a base confidence value (0–1) generated at scenario creation, reflecting how well-assessed that factor is. The global Field Uncertainty slider scales all confidences multiplicatively:
Unknown status treatment encodes a key epistemic distinction: a known unknown is less dangerous than an unknown unknown. A factor assessed as "unknown" with high confidence (we are sure we don't know) scores higher than the same status with low confidence (we are not even sure our ignorance is accurate):
This models the real-world asymmetry in which a field team that reports "we could not assess food supply" provides actionable information, whereas a report produced under conditions where the team itself was unreliable provides less.
For each (evacuee group, destination) pair, 100 Monte Carlo runs simulate the outcome distribution arising from field uncertainty. In each run, every factor's assessed status is independently subjected to a perturbation test:
Success in a single run requires all three conditions:
The reported success rate is the proportion of runs meeting all three criteria. Standard deviation across runs quantifies outcome uncertainty — high SD indicates a volatile scenario where small real-world changes could flip the outcome.
Each evacuee group is assigned to the destination with the highest composite score, a linear combination of four sub-scores:
Weights reflect the priority ordering in humanitarian evacuation planning: protection quality first, physical fit second, operational burden third, population needs fourth. The capacity_fit cap at 1.0 prevents over-rewarding destinations that vastly exceed need.
All data is generated from a seeded pseudo-random number generator using the Park-Miller Linear Congruential Generator (LCG):
Using a seeded RNG means every scenario is fully reproducible by seed number — a critical requirement for thesis research where peer reviewers must be able to regenerate results exactly.
Destination capacity follows an exponential distribution (λ = 3, mapped to [200, 5000]) to reflect the realistic skew of humanitarian site sizes: many small sites, few large camps. Factor status distributions are weighted differently for gatekeepers (more likely impaired in active conflict) versus standard factors.
Groups are drawn from eight ecologically valid archetypes grounded in ICRC field taxonomy and IHL protected-person categories. Each archetype has fixed vulnerability, special-needs, and urgency properties; only group size is randomised per scenario.
| Archetype | Vuln. | Needs | Urgency |
|---|---|---|---|
| Elderly & mobility-impaired | 5 | mobility | immediate |
| Families with children | 4 | — | urgent |
| Wounded & medical cases | 5 | medical | immediate |
| Unaccompanied minors | 5 | medical | immediate |
| Pregnant women | 4 | medical | urgent |
| Unaccompanied adults | 2 | — | can-wait |
| Mixed general population | 2 | — | can-wait |
| Journalists & aid workers | 2 | — | urgent |
The vulnerability_match sub-score in §4 rewards destinations with operational medical capacity when a group has medical or mobility needs — operationalising the IHL principle of proportionate protection for the most vulnerable.
Assumptions
Scope & intended use
Math.random() is not called anywhere, ensuring full reproducibility.Parameter reference — all values are in the PARAMS constant at the top of the script and can be adjusted for sensitivity analysis without touching any other code.