1. Interpret — In this stage, the AI reasons over multiple satellite-derived Earth-observation signals together with forecast data: observed rainfall (CHIRPS), vegetation condition (NDVI), ICPAC's Combined Drought Indicator, forecast river discharge (GloFAS, riverine woredas only), and the 14-day rainfall/temperature forecast (Open-Meteo). It produces two independent structured hazard assessments per woreda, every run — one for drought, one for flood — each with a severity level (low, watch, warning, emergency), a confidence rating, explicit written reasoning, and a list of exactly which data sources actually informed it. Flood assessments carry a hard constraint: return-period thresholds for GloFAS's river discharge forecast haven't been computed yet, so a flood assessment's confidence is never allowed to be anything but low, and its reasoning must say so explicitly. The ICPAC drought indicator and NDVI are never used for flood.

2. Anticipate — The hazard assessment from stage one is reasoned over a pre-built table of 15 climate-to-health impact rules, drawn from sources like WHO guidance and Ethiopia's national malnutrition treatment protocol. Each rule encodes a relationship — e.g. "flood at warning level" links to "cholera outbreak risk" within a stated time window (e.g. "1 to 4 weeks"). The AI treats these rules as hard constraints: every anticipated health risk it produces must cite at least one matching rule, and its timing must fall inside that rule's stated range. Output that doesn't meet this bar is rejected outright, not softened or approximated.

3. Advise — The AI advisor (a retrieval-grounded chat assistant) answers protocol questions from health workers, disaster-management officers, or community members. It answers only from ingested source documents (WHO guidelines, Sphere standards, etc.), with an explicit citation naming the document and section for every claim. If there isn't a good enough match in the source material, it says so plainly — "not in my sources" — instead of generating a plausible-sounding but ungrounded answer.

4. Advise (Generate) — Once a region has a confirmed health situation, the AI can draft advisory text — a WhatsApp message, a radio script, or a formal memo — in both Somali and English. The AI writes only the narrative wording; it has no mechanism to produce a new risk level in this stage. Every advisory is a draft until a health officer or admin reviews and approves it.

Degdeg uses four hazard levels — low, watch, warning, emergency — where WHO's operational alerting guidance typically frames risk in three tiers: green, yellow, red. This isn't a departure from WHO practice; it's WHO-compatible, with one additional operational distinction folded into the red tier.

Green maps to low (routine surveillance — no change to standard practice). Yellow maps to watch (enhanced monitoring and preparedness: check supply levels, brief field staff, track trends closely — without yet triggering a response). Red maps to warning and emergency together (initiate predefined response actions).

Inside red, we keep warning and emergency distinct because anticipatory action depends on lead time as much as severity. A warning-level assessment gives responders a window to pre-position supplies and staff before an outbreak or shortage materializes; an emergency-level assessment means impact is imminent or already underway, and needs escalated, EOC-level (Emergency Operations Center) coordination rather than routine follow-up. Collapsing the two into a single red tier would erase exactly the distinction that makes early action possible.

Grounding, not freestyling: Stages 2 and 4 cannot output an unsupported claim. Anything not traceable to a vetted rule or confirmed data is rejected automatically, before a human ever sees it.

Structured validation: Every AI response is checked against a strict technical schema. Malformed or non-compliant output is retried once; if it still fails, it's routed to a review queue that admins can browse in the admin panel, rather than silently discarded or force-accepted.

Confidence + human-in-the-loop: A routine assessment (low or watch severity) publishes automatically, regardless of confidence — confidence describes how sure the AI is, not how urgent the finding is, and an honestly-low-confidence routine reading doesn't need a human gatekeeper. Only an elevated assessment (warning or emergency severity) paired with low confidence is held back from public display, because that's the one combination where a wrong call in either direction — a false alarm or a missed warning — actually matters. An administrator or health officer then explicitly confirms (publishes it) or rejects (keeps it hidden) the assessment in the admin panel; either decision, and who made it, is permanently recorded. Every advisory, regardless of confidence, stays a draft until a human approves it.

Full audit logging: Every AI call — the prompt it was given, the exact response, and the validation outcome — is written to an immutable log. That log is, in effect, the methodology annex: it's how a reviewer can verify the claims on this page against what the system actually did. This isn't just a design principle — the log itself is browsable in the admin panel (Admin role only, since prompts can contain internal detail), filterable by stage, woreda, and validation outcome.

The system defines four roles: Admin (full access), Health Officer (can approve advisories for their assigned region), Disaster Risk Management (DRM) Officer, and Viewer (read-only).

An elevated hazard assessment (warning or emergency severity) paired with low AI confidence is withheld from public display until an admin or health officer explicitly confirms or rejects it — a routine low/watch assessment publishes automatically regardless of confidence. AI-drafted advisories stay in draft status until a Health Officer (for their own region) or Admin (any region) approves them — both the approval timestamp and the approver are recorded.

