Common Impact Data Standard Alignment Checklist
Overview
Section titled “Overview”This guide supports Alignment and conformance. For normative tier rules, see Obligations by tier. Integration pathways (relational, Graph Cast, spreadsheet utilities) are defined on the conformance page — this page focuses on interpreting the contents of the Alignment Checklist resource.
The Common Impact Data Standard Alignment Checklist (Excel file) contains all the classes and properties of the Common Impact Data Standard formatted as a table. Use it to map tables and columns in another database, schema, or spreadsheet to a chosen tier of alignment, and to look up datatype and cardinality restrictions.
Object-property descriptions conventionally start with “Refers to…”; literal descriptions start with “A/An” or “The …”. The checklist is derived from SHACL files on ontology.commonapproach.org.
Using the Alignment Checklist
Section titled “Using the Alignment Checklist”1. Filter the Alignment Checklist
Section titled “1. Filter the Alignment Checklist”Open the Alignment Checklist and filter the checklist tab to show only the classes and properties relevant to your chosen tier of alignment.
- If you are aligning to the Basic Tier and the Social Finance Fund (SFF) Companion Module, filter using column I (SFFTier) to hide blank rows.
- If you are aligning to only Basic, Essential, or Full Tier, filter using column H (CIDSTier)
2. Review the Alignment Checklist
Section titled “2. Review the Alignment Checklist”Checklist tab, columns A through J (mapping reference)
Section titled “Checklist tab, columns A through J (mapping reference)”These columns list the classes and properties to be mapped.
These columns are a flat file interpretation of the SHACL shapes files for the Common Impact Data Standard. Later in the alignment process, developers will use the SHACL files to validate their JSON-LD files for exchange (impact data capsules) to test conformance to the Data Standard.
| Column | Column name | Column description |
|---|---|---|
| A | targetClass | Provides the name of the Data Standard nodetype or class, which will generally map to entities or tables in your database. For general descriptions of the classes, see sections 2, 3, and 4 at https://ontology.commonapproach.org/cids-en.html and at https://ontology.commonapproach.org/sff-en.html for Social Finance Fund elements. |
| B | path | The names of the properties defined for the class, which will generally map to entity attributes or table columns in a database. |
| C | datatype | The datatype restriction for property values, if they are listed as sh:Literal in the nodeKind column (column G) |
| D | shClass | The class/type restriction for properties that link to other nodes, if they are listed as sh:IRI in the nodeKind column (column G). This is roughly equivalent to Foreign Keys. For example the Organization property hasAddress must link to a node of type Address. |
| E | minCount | The minimum allowed number of values for this property. Where minCount is 0, the value can be left blank/empty. See also this note on handling missing/empty values. |
| F | maxCount | The maximum allowed number of values for this property. Properties of nodeKind sh:IRI, with maxCount of 0 indicate a one-to-many or potentially many-to-many relationship between classes. Given the question “how many other nodes, maximum, can this node connect to”, a zero signifies “there is no maximum”, not “the maximum is zero”. A non-zero integer signifies the upper limit (often 1). |
| G | nodeKind | Indicates whether the property value is a sh:Literal with specified datatype column C, or sh:IRI (a link to another entity/class) with specified shClass in column D. |
| H | CIDSTier | Identifies which classes/properties belong to which “Tier of Alignment” for the Data Standard. |
| I | SFFTier | Identifies all required properties for reporting to Social Finance Fund, which includes all Basic Tier, some Essential Tier, and all Social Finance Fund Companion Module classes and properties. |
| J | description | a brief description of the meaning of the property’s data or value. |
In addition to what is noted in the checklist tab, all classes have two additional properties (@id and @type) that are a standard part of the Resource Description Framework (RDF) format.
- @id: a URI that is a globally unique, persistent identifier, and roughly equivalent to a primary key for a table row.
- @type: the class or nodetype (e.g. “Indicator”, “Outcome”, “Organization”)
For alignment pathway A, the @id and @type properties and their associated values must be preserved on a “round-trip” through the software (import and then re-export).
Checklist tab, columns K through P (user-filled)
Section titled “Checklist tab, columns K through P (user-filled)”| Column | Column name | Column description |
|---|---|---|
| K | Properties available in software | A simple “yes/no” column to quickly identify data coverage, flag engineering gaps, or highlight items for discussion on your first pass. For Pathway A (Relational): Mark “yes” if an equivalent entity/attribute exists in your schema. Mark “no” if a database column needs to be added to achieve compliance. For Pathway B (Graph Cast): Mark “yes” if this specific property is actively exposed to, collected from, or editable by the user in the UI application layer. Mark “no” if your UI ignores this field. Marking “no” is acceptable for API integrations; Graph Cast will still ingest, store, and re-export unmapped properties. |
| L | Label in UI | Where there is a confirmed or proposed mapping, enter the specific text label or navigation name used to display this data field or element to the end-user in the software interface. |
| M | Name in database | For Pathway A (Relational): input the precise name of the relevant database table or column (e.g., a metrics.description column mapped to the Indicator class’s hasDescription property). |
| N & O | Export & Import Alignment (Optional) | These optional columns can track specific edge cases, manual transformation processes, or unique logic variations during data ingest or generation. For Pathway A: Relational Use these fields to design the custom extraction and ingestion scripts needed to transform data between a relational model and a graph model. For Pathway B: Graph Cast Leave these columns blank. The heavy lifting of JSON-LD data ingestion, graph persistence, and SHACL format validation is offloaded to the managed cloud service. |
| P | Notes/Context | Use this field as needed to capture open questions (e.g., “should our Goal entity map to the standard’s Outcome class?”), clarify semantic equivalence, or note specific requirements for Graph Cast resources. |
3. Map Your Schema to the Standard
Section titled “3. Map Your Schema to the Standard”Go through the filtered checklist rows and enter mapping details in columns K through P. Verify that your application can structurally accommodate required fields for your chosen tier, and note how one-to-many and many-to-many relationships (for example Indicators ↔ Outcomes, Organization → Address) will be handled on export and import. Pathway-specific guidance is in Alignment and conformance.
Several classes share structure because they are subclasses of a parent class. See the subclasses tab of the Alignment checklist for details. In a table-based schema, parent and subclass instances may be able to share one table, differentiated by @type.
4. Optional formal review
Section titled “4. Optional formal review”Save your completed Alignment Checklist if you want Common Approach to review the mapping. See Alignment and conformance.