Child-Impact Ledger — Methodology

Version: v0.1.0 (matches LEDGER_VERSION in lib/ledger.ts) Status: Draft — refined throughout the demo sprint, peer-reviewed in grant phase License: CC-BY 4.0

The Child-Impact Ledger turns facility risk profiles into six concrete, audit-able monthly metrics that quantify what is at stake for children right now at each facility. These same definitions feed the Day-6 Counterfactual Deployment Simulator — the Simulator computes counterfactual deltas using the exact formulas documented here.

1. The six metrics

All six are baseline values in v0 — they describe the current per-month exposure given the synthetic risk profile, not a counterfactual saving. The Simulator (Day 6) computes savings by running the same formulas with reduced inputs after an intervention.

2. Formulas

2.1 Children served (monthly)

children_served_monthly = facility.population.children_served_estimated

Direct from facility record. For schools this equals enrolment; for clinics it's estimated paediatric throughput.

2.2 Service hours at risk (monthly)

service_hours_at_risk_monthly = monthly_unbacked_outage_hours

Unbacked outage hours are the hours per month when neither grid nor generator is supplying power. These are the hours when services genuinely interrupt — diagnostics offline, cold storage warming, water pumps idle, lights out in classrooms.

In v0 this is a single number sourced from the risk profile. In grant phase it comes from sensor telemetry — specifically the count of contiguous "grid off + generator off" intervals.

2.3 Vaccine doses at risk (monthly)

if facility has cold_chain_active:
    monthly_doses_delivered = children_served × 0.10
    outage_fraction = monthly_unbacked_outage_hours / 720
    vaccine_doses_at_risk_monthly = monthly_doses_delivered × outage_fraction
else:
    vaccine_doses_at_risk_monthly = 0

Assumptions:

• An average of 0.10 routine-immunisation doses are administered per child per month, across the calendar (covers BCG, polio, DPT, measles, COVID, etc., averaged across cohorts). This is a programme-level approximation; per-country fine-tuning happens in grant phase.
• Vaccines spoil when the cold chain warms beyond threshold; for v0 we use unbacked outage fraction as the proxy for cold-chain breach risk.

Why this matters: a small PHC with 1,500 children but 50 unbacked outage hours/month has roughly 1500 × 0.10 × (50/720) ≈ 10 doses at risk per month — enough to compromise routine immunisation for one local cohort.

2.4 Classroom hours lost (monthly)

if facility is education sector:
    classroom_hours_lost_monthly = min(monthly_unbacked_outage_hours × 0.4, 176)
else:
    classroom_hours_lost_monthly = 0

Assumptions:

• 40% of outage hours overlap with school hours (~8h × 22 days = 176 h/month). The other 60% are after-hours/weekends/holidays.
• Outages during school hours interrupt teaching (no lights, no AC in heat-stressed Kano classrooms, no laboratory equipment, no computer-aided learning).
• Capped at 176 — even a constant outage cannot lose more than one month of school hours.

Refinement in grant phase: real school timetables and term calendars per facility replace the 0.4 overlap heuristic.

2.5 Diesel litres consumed (monthly)

monthly_gen_hours = 720 × diesel_runtime_ratio
diesel_litres_monthly = generator_capacity_kw × 0.5 × monthly_gen_hours × 0.30

Where:

• 0.5 is the average generator load factor (most backup gens are not fully loaded; 50% is a realistic average across Nigerian field deployments)
• 0.30 L/kWh is the standard fuel consumption for typical small/medium diesel generators (manufacturer datasheets agree within ±10%)

Why this matters: diesel cost is a major opex item for child-critical facilities; reducing diesel through solar+battery is both a climate and an affordability story.

2.6 CO₂ emitted (monthly tonnes)

co2_tonnes_monthly = (diesel_litres_monthly × 2.68) / 1000

2.68 kg CO₂ per litre of diesel is the IPCC stationary combustion default emission factor for distillate fuel oil / diesel.

3. Aggregation

/api/ledger/aggregate sums each metric across the filtered facility cohort and breaks down by sector and admin_1 (state). The aggregate response includes:

• totals — sum of each of the six metrics across the cohort
• by_sector — same metrics broken down by health / education / WASH
• by_admin_1 — same metrics broken down by state

Aggregation rule: sums are arithmetic — no double-counting, no weighting at this level. Aggregate is sum-of-parts and can be reconciled by calling /api/ledger/[id] per facility and adding.

