Introduction and scope
The Common Impact Data Standard (CIDS) provides a shared semantic model for impact measurement data — outcomes, indicators, reported values, organizations, and the relationships between them — so that data can move between software systems and funders as impact data capsules without forcing every organization into the same metrics or rigid schema.
Practically, an impact data capsule is a JSON-LD file: an array of linked objects with stable @id values. For background on the underlying model, see What is RDF?.
This page defines the scope of the standard and the audiences who should read each part of this Metadata Application Profile (MAP).
Who uses impact data capsules
Section titled “Who uses impact data capsules”- Portfolio users (typically funders) — import and aggregate capsules from many reporting organizations; often need import, validation, and query tooling.
- Enterprise users — export capsules from their own impact data; may not need to import their own or others’ capsules.
Both spreadsheet-first and database-first software can align. The data standard does not mandate a storage architecture — only the interchange format.
Problem and interoperability context
Section titled “Problem and interoperability context”Social purpose organizations measure impact in diverse ways: different theories of change, indicators, terminology, and file formats. Funders and portfolio managers need to aggregate and compare that data across enterprises. Without a flexible interchange standard, the sector faces a false trade-off:
- Top-down standardization — rigid metrics that limit local relevance, or
- Bottom-up flexibility — rich organizational data that cannot be combined at portfolio scale.
CIDS breaks that trade-off by standardizing meaning and graph structure while leaving organizations free to choose what they measure.
For the strategic rationale, see Common Approach’s public overview and the CIDS FAQ on RDF.
In scope
Section titled “In scope”This profile covers:
- The CIDS ontology (classes, properties, imported vocabularies) at a pinned release
- Alignment tiers — Basic, Essential, and Full — scoped by
cids:belongsToTierin the ontology and enforced in tier SHACL files (capsules usually do not carry a tier field; you choose the SHACL file at validation time) - The Social Finance Fund (SFF) companion module — additional reporting requirements on top of Basic Tier for Canada’s Social Finance Fund (skip if not participating)
- Serialization — JSON-LD with published
@contextfiles; Turtle and other RDF syntaxes for debugging and tooling - Conformance — validation of capsule graphs against published SHACL shapes for a declared tier
- Code lists — normative references to published taxonomies at
codelist.commonapproach.org - Impact data capsules — JSON-LD documents exchanged between aligned exporters and importers
Out of scope
Section titled “Out of scope”The following are not defined by this MAP, even when related products support them:
- Funder-specific business rules beyond published SHACL (e.g. “every applicant must supply field X for program Y”) — see SHACL validation vs. funder requirements
- ETL, record-level CRM data, or general-purpose databases not mapped to CIDS concepts
- Non-impact administrative data unique to a single funder or program
- Operational behavior of hosted services (Graph Cast API, Excel add-in, Airtable extension, Data Converter) — documented separately; see Graph Cast
- SPARQL endpoints on ontology.commonapproach.org — a possible future enhancement; not part of this profile today
Tiers, modules, and companion profiles
Section titled “Tiers, modules, and companion profiles”| Name | Purpose |
|---|---|
| Basic Tier | Minimum graph for interchange: Organization, Theme, Outcome, Indicator, IndicatorReport and core properties |
| Essential Tier | Adds commonly needed entities (e.g. stakeholders, addresses, organization identifiers) beyond Basic |
| Full Tier | Complete CIDS feature set in the published ontology for the release |
| SFF companion module | Reporting extensions for Social Finance Fund participants — includes Basic Tier plus SFF-specific classes and properties |
Tiers reflect data complexity, not quality rankings. Choose the tier that matches what you need to model — see Choosing a tier.
Companion modules extend CIDS in the same namespace family (cids: and sff:). They use separate SHACL files (sff.shacl.ttl) that subsume Basic Tier requirements. Software may align to CIDS only, or to CIDS + SFF.
Tier membership is declared in the ontology via cids:belongsToTier and materialized in generated SHACL. See Obligations by tier and the SHACL generator documentation.
Audiences
Section titled “Audiences”| Audience | Read first | Can skip or defer |
|---|---|---|
| Software developers / vendors | Developers guide, normative references, serialization, alignment, obligations | Strategy prose on commonapproach.org |
| Funders / portfolio users | Introduction, conformance, examples; then Graph Cast if using hosted import | OWL and SHACL file internals |
| SPOs (via their tools) | commonapproach.org overview; rely on aligned software for export | Direct SHACL editing |
| Ontology contributors and maintainers | Full MAP + CIDS GitHub repo | Graph Cast API reference |
Related
Section titled “Related”- Overview — navigation hub
- Normative references — pinned artifact URLs
- Graph Cast — optional hosted implementation (non-normative)
