About AidOps
What it provides, where it sits, and where it's going.
What AidOps provides
AidOps is an open reference model for humanitarian field data. It provides structured, machine-readable definitions for the data that humanitarian programs collect, process, and share.
- Concepts: structured profiles for field observations (nutrition screening, food security assessment, shelter damage). Each concept has a definition written for program staff, not developers.
- Properties: named, typed fields that carry the actual data:
muac,fcs_score,damage_level,current_shelter_type, and nearly a hundred others, each defined once and reused where it applies. - Vocabularies: controlled value sets for fields like food groups, coping strategies, MUAC bands, damage levels, and measurement techniques. Encoded from standard instruments (WFP FCS, FAO HDDS, WHO Growth Standards) where they exist; defined as a common set where coding varies across agencies.
AidOps builds on PublicSchema's universal concepts rather than defining its own Person, Household, or Location. This means assessment data from AidOps and enrollment data from a social protection system using PublicSchema share the same core identifiers, so linkage is straightforward.
Every element gets a stable URI. Everything is optional. Organizations adopt what they need and extend what they don't.
AidOps is in active development. Definitions for nutrition assessment, food security measurement, and shelter damage are available now.
Design principles
- Definitions carry semantic weight. Concepts are not bags of fields. Each definition describes what the data represents, not just what columns to expect.
- Properties are reusable. A property like
muacis defined once and used wherever it applies, keeping definitions consistent across profiles. - Instrument provenance is tracked by default. Every observation records what instrument collected it and when, so you always know where a score came from.
- Standard instruments are encoded, never reinvented. Where WFP, FAO, WHO, or other bodies define an instrument, we encode their definitions. We only define new value sets where no standard covers the domain.
- Nothing is mandatory. Organizations adopt what fits their operation. The schema grows through field use, not committee design.
Where AidOps sits
AidOps complements existing humanitarian data efforts rather than competing with them. It sits at the field data layer: between assessment methodology and reporting.
| Layer | What exists | What AidOps adds |
|---|---|---|
| Assessment methodology | SMART, Washington Group, WFP food security instruments | Structured data definitions for what those methodologies produce |
| Data collection | KoboToolbox, ODK, CommCare | Canonical field names and value codes to use inside forms |
| Data exchange | OCHA HDX, HXL | Semantic definitions behind the tags and column headers |
| Analysis and classification | IPC/CH, cluster dashboards, 4W matrices | Consistent field-level data that feeds directly into classification and reporting |
| Field data semantics | No cross-agency standard | This is the gap |
SMART defines how to conduct a representative anthropometric survey; AidOps defines how to structure the resulting data. WFP specifies how to calculate the Food Consumption Score; AidOps defines the fields and value codes that carry the raw inputs and the result. HXL provides column tags for data exchange; AidOps specifies what those columns mean at the field level.
Scope
AidOps starts with the data that humanitarian field programs most commonly collect: nutrition and anthropometric assessments, food security measurements, and post-disaster shelter and damage surveys. These are well-understood domains with standard instruments, active data sharing needs, and immediate interoperability pain.
New domains follow the same structure: define concepts, name properties, encode vocabularies. WASH, protection, livelihoods, and health referral data are natural next steps as adoption grows.
How organizations adopt it
AidOps is a starting point, not a mandate. Organizations adopt the parts that apply to their operation and extend the rest. The most common entry point is mapping an existing dataset to AidOps definitions to see where your data already aligns and where it diverges.
- Use standard instrument vocabularies as-is. FCS food groups, rCSI strategies, MUAC bands, and damage levels map directly to the instruments your teams already use.
- Adopt profile concepts for your assessments. FoodSecurityProfile, AnthropometricProfile, and DwellingDamageProfile give you a structured schema for the most common field data types.
- Extend what's missing. Operation-specific fields (a custom vulnerability index, a local shelter classification, an additional food group) live in your namespace alongside AidOps definitions.
- Propose upstream. When an extension turns out to be useful across operations, propose it for inclusion. The schema grows through field use, not committee design.
Data responsibility
Humanitarian field data is among the most sensitive data collected anywhere. AidOps defines data structure, not data governance. Organizations using AidOps definitions remain responsible for applying their own data protection policies, including the IASC Operational Guidance on Data Responsibility. Sensitivity annotations on properties (standard, sensitive, restricted) flag fields that typically warrant additional safeguards, but classification decisions belong to each organization's data protection framework.
License
The reference model is published under Creative Commons (CC BY 4.0). The site code is Apache 2.0.
Contribute
AidOps is developed in the open. Contributions and feedback are welcome on GitHub.