4. Worked example — Lagos aggregate

For the 18 facilities in Lagos (filter: admin_1=Lagos):

The aggregate /api/ledger/aggregate?admin_1=Lagos returns the per-state rollup. Multiplying out by hand:

• Total children served across Lagos cohort = sum of children_served_estimated across 18 facilities
• Total diesel consumed = sum of per-facility diesel litres
• etc.

Because every per-facility value has a documented formula, the aggregate is fully reconcilable by an external auditor.

5. v0 → grant phase replacements

Every v0 input becomes a real signal in grant phase. No code change is required — the same computeLedger() function accepts whichever values come in.

5.1 Relationship between risk-profile fields and synthetic telemetry

The risk profile carries three fields about generator behaviour: monthly_outage_hours, monthly_unbacked_outage_hours, and diesel_runtime_ratio. In real life these are independent indicators that may diverge (a generator can run during grid-present hours for maintenance or peak-shaving, raising diesel_runtime_ratio above the outage-coverage implication).

For v0 synthetic telemetry (see lib/telemetry.ts), the generator uses the self-consistent interpretation:

gen runs ⇔ grid is off AND this hour is NOT one of the unbacked subset

→ gen_hours_in_telemetry ≈ monthly_outage_hours − monthly_unbacked_outage_hours
→ diesel_runtime_ratio_observed ≈ (monthly_outage_hours − monthly_unbacked_outage_hours) / 720

This means the synthetic telemetry's observed diesel runtime ratio may be lower than the risk profile's stated diesel_runtime_ratio for any facility where the gen runs during grid-present periods in real life. The FRI engine still uses the risk profile's stated value (which dominates the Power Vulnerability score); the telemetry generator only reconciles the outage / unbacked-outage / gen-runtime triplet so live dashboards display coherent numbers.

In grant phase, the real ESP32 generator current sensor measures gen runtime directly, and diesel_runtime_ratio is computed from observation — both fields become measured, not assumed.

6. Counterfactual computation (Day 6 Simulator preview)

The Simulator (spec section 8.3) uses these same metric definitions. For an intervention i applied to facility f:

baseline = computeLedger(f, rp_current)
post    = computeLedger(f, rp_after(i, rp_current))
delta   = baseline - post

rp_after() is an intervention-specific transformation of the risk profile. For example, "solar+battery sized to load" reduces diesel_runtime_ratio substantially, drops monthly_unbacked_outage_hours to near zero, and slightly reduces fuel_cost_share_of_opex. The delta in the six metrics is what the Simulator reports as the projected impact.

This is why the ledger is documented carefully now: the Simulator's defensibility depends on these formulas being clear and auditable.

7. Known v0 limitations

1. All inputs are synthetic. Realistic but not measured. Grant phase replaces them facility-by-facility as sensors come online.
2. The vaccine doses estimate uses a flat 0.10 doses/child/month. This averages across cohorts and immunisation calendars. Per-country tuning is a grant-phase research output.
3. The classroom overlap heuristic (0.4) is a placeholder. Real timetables replace it.
4. CO₂ from diesel only. Excludes embodied emissions, transport, methane leaks. These are out of scope for v0; the IPCC default is the standard donor-acceptable starting point.
5. No counterfactual deltas yet. Day 6 Simulator adds them; the formulas are already prepared.

8. References

• Spec v4.1 section 8.9 (Child-impact ledger)
• lib/ledger.ts — engine implementation (MIT-licensed)
• lib/fri.ts — companion FRI engine (uses the same risk profile inputs)
• IPCC 2006 Guidelines for National Greenhouse Gas Inventories, Vol. 2 (Energy), stationary combustion default factors
• WHO Immunization Coverage data (used as sense-check for the 0.10 doses/child/month figure)

Counterfactual Deployment Simulator — Methodology

Version: v0.1.0 (matches lib/simulator.ts) Status: Draft — peer review in grant phase Licence: CC-BY 4.0

The Simulator answers a single question: if a donor spends $X across these facilities under this strategy, what is the projected child-impact?

It is deliberately a counterfactual tool. It does not place orders, it does not dispatch contractors, and it does not bind any budget. It models the projected delta against the Facility Resilience Index (FRI) and the Child-Impact Ledger, then makes the trade-offs visible before any money moves.

