[ricardomiron]

DPGs for AI criteria — community input

Collections are curated sets of Digital Public Goods (DPGs) grouped by strategic priority — such as Climate, DPGs for DPI, or DPGs for AI — to accelerate impact in specific sectors.

Each collection applies a small set of supplementary criteria on top of the DPG Standard. The Standard remains the prerequisite; a collection's criteria add only the additional, domain-specific expectations a DPG must meet to be featured in that collection.

---

This PR publishes the first public, version-controlled draft of the technical criteria for the DPGs for AI Collection, and opens a thread for the community to weigh in.

The DPGs for AI Collection highlights Digital Public Goods that enable the ethical and responsible development of AI in support of the SDGs, with particular attention to low-resource contexts and underrepresented domains. The criteria are a supplementary lens over the DPG Standard: the Standard remains the prerequisite, and these criteria add only the additional, AI-specific expectations.

How the criteria work

• Layer 1 — DPG Standard: the solution is a recognized DPG in the DPG Registry.
• Layer 2 — AI relevance: a single relevance gate (category fit, AI-lifecycle utility, documented relevance/impact).
• Layer 3 — Technical criteria: category-specific mandatory criteria for open source software (S1–S3), open data (D1–D3), and open AI systems (A1–A3), with recommended best practices.

Inclusion is a binary gate on mandatory criteria only; recommended items are surfaced as best practices, not a score. Mandatory criteria are documentation requirements (no engineering or measurement overhead), so they're achievable by Global Majority maintainers and assessable by DPGA reviewers against public documentation.

Co-stewards & partners

This criterion was developed by the Digital Public Goods Alliance (DPGA) Secretariat, the Open Data Institute (ODI), the United Nations International Computing Centre (UNICC), and Digital Futures Lab; and the valuable input from UNESCO, Wikimedia, OpenFuture, and Mozilla.

What we're looking for (please comment)

• Is anything in the mandatory tier too demanding, or anything recommended that should be mandatory?
• Are the evidence expectations (datasheets, model cards, Croissant/Croissant-RAI, benchmark reports) realistic and assessable from public docs?
• Are the Layer 2 category boundaries (software / data / AI systems) drawn in the right place?
• Gaps, especially for low-resource and non-English contexts.
• Any overlap that duplicates rather than complements the DPG Standard or Maturity Model.

Status: Final draft — any changes will be recorded in the collection changelog.

The criteria live in collections/dpgs-for-ai/, alongside a short overview README and a changelog, so the collection can be maintained and versioned independently.

---

Comment period: from June 15 to June 30, 2026

[kelkalot]

-For a collection whose stated focus is sovereignty and low-resource contexts, "no mandatory telemetry / phone-home" sits oddly in the recommended tier, since privacy/no-lock-in is already near-core to the DPG Standard. Consider promoting a lightweight version to mandatory (it's a documentation check, not engineering).
-Datasheets / model cards / Croissant / Croissant-RAI / benchmark reports are reasonable and assessable for data and AI-system entries. I would make that artifact-type -> criteria mapping explicit in the framework itself so different reviewers apply the same N/A logic consistently rather than per-judgment.
-The software/data/AI-system split is drawn in a sensible place, but tools that bundle datasets fall between stools: There is currently no lightweight provenance/PII/consent disclosure expected of a software entry that includes data. Suggest adding a small "bundled-data provenance" item that triggers when a software DPG ships datasets, which closes a real gap without burdening pure-code tools.
-The "non-Latin script or low-resource language support" item is valuable but lives in recommended. Given the collection's explicit low-resource emphasis, consider a mandatory-but-cheap "documents language coverage and known limitations" item. It's a documentation requirement, not a measurement one, so it stays achievable.
-S3 (Responsible Practices: limitations/biases/failure-mode documentation) conceptually overlaps with responsible-AI dimensions in the Maturity Model. Worth a sentence in the README clarifying the boundary so maintainers don't document the same thing twice in two places.
-the L5 rung should recognize local-first plug-and-play as an L5-equivalent path, not only managed/hosted services, otherwise the ladder structurally under-credits sovereignty-respecting tools, which contradicts the collection's own low-resource/on-prem priorities.

[tjcareywilson]

Thanks for consolidating this into a clear draft. The layered Standard / relevance-gate / category model reads well, and the open-data criteria are much more concrete than the earlier version. Comments below answer the open questions. The metadata-standard and synthetic-data points are the two we'd press on, the rest are refinements.

• Croissant should be the default for D2, not one option among equivalents. CSVW and schema.org/Dataset don't carry the same machine-readable, ML-aware semantics, so listing them as fallbacks risks treating them as substitutes when they aren't. Name Croissant as the default, and if a non-AI-native fallback is retained use DCAT rather than schema.org/Dataset. For the same reason, D3 should name Croissant-RAI explicitly as the machine-readable vehicle for the responsible-practices disclosure rather than leaving it implicit.

• Promote demarcation of synthetic data / machine annotation from recommended to mandatory for data. Whether a dataset is real, synthetic or machine-annotated is fundamental to judging whether it's safe to train on, and undisclosed synthetic content carries model-collapse and provenance risks a downstream user can't detect after the fact. It's a single documented statement with no measurement overhead, so it stays within the achievability bar for a mandatory item.

• Make D3's minimum-disclosure requirement explicit in the criterion itself, not just the explanatory note. State that it means a genuine narrative of coverage, gaps and collection context. It would also help to add a short reviewer note on when each vehicle applies (Datasheets for general datasets, Data Statements for natural-language datasets, Croissant-RAI as the machine-readable option), with any one of the three satisfying the requirement.

• Unbundle the multi-part mandatory criteria in the evidence column. D1 and A1 each combine several sub-elements (D1 is technical specs plus versioned changelog plus programmatic access). Listing each sub-element in the evidence column so a reviewer confirms them one by one makes pass/fail decisions easier to evidence. This is presentation only and doesn't change what's required.

• Use the D3 coverage-and-gaps narrative to surface language coverage. Where a dataset has a language dimension, that existing narrative could note which languages, scripts or dialects are present and which are absent or under-represented. This sits inside the criterion as written, so it adds no measurement overhead and stays assessable from public docs, and it fits the collection's low-resource emphasis without a separate language requirement.

• Lower the metadata barrier for Global Majority maintainers with two templates: a Croissant starter kit for the collection, and a Datasheet template pre-populated with the DPG Standard fields. The main barrier is producing Croissant metadata and structured bias documentation without data-engineering capacity.

• Make the 'Beyond DPG Standard/Maturity' headings accurate. All three category notes carry that heading, but only the software note actually addresses the Maturity Model, while the data and AI notes explain the criteria against the Standard's indicators only. A short addition to the data and AI notes stating what they add beyond the Maturity Model's documentation, interoperability and adoption pillars would make the heading accurate and the boundary explicit.

• If the post-launch maturity tiers are published, make them visibly distinct from the Maturity Model. One grades AI-readiness within the collection, the other grades a DPG's general maturity, and two similar three-level scores side by side could confuse downstream users. The underlying logic that inclusion and quality are separate signals is right.

• Add to the resources list, to give maintainers the references behind the D2/D3 evidence expectations: Unlocking data collaboration (ODI, 2025, relevant to the copyright attestation criterion); Croissant and Croissant-RAI (MLCommons); Datasheets for Datasets (Gebru et al., 2018); Data Statements for Natural Language Processing (Bender and Friedman, 2018).

On the parts that don't need changes: the evidence expectations are realistic and verifiable from public docs without running code, and the Layer 2 software/data/AI boundaries plus the relevance gate handle the edge cases we'd expect.