Beyond advisories (drafted communication content), Degdeg tracks alerts — notification events with their own lifecycle, separate from any advisory text. An alert is created deliberately by an admin or health officer from a specific, already-confirmed health risk; it is never generated automatically by the nightly forecast pipeline, the same caution that governs advisory drafts.

Every alert's history — created, acknowledged, action taken, outcome recorded — is kept as an append-only event log, not a status field that could silently drift from what actually happened. Each event records who did it and when, plus a comment or which recommended action was performed, where relevant.

Honesty about what's real today: Degdeg has no SMS, email, or WhatsApp delivery integration yet. An alert is visible to authorized staff on the /alerts dashboard from the moment it's created; nothing is ever marked 'sent' or 'received' unless a real dispatch happens or a human explicitly records that it did. Building an actual delivery channel is planned, tracked, future work — not something this page pretends already exists.

Every week, Degdeg produces a regional bulletin summarizing the whole hazard picture, the highest-risk woredas, changes since the previous week, anticipated health risks (each citing a vetted rule), recommended preparedness actions, and an explicit statement of uncertainty and data vintage per source. Like advisories, it's written in both Somali and English and stays a draft until a health officer approves it.

The 'changes since last week' section is computed from stored history (hazard_states, which is append-only) — comparing today's confirmed level for each woreda against whatever was the latest confirmed level at the start of the reporting period. It is never asked of the model to recall.

An honest comparison depends on the two ends of that comparison being grounded in the same evidence. If a methodology or data-source change (e.g. a new Earth-observation source going live, or ICPAC's CDI migrating from single-point to zonal-mean sampling) falls inside a given week's comparison window, the system detects this automatically (a dated registry, lib/ai/grounding-method-changes.ts) and the bulletin is required to state plainly that part of the apparent change may reflect newly available evidence rather than real conditions — rather than presenting a methodology artifact as a clean weather-driven trend.

Every Earth-observation source (CHIRPS, ICPAC, NDVI, GloFAS) runs as a scheduled job (Python + GitHub Actions, not Vercel — raster download and true polygon zonal statistics don't fit Vercel's function time limit), and every run is logged, successful or not, so staleness is always visible rather than silently assumed. Every source computes a true zonal mean over each woreda's full boundary polygon, never a single center-point sample.

Manually-entered data: other bulletins from ICPAC, FEWS NET, and regional disaster-management offices, distinct from the automated sources above, are occasionally entered by hand through the admin panel.

Protocol documents: WHO guidelines, Sphere standards, and national health protocols are ingested as PDFs, chunked, and indexed so the AI advisor can retrieve and cite them.

Plausibility checks: GloFAS is currently the only source with an explicit plausibility check — every reading is compared against that reach's own long-term average discharge, and an implausible value (too low or too high to be a real river reading) is flagged, stored for audit, and excluded from what reaches the AI's grounding — treated identically to no reading at all, never silently passed through. The other sources don't yet have an equivalent bespoke check; their confidence is ordinary read-the-data confidence, not a claim that every value has been sanity-checked.

Important: ICPAC's drought indicator, CHIRPS, and NDVI feed the drought assessment only, additive to (never replacing) Open-Meteo. GloFAS feeds the flood assessment only, for riverine woredas only; return-period thresholds haven't been computed yet, so flood confidence never rises above low.

In the interest of being straightforward: soil moisture and land surface temperature are identified candidate sources but not yet integrated into the data used.

GloFAS return-period thresholds (2/5/20-year) haven't been computed yet — the historical reanalysis download they'd be fitted from is deliberately paused (not abandoned), and is scoped as a future-phase, better-resourced workstream, not a blocker to the current seed study.

Observed flood extent (e.g. Copernicus Global Flood Monitoring) hasn't been ingested — it was evaluated and deliberately deferred, since it belongs more naturally with future forecast-verification work than the current early-warning pipeline.

Vulnerability/exposure weighting hasn't been built — anticipated risk is currently hazard-driven only.

Authentication was only recently wired up. Role assignment (who becomes a Health Officer or Admin, and for which region) is currently done directly against the database rather than through a self-service admin UI — that's the next piece of access-control work.

Forecast history (past hazard-level assessments) is preserved and never overwritten. A store for what actually happened on the ground — case counts, admissions, deaths, or a confirmed outbreak/IPC threshold — now exists too, so a forecast can eventually be checked against reality. That store is empty today, and that's expected, not a problem: no outcome data is ever backfilled or invented, only entered from a named real source. We will not publish an accuracy percentage or any other performance metric until enough real outcome data has accumulated to calculate one honestly.