This document describes the budget logic, the four prioritisation strategies, the four-intervention library, the smart-pick heuristic, the confidence band, and how the ledger delta is computed.

1. The simulation step

For each chosen facility in scope, the Simulator:

1. Reads the baseline FRI breakdown and ledger for that facility.
2. Picks an intervention — either the explicitly requested one, the cheapest applicable one, or the smart pick (described in section 5).
3. Synthesises a post-intervention risk profile by applying the intervention's deltas to the inputs the FRI engine reads.
4. Recomputes the FRI and the ledger against the new risk profile.
5. Records the projected (fri_before, fri_after, cost_usd, ledger_delta) tuple.

Once every facility has been evaluated, the Simulator orders them by the prioritisation strategy (section 3), then greedily commits cost against the budget until the budget is exhausted or the queue is empty.

The greedy step is intentional. A true integer-program optimiser is grant-phase work and adds little to the comparative narrative for the donor user.

2. The intervention library

Four interventions ship with v0. The library lives in data/interventions.json and is loaded at server boot.

Each intervention carries an effect block that describes how the post-intervention risk profile differs from the baseline. For example, solar_battery reduces monthly_unbacked_outage_hours by 80 % and diesel_runtime_ratio by 70 %; cold_chain_retrofit raises the implicit cold-chain reliability multiplier.

The per-facility cost is interpolated linearly inside the cost band as a function of facility size (monthly_users_estimated). The bands are deliberately wide to reflect honest market dispersion in Nigeria today.

3. Prioritisation strategies

Four strategies are available. Each sorts the candidate facilities by a different key.

The strategy is not opinionated. The Simulator surfaces the differences so the donor can see, side-by-side, which strategy serves which goal.

4. Honouring the budget

The Simulator never breaks the budget. The greedy commit step is:

for facility in sorted(scope, key=strategy):
    cost = costFor(facility, intervention)
    if cost > budget_remaining:
        continue          # skip, try the next one
    commit(facility, intervention)
    budget_remaining -= cost

Two consequences worth flagging to the donor user:

1. The committed list may be smaller than the candidate list. If the budget is small, the Simulator commits a few high-value facilities and stops. The unfunded remainder is exposed in the output so the donor sees the gap.
2. The order of evaluation matters. A cheaper facility may be skipped if it sits below a more expensive one in the priority order. This is by design — the strategy is the donor's stated preference and the Simulator honours it.

A future v0.2 will offer an "optimise within budget" mode that drops the strict ordering and lets the user see the budget-optimal cohort.

5. The smart-pick heuristic

When the donor does not pick an intervention, the Simulator chooses one per facility. The heuristic is intentionally simple:

1. List every intervention that is applicable to the facility (section 2).
2. For each, compute the per-dollar FRI reduction: (fri_before - fri_after) / cost_usd.
3. Pick the intervention with the highest per-dollar reduction.

This is the same per-dollar logic the Priority Deployment Ranker uses (see docs/methodology/ranker.md). It is not the same as maximising child-impact, because the Simulator weights by FRI rather than by the ledger directly. That keeps the smart-pick aligned with the priority strategy the donor selected at the top of the form.

6. Ledger delta computation

For every committed facility, the Simulator computes a six-metric ledger delta:

The deltas at facility level are summed to produce the cumulative-over-horizon block, which is the headline number a donor sees: "if you fund this plan, over the next 12 months you protect approximately N children, prevent M vaccine doses spoiling, save L litres of diesel."

These numbers are projections, not promises. They carry the confidence band described in section 7.

7. Confidence band

The Simulator returns a confidence_band_pct value alongside every projection. The default in v0 is ±25 %. This number is a honest acknowledgement of three sources of uncertainty:

1. Synthetic baseline data. Demo facilities have synthetic risk profiles; real telemetry will replace them in the grant phase.
2. Intervention effect uncertainty. Manufacturer specs and field experience disagree by roughly ±15 % on the actual outage reduction from a given solar+battery install.
3. Behavioural uncertainty. Operators do not always run new equipment as the manufacturer assumed. Maintenance regimes, fuel availability, and staff turnover all introduce real-world drift.

In the grant phase, the band tightens as live telemetry replaces synthetic data and as the platform accumulates a track record of predicted vs. observed deltas.

8. What v0 does not do

