Skip to content

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).

  • 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.

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.

This profile covers:

  • The CIDS ontology (classes, properties, imported vocabularies) at a pinned release
  • Alignment tiers — Basic, Essential, and Full — scoped by cids:belongsToTier in 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 @context files; 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

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
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.

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