A single, searchable home for the OCHA Centre for Humanitarian Data — Data Science team's institutional knowledge: how we build anticipatory-action frameworks, the triggers and monitoring behind them, the pipelines and apps that run them, and the infrastructure it all sits on.
Built to be read by humans (browse the markdown) and by Claude — point Claude at a clone, or connect to the team's hosted MCP connector and query the KB from Claude with no clone at all. The same files serve both.
Note for visitors: this repo doubles as a Claude Code plugin marketplace for our team (
ds-team, see claude/). If you open it in Claude Code you may get a trust prompt offering plugins whose session-start hook clones this KB onto your machine (only to a directory you explicitly choose). That's intentional — it's how the team self-installs — and entirely declinable; nothing runs or is written without the prompt being accepted.
Our knowledge is scattered across three forms — documents (mostly PDFs), code (dozens of ocha-dap repos), and infrastructure (Azure, Databricks, a database) — and it lives in people's heads. This repo gathers it into one place where any of it can be found by searching, so that:
- a teammate (or Claude) can answer "how did the Niger drought trigger work, and why those thresholds?" without spelunking through a repo;
- the routine 80% of producing a framework or debugging a pipeline can be accelerated;
- we can eventually publish the parts that should be public (frameworks, triggers, monitoring).
It is not a chatbot or a trained model. It's a structured markdown corpus; "the agent" is just Claude reading these files.
Hub-and-spoke. This repo is the hub — summaries, cross-links, and the cross-framework comparison no single repo can hold. The individual ocha-dap repos are the spokes, holding the deep, code-adjacent detail. One home per fact: pages here link to the canonical code/PDF via source_repo/code_ref rather than copying it.
Eight content types:
| Folder | What's in it |
|---|---|
frameworks/ |
OCHA/CERF AA frameworks & their versions — design, trigger logic, rationale (one page per version) |
external-frameworks/ |
Other orgs' AA frameworks (IFRC, WFP, FAO, START…) — cross-org view in catalog-global.md |
pipelines/ |
Living operational systems — data ingests, monitoring, alerts (runbooks) |
apps/ |
Deployed interactive surfaces (marimo / Dash / Quarto) on Azure / GH Pages |
analysis/ |
Analysis repos that aren't frameworks or pipelines — regional overviews, ad-hoc activations, pre-framework exploration |
methods/ |
Cross-cutting "how we do it" — e.g. the trigger typology |
infrastructure/ |
Conventions + registries: storage, database, deployments, the pipeline registry, shared libraries, the MCP connector |
assets/ |
What data we actually hold in blob per project — coverage / gap reports (Phase 8, piloting) |
A key design choice: the latest published framework PDF is authoritative for the trigger, and ingestion reconciles it against the repo (which can drift) — recording discrepancies rather than trusting either alone.
- Install the
ds-teamplugins (team members — the recommended route). This repo doubles as a Claude Code plugin marketplace:claude plugin marketplace add OCHA-DAP/ds-knowledge-base, installkb-access@ds-team, and say "finish my KB setup" — the plugins keep a local clone synced and load the team's skills (KB search, data access, AA methods, infra ops) into every session. Full guide: docs/USING.md. - Hosted MCP connector (no clone). The KB is exposed as a remote MCP server; add it as a custom connector in claude.ai or Claude Code and query the KB from Claude directly — search, read, and Claude-Code-style code navigation across the frameworks/pipelines/infra pages and the generator code. Setup + URL: infrastructure/mcp-connectors.md. A second, token-gated internal tier is also live — read-only DB/blob plus the internal Drive extracts — reached today via the KB chatbot's
/privatepage (the claude.ai-connector path for it is still OAuth/Entra-blocked). - The KB chatbot (no setup at all). A password-gated web chatbot answers KB questions in the browser; its
/privatepage adds live DB/blob and the internal Drive layer. See infrastructure/mcp-connectors.md. - Point Claude Code at a clone. Clone the repo and run Claude in it — same files, full grep/read over everything.
The corpus is substantially built. The DS-built framework corpus is complete (see catalog.md) and the scope has widened to the full OCHA/CERF AA portfolio (historical pilots are still being drafted from public sources; aa-watch surfaces what's missing). The systems back-catalogue is ingested (pipelines, apps, shared libraries) alongside pre-framework / regional analysis/, plus the cross-org external-frameworks/ layer, and the cross-cutting layers are in place: the dependency graph + blast radius, the trigger typology, and a generated pipeline registry with live health. Self-maintenance runs on four axes — deterministic generators that auto-commit, drift/PDF-freshness detection, discovery, and usage telemetry — feeding the detect→Claude-draft→PR loop (automation.md); public framework-PDF full-text is persisted in raw/ for grepping. The consumption layer is live: the ds-team plugin marketplace (above), both MCP tiers, the KB chatbot, and the public AA site (EN/FR). Google Drive ingestion is largely done (manifest + ~3,560 text extracts in the private companion repo, daily sync — see PRIVACY.md); Phase 8 (blob data inventory under assets/) is under way.
For the authoritative live status see docs/ROADMAP.md.
| To understand… | Read |
|---|---|
| How to use the KB day to day — plugins, MCP, chatbot | docs/USING.md |
| Why it's built this way — the rationale + full decision log | docs/DESIGN.md |
| What's next — phases and current status | docs/ROADMAP.md |
| How to add or restructure a page — conventions & schema | INGESTION.md |
| How Claude should use this repo | CLAUDE.md |
| How to connect Claude to the KB (MCP connector + tiers) | infrastructure/mcp-connectors.md |
| How the KB maintains itself — the four automation axes | infrastructure/automation.md |
| What's public vs internal, and why | docs/PRIVACY.md |
| How the public sites do EN/FR | docs/I18N.md |
| The ds-team plugin payload — contributor rules | claude/README.md |
| What's in scope to ingest, and progress | docs/repo-manifest.md |
The pages are machine-ingested and reviewed but not infallible — flagging mistakes is how the KB earns trust.
- Just open an issue (the KB error or feedback form) describing what you want changed or added. The KB steward (headless Claude) reads the issue and its comments and drafts the change as a review PR — or, if it needs a source/decision it doesn't have, comments asking you. For an error, point to the authoritative source; for a decision, just comment the answer on the issue and the next run applies it. You review the PR; nothing auto-merges.
- No label needed — any issue a team member (repo write/admin) opens is picked up automatically. Add a
discuss(orno-autofix) label if you just want to talk it through without a draft. - From outside the team? Your feedback is welcome and read by a maintainer first — for safety the steward doesn't auto-act on issues from non-members; a maintainer triages it (replies or tags
kb-autofix) and then it's drafted the same way.
- No label needed — any issue a team member (repo write/admin) opens is picked up automatically. Add a
- Prefer to do it yourself? Edit the page and open a PR (each page links its sources —
code_ref, the framework PDF — so corrections can be checked). - Automated checks also file issues the steward resolves —
kb-validity(a framework past its validity period),kb-docs(the how-it-works docs drifted),kb-new-repos/kb-coverage/kb-aa-watch(new things to bring in). (Deterministic re-syncs like a moved source or a newer PDF go straight to akb-ingestPR instead.) See infrastructure/automation.md for the full self-maintenance map.
Much of this repo is assembled and maintained with Claude working over the team's repos and the published framework documents — that workflow is itself part of what's being built here.