• Spot-market diesel prices, FX, or grid-tariff variation. These move week to week and would add noise rather than insight at the donor briefing level.
• Carbon-credit revenue projections. We chose to leave the ledger CO2 column as a physical quantity rather than monetise it. Donors who want a carbon-credit overlay can do so externally with the published number.
• Optimisation under stochastic outage realisations. The demo treats the monthly outage hours as a point estimate; the grant build will swap in a Monte Carlo step over a posterior distribution fitted to telemetry.

9. Worked example

A donor enters: budget $50,000, horizon 12 months, strategy balanced, intervention smart_pick, scope all of Lagos State.

The Simulator runs through 27 Lagos facilities, sorts by the balanced composite, and greedily commits:

- lag-h-001  Mushin tertiary hospital     solar_battery        $34,800
- lag-h-005  Surulere PHC                 cold_chain_retrofit   $6,200
- lag-h-007  Yaba PHC                     basic_battery_inverter $3,400
- lag-w-001  Community borehole           water_pump_backup     $4,900
Budget committed: $49,300 of $50,000 (98.6 % utilisation)

Projected cumulative child-impact over 12 months:

+8,420 children protected
−2,180 vaccine doses at risk per month
−380   classroom hours lost per month
−1,840 litres diesel per month
−4.6   tonnes CO2 per month

The Simulator surfaces this block on the page, lets the donor click any of the four committed facilities to see the per-facility FRI delta, and provides the share-link / CSV / PDF export so the same scenario can be circulated to a ministry counterpart.

10. References

• World Health Organization, 2014. Effective Vaccine Management Assessment Tool.
• IRENA, 2022. Solar PV in Africa — cost and performance trends.
• Energy Sector Management Assistance Program (ESMAP), 2019. Energising health: accelerating access to electricity in healthcare facilities.
• Government of Nigeria, 2021. National Energy Compact.
• Sustainable Energy for All (SEforALL), 2023. Powering healthcare in Africa: financing models.

All references are open-access. Direct URLs and DOIs are in docs/references/simulator.bib.

Anticipatory Action Trigger Engine — Methodology

Version: v0.1.0 (matches lib/triggers.ts) Status: Draft — peer review and field validation in grant phase Licence: CC-BY 4.0

The Anticipatory Action Trigger Engine fires before a child-critical service fails, not after. The principle, lifted from the humanitarian anticipatory-action literature (FAO 2021; Anticipation Hub; START Network), is that a small amount of money spent in the 48 to 72 hours before a foreseeable shock prevents a much larger loss after it.

This document describes the rule DSL, the predicate operators the engine understands, the four pre-built rules shipped with the demo, the audit-log structure, and the approval workflow.

1. Anatomy of a rule

Every trigger rule is a JSON document with the following shape. The full schema lives in lib/types.ts (TriggerRuleSchema).

{
  "id": "CHILL-1",
  "name": "Cold-chain heat warning",
  "description": "Fires when forecast heat coincides with active cold chain and falling battery state-of-charge.",
  "severity": "high",
  "all_of": [
    { "var": "facility.services", "op": "contains", "value": "cold_chain_active" },
    { "var": "forecast.heatwave_days_next_72h", "op": "gte", "value": 1 },
    { "var": "facility.battery_soc_pct", "op": "lt", "value": 60 }
  ],
  "response": {
    "type": "dispatch_diesel_and_inspect",
    "budget_usd": 1200,
    "lead_time_hours": 48
  },
  "citation": "FAO 2021 — Anticipatory action in protracted crises"
}

A rule fires when every predicate inside all_of evaluates to true against the per-facility evaluation context. A rule does not fire if any predicate is false, missing, or malformed; the audit log records the reason in either case.

any_of is supported but used sparingly in the demo. We prefer conjunctive (AND) rules because they are easier for ministry approvers to reason about.

2. Predicate operators

Ten operators are supported. They cover the cases the demo rules need plus the predicates we expect Uganda partners to add in the grant phase.

Type coercion is strict. A predicate that compares a string against a number raises an error in the audit log and the rule does not fire. This matches the production-grade behaviour expected when the engine is wired to live forecast feeds.

3. Severity tiers and what they mean

The severity tier alone does not move money. Money moves when:

1. A rule fires, and
2. Its response.budget_usd falls inside the pre-authorised envelope for its severity tier at the relevant administrative level, and
3. The named approver (or their pre-authorised delegate) confirms within the rule's lead_time_hours window.

This three-step gate is the safeguard against false positives draining the response pool. Each step is recorded in the audit log.

4. The four pre-built rules

The demo ships with four rules, each tied to a specific child-impact pathway documented elsewhere in this methodology pack.

CHILL-1 — Cold-chain heat warning (severity: high)

Forecast heatwave × active cold chain × battery state-of-charge below 60 %. Fires roughly 48 hours ahead of the heat event. The response dispatches diesel and a technician to top up backup runtime before vaccines spoil. Tied to the vaccine-doses-at-risk ledger metric.

FLOOD-1 — Flood risk pre-positioning (severity: medium)

Forecast flood index ≥ 0.6 × facility within mapped flood zone × downstream of any patient-referral edge. Fires roughly 72 hours ahead. The response pre-positions emergency electrical isolation kits and ensures referral pathways stay open. Tied to the service-hours-at-risk ledger metric.

FUEL-1 — Fuel-reserve depletion (severity: medium)

Diesel reserve at the facility ≤ 3 days at present run rate × no scheduled refill in the next 5 days. Fires whenever the rolling check trips. The response refuels ahead of stock-out. Tied to diesel-litres and service-hours-at-risk.

AQ-1 — Indoor air quality alert (severity: low)

Indoor PM2.5 exceeds 75 µg/m³ for more than 6 hours, where the facility is a school or paediatric clinic. Fires immediately on threshold breach. The response is operator notification with a recommendation to ventilate, escalate to maintenance if the trend persists. Tied to the classroom-hours-lost and service-hours-at-risk ledger metrics.

5. The audit log

Every evaluation, fired or not, leaves a row in the audit log. The shape is:

{
  "evaluated_at": "2026-05-21T08:14:23Z",
  "rule_id": "CHILL-1",
  "facility_id": "lag-h-001",
  "fired": true,
  "predicate_results": [
    { "var": "facility.services", "op": "contains", "value": "cold_chain_active", "actual": "[cold_chain_active, neonatal_care]", "result": true },
    { "var": "forecast.heatwave_days_next_72h", "op": "gte", "value": 1, "actual": 2, "result": true },
    { "var": "facility.battery_soc_pct", "op": "lt", "value": 60, "actual": 54, "result": true }
  ],
  "response_proposed": {
    "type": "dispatch_diesel_and_inspect",
    "budget_usd": 1200,
    "lead_time_hours": 48
  },
  "engine_version": "v0.1.0"
}

Three properties of the audit log are non-negotiable:

1. Immutable. Rows are append-only. Corrections are new rows, never edits.
2. Reproducible. Given the same inputs and engine version, every audit row is reproducible. This is what lets external auditors verify the engine did what the methodology says it did.
3. Cited. Every rule carries a citation field linking back to the public evidence base (FAO 2021, peer-reviewed paper, government circular, etc.). Audit rows inherit it.

In the demo, the audit log lives in memory. In the grant phase it lands in Postgres with a content-addressed hash per row.

6. Approval workflow

The trigger console at /triggers shows every fired event in three states:

1. Pending. The rule fired; the named approver has not yet confirmed.
2. Approved. Approver confirmed within the lead_time_hours window; the pre-authorised budget is committed.
3. Lapsed. The window closed without approval; the event is logged but no money moves.

The demo uses a mock $50,000 response pool and lets any visitor click "Approve" to walk through the flow. In production, approver identities are tied to ministry email accounts, MFA-protected, and the action is logged with the approver's pseudonymised identifier.

7. What v0 does not do

To stay honest about limits, the demo engine does not yet do the following. Each is a grant-phase deliverable.

• Live forecast feeds. The demo evaluates against data/synthetic-forecasts.json. The grant build wires ECMWF (or partner NMHS) feeds via the relevant data licence.
• Counter-factual evaluation. We do not yet measure "what would have happened without the trigger" except by manual case study. Counter-factual evaluation requires a comparison cohort and a longer observation window.
• Multi-rule deduplication. If CHILL-1 and FUEL-1 both fire on the same facility on the same day, the engine emits two events. Operationally, the approver consolidates. Engine-level deduplication is a v0.2 task.

8. References

• FAO, 2021. Anticipatory Action in Protracted Crises. Rome.
• Anticipation Hub. Glossary of anticipatory action. anticipation-hub.org/glossary.
• START Network, 2022. Anticipatory action: lessons from the 2020 Bangladesh flood pilot.
• WHO, 2020. Effective Vaccine Management Initiative — global cold-chain assessment.
• IFRC, 2023. Forecast-based Financing operations manual.

All references are open-access. Direct URLs are kept in docs/references/triggers.bib for citation-management tools.

Priority Deployment Ranker — Methodology

Version: v0.1.0 (matches lib/ranker.ts) Status: Draft — peer review in grant phase Licence: CC-BY 4.0

The Ranker answers a deceptively simple question: given the dataset and the intervention library, where does each next dollar protect the most children?

It is the dual of the Simulator. The Simulator takes a fixed budget and a strategy and reports an answer. The Ranker takes no budget and reports a league table that the donor, ministry, or grant manager uses to set the budget in the first place.

This document describes the priority score, the applicability checks, the "best per facility" mode, the scope filters, the cumulative-cost ladder, and a worked example.

1. The priority score

For every facility in scope, for every applicable intervention, the Ranker computes:

priority_score = (fri_reduction × children_served_estimated) / cost_usd

Where:

• fri_reduction = fri_before − fri_after, computed by the same FRI engine that drives the public map and the Simulator.
• children_served_estimated is the facility's self-reported monthly child throughput.
• cost_usd is the per-facility cost of the intervention, taken from the cost band in data/interventions.json interpolated by facility size.

Higher score means more child-impact per dollar. The Ranker sorts the result descending by score and reports the top N facilities.

The score is a ratio of three honest quantities; it is not a black-box number. Anyone can read the four columns in the output table, do the arithmetic by hand, and reproduce the ordering.

2. "Best per facility" vs. forced intervention

The Ranker has two modes:

Mode A — Best per facility (default)

For each facility, the Ranker tries every intervention that is applicable, scores it, and keeps the best one for that facility. The output table shows the single best intervention per row.

Use this mode when the question is "across all my facilities, which dollars matter most?" The Ranker chooses the right tool per facility on the donor's behalf.

Mode B — Forced intervention

The donor pins a single intervention (e.g. cold_chain_retrofit) and asks "across all my facilities, where would a cold-chain retrofit dollar do the most good?" The Ranker only scores that intervention per facility and ranks the resulting set.

Use this mode when the donor's mandate restricts what they can fund (e.g. a vaccine-specific grant). Facilities for which the intervention is not applicable are silently dropped.

3. Applicability checks

A facility-intervention pair is applicable if the intervention's preconditions are met by the facility's static metadata. The library encodes these per-intervention. In v0:

If no intervention is applicable, the facility is excluded from the output. If an intervention is applicable but the projected FRI reduction is ≤ 0 (because the facility is already low-risk), the candidate is dropped. The Ranker is conservative — it would rather omit a row than carry a misleading one.

4. Scope filters

Three scope filters are exposed via the API and the UI:

• admin_1 — restrict to one state (Lagos, Kano, Cross River in the demo)
• sector — restrict to health, education, or WASH
• facility_type — restrict to a specific facility type, e.g. primary_school or community_borehole

Filters compose. A donor can ask "rank only Kano primary healthcare centres with cold chain" and the Ranker honours all three predicates. The applied filters are echoed in the notes array of the response so the audit trail is preserved.

5. The cumulative-cost ladder

The output is sorted by priority score, but the donor also sees a cumulative-cost column on every row. This turns the league table into a budget-planning instrument.

Rank 1  ...   $34,800   (cumulative $34,800)
Rank 2  ...    $6,200   (cumulative $41,000)
Rank 3  ...    $3,400   (cumulative $44,400)
Rank 4  ...    $4,900   (cumulative $49,300)
Rank 5  ...   $12,100   (cumulative $61,400)
...

A donor with a $50,000 envelope can read straight down the cumulative column and see exactly where their budget stops. Anything above that line is funded; anything below is the unfunded gap.

This is the same number the Simulator would produce if asked to run the same scope with strategy balanced. The two tools are deliberately consistent.

6. Worked example

Inputs:

intervention = best          (best per facility)
scope        = admin_1 = "Lagos"
top_n        = 5

Output (abridged for legibility):

A reader will notice that rank 1 has the largest absolute FRI reduction (40.2 points) and the most children served, but rank 3 has the highest per-dollar score. The Ranker sorts by per-dollar, not by absolute reduction, because the donor's question is per-dollar. Both columns are visible so the reader can override the ordering by hand if they want to weight differently.

7. Relationship to the Simulator

The Ranker and Simulator share the same FRI engine, the same intervention library, the same cost function, and the same ledger. The only difference is the question they answer.

• Ranker. "No budget — sort everything by per-dollar impact and let me read off the table."
• Simulator. "Fixed budget — sort by my strategy and tell me what I can afford."

For most donor conversations, the Ranker comes first ("show me the league table"), the Simulator second ("now lock the budget and tell me the cumulative impact"). The two views always agree on the underlying numbers because they share the engine.

8. What v0 does not do

• Risk-adjusted scoring. The current score weighs only FRI reduction, children, and cost. A grant-phase v0.2 will fold in execution-risk per facility (consent status, security, operator capacity) as a discount factor.
• Equity overlays. The score does not yet penalise concentration. A donor who funds only the top 5 by score could inadvertently leave one administrative district uncovered. The grant build adds an optional Gini-style equity adjustment that diversifies the picks at a small per-dollar cost.
• Time discounting. Year-1 child-impact and year-5 child-impact are treated identically. A donor with a clear time preference can apply their own discount factor; the engine surfaces the underlying number rather than baking in an opinionated rate.

9. References

• World Bank, 2020. Cost-effectiveness in low-resource health systems.
• Center for Global Development, 2021. How donors should rank investment opportunities.
• Gavi, 2022. Vaccine cold-chain equipment optimisation platform — technical guidance.
• UNICEF, 2023. Climate Landscape Analysis for Children — Nigeria.

Direct URLs and DOIs are kept in docs/references/ranker.bib.

Data Protection Impact Assessment

Project: OpenResilience Power Data controller: Tribe Energy Resources Limited (Nigeria), wholly owned by Tribes Capital Limited (United Kingdom) Version: v0.1.0 Status: Draft for UNICEF Venture Fund review — updated after community consent fieldwork in the grant phase Authoring date: 21 May 2026 Next review: End of grant-phase month 3, then annually Licence: CC-BY 4.0

This document is the Data Protection Impact Assessment for the OpenResilience Power platform. It follows the structure recommended by the UK Information Commissioner's Office (ICO 2022), the European Data Protection Board (EDPB 2017 guidelines on DPIAs), and the UNICEF Manifesto on Good Data Practices for Children (UNICEF 2018), with field-level tailoring for Nigeria (NDPR 2019, NDPA 2023) and Uganda (DPPA 2019).

1. Purpose and scope

OpenResilience Power is an open-source platform that publishes the resilience profile of child-critical hospitals, clinics, schools, and water points, simulates the projected child-impact of investment decisions, and triggers pre-authorised anticipatory response. It is operated as a public good; the base layer is permanently free.

This DPIA covers:

• The demo deployment on Vercel (this site) and the open repository on GitHub.
• The reference sensor firmware listed in firmware/esp32-resilience-sensor/.
• The Field Assessment PWA at /assess and the assessment ingest endpoint.
• Every public API endpoint documented in /api/openapi.json.

It does not cover:

• Third-party tools an operator might choose to integrate (e.g. their own facility management system). Operators are responsible for their own DPIA on those.
• Future product surfaces not yet built (e.g. patient-facing apps). Those will receive their own DPIA before launch.

2. Necessity and proportionality

Why does the platform need data at all? Because protecting child-critical services in Nigeria and Uganda from foreseeable power and climate failures requires three signals that cannot be guessed: which facilities exist and what they serve, what their resilience condition is right now, and what the weather and grid are about to do to them. Without those signals the platform cannot do its job.

What is the minimum dataset? The platform was designed from the outset to operate on facility-level data and never on patient-level or child-level identifying data. Patient names, clinical records, attendance registers, exam results, and any other personally identifiable record are explicitly out of scope. The platform's value comes from the operational resilience layer, which sits one level above any clinical or educational record system.

Proportionality test. We considered whether the same outcomes could be achieved with less data and concluded no. A facility map without facility coordinates is not navigable; a Simulator without facility size estimates cannot project child-impact; a trigger engine without weather forecasts cannot anticipate failure. We did, however, eliminate three categories of data that an earlier draft included: real facility names (replaced with pseudonymised IDs in the public surface), individual operator names (replaced with role labels), and any historical service-level data older than 36 months (rolling window).

3. Data flows

3.1 Facility registry

Real facility names and contact details are stored in a private backend table that is not exposed on any public endpoint and is not pushed to the GitHub repository. The mapping between pseudonymous ID and real name lives behind ministry-level access controls in the grant phase. During the demo there are no real names at all — every facility on the public map is a pseudonymous demonstration entity.

3.2 Sensor telemetry

The sensor reads electrical and environmental signals only. It does not read people, footfall, audio, video, network traffic, or anything else that could identify a person.

Raw per-minute samples are retained for 90 days, then automatically rolled up to hourly summaries and the raw rows are deleted. The rollups are retained for 36 months, then deleted.

3.3 Field assessments

The Field Assessment PWA collects facility-level operational data (battery condition, generator hours, water pump status, etc.) plus optional GPS, photo, and signature. The assessment payload is keyed to a pseudonymous assessment ID and a pseudonymous device ID. Photos are taken of equipment (not people); the form makes this explicit.

Photos are stored encrypted at rest. Any photo that inadvertently captures a person's face is reviewed and re-shot during the data-quality pass. Assessors are trained on this at onboarding.

3.4 Public API consumers

The platform exposes only aggregated and facility-level data. There is no API surface that returns individual records. Rate-limiting at the edge prevents bulk scraping that could enable adversarial re-identification.

4. Identified risks and mitigations

5. Special protections for children

OpenResilience Power explicitly does not handle individual children's data. The platform was designed around this principle from day one, and every component, including the field forms and the sensor, was specified to avoid touching it.

Where the platform reports child-impact metrics (e.g. "1,800 children served", "2,400 vaccine doses at risk"), these are estimates derived from operator self-reports of facility throughput, not from individual records. They are presented at facility-month aggregation, never per-child.

In line with the UNICEF Manifesto on Good Data Practices for Children:

• We act in the best interests of children by surfacing the resilience risks they live with and the investments that protect them.
• We are transparent and accountable — every metric is documented, every formula is open, every data flow is in this DPIA.
• We proportionately collect — facility-level data only, never personal.
• We safeguard the data we hold via the controls listed in section 6.
• We engage with operators and ministry partners on every data category before we collect it.

6. Technical and organisational controls

7. Cross-border data transfers

After the UNICEF outcome, the platform migrates from Vercel to Tribes Capital's existing Fasthosts VPS 2 in the United Kingdom (see OPENRESILIENCE_POWER_BUILD_PLAN.md section 10.1). That removes the United States from the transit path entirely and reduces the cross-border risk surface to UK–Nigeria, UK–France, and UK–Uganda. SCCs cover each leg.

8. Consultation

The consultations are not pro-forma. The platform's data categories will be re-examined after each consultation and the DPIA updated accordingly. The version history of this document is in the git log.

9. Decision and approval

The data controller has determined that, with the controls listed above implemented and maintained, the residual risk of harm to data subjects is low. The platform is approved for the demo deployment described in section 1, subject to:

1. Annual DPIA review by the data controller.
2. Quarterly review of identified risks during the grant phase.
3. Immediate review on the introduction of any new data category, new processor, or new geography.
4. Public publication of every material change to this document on the project website with a dated changelog.

Approved by:

• Daniel Akinrele, founder, Tribes Capital Limited (data controller)
• Pending — UNICEF Venture Fund grant-phase reviewer
• Pending — independent DPIA reviewer (grant-phase month 3)
• Pending — ministry data-protection focal points (Lagos State, Kano State)

10. Contact

Data protection enquiries, subject access requests, and incident notifications:

Tribe Energy Resources Limited Attn: Data Protection Officer [contact email forthcoming — placeholder during demo phase]

A named DPO is appointed at the start of the grant phase. During the demo, the data controller acts as DPO for the platform.

11. References

• Information Commissioner's Office (UK), 2022. Data protection impact assessments — guidance.
• European Data Protection Board, 2017. Guidelines on Data Protection Impact Assessment (WP248 rev.01).
• UNICEF, 2018. Manifesto on Good Data Practices for Children.
• UNICEF, 2020. Policy guidance on AI for children.
• Federal Republic of Nigeria, 2019. Nigeria Data Protection Regulation.
• Federal Republic of Nigeria, 2023. Nigeria Data Protection Act.
• Republic of Uganda, 2019. Data Protection and Privacy Act.
• World Health Organization, 2021. Ethics and governance of artificial intelligence for health.