When to apply When a project, dataset, or output involves Indigenous knowledge, data, or participants, and the institution needs to operationalise the CARE principles alongside (not instead of) FAIR.
Before you start
Prerequisites
What needs to be in place before you operationalise Indigenous data governance — CARE principles terminology in your CRIS or repository.
- Awareness that CARE (Collective benefit, Authority to control, Responsibility, Ethics) is not a replacement for FAIR but a complement that constrains how FAIR is implemented
- A working relationship with Indigenous data-governance bodies, traditional knowledge holders, or relevant Indigenous research-ethics frameworks (CIHR Chapter 9, AIATSIS, Te Mana Raraunga, GIDA-CARE)
- A controlled vocabulary for Indigenous-data flags that does not itself disclose what is being protected
- An access-control layer in the repository that supports community-determined access, not just open/closed
- TK Labels and BC Labels familiarity (Local Contexts Hub) for biocultural and traditional-knowledge metadata
Deployment
Five steps to deploy
Each step is small enough to land in a single sprint or a single sitting with the relevant CRIS administrator. Follow in order.
Add a community-governance entity
A first-class record type that names the community or governance body holding decision authority over a dataset. Includes contact, agreement_document, governance_scope, and version. Datasets link to this entity rather than carrying scattered references.
Adopt TK Labels and BC Labels
Apply Local Contexts TK / BC Labels at the record level for traditional-knowledge and biocultural data; the labels carry community-defined access and use expectations as structured metadata that travels with the record.
Configure community-determined access controls
Beyond open/closed, support: open within community, open with attribution to community, open with prior notification to community, restricted with community-approved gatekeeper. Each access mode points to a documented decision path.
Capture consent provenance
Free-prior-and-informed consent records belong on the project record: who consented, on whose behalf, scope of consent, withdrawal pathway. Treat these as living records that can be updated — not as one-time deposits.
Pilot with a partner Indigenous-led project
Test the entire workflow on a real project led by Indigenous researchers, with community partners as reviewers of the CRIS configuration. Adjust the controlled lists and access modes against their feedback rather than yours.
Worked example
Sample workflow
A realistic walk-through of a single record passing through the Indigenous data governance — CARE principles pipeline once the checklist is in production.
Integration points
CRIS and repository systems
Vendor-specific notes on where this vocabulary fits in real research-information systems. Names appear here only where there is public field evidence — they are not vendor partnerships.
Federation target for TK Labels and BC Labels. Register the institutional repository as a Local Contexts cooperator and use the Hub APIs to fetch and apply labels.
Add Indigenous-governance entity via configurable-entities; integrate TK Labels via a custom metadata schema and the Local Contexts Hub API.
Add community-governance and consent-provenance as custom metadata blocks on the Output and Project entities; use the Pure access-control layer for community-determined access modes.
Strong native support for differential access via dataset templates and custom metadata blocks; supports the access-request-with-justification pattern that CARE-aligned datasets often require.
Mukurtu is built from the ground up for Indigenous-community knowledge management; the right answer for some communities is not "extend the institutional repo" but "host the canonical record in Mukurtu and link from the institutional record".
What goes wrong in the field
Common pitfalls
The patterns that show up repeatedly when this checklist is skipped or misapplied. Address these before they become entrenched.
- Implementing FAIR without CARE and treating Indigenous data as "just data with extra access rules"
- Naming Indigenous communities as keywords or affiliations instead of as governance entities with structured authority
- Letting open-access mandates over-ride community-determined access without negotiated exceptions
- Treating TK Labels as decorative rather than as structured metadata that should flow through downstream citations
- Skipping the community-partner review step in the CRIS configuration itself, designing the workflow without those it most affects
Frequently asked
Implementation FAQ
- Who maintains this checklist?
- The Indigenous data governance — CARE principles working group maintains the checklist alongside the dictionary terms in the same domain. It is reviewed each release cycle (March and September) and updated when a working-group consultation, a vendor product change, or a federation-partner schema update materially changes the operational guidance.
- What if my CRIS or repository is not listed?
- The integration points listed name the systems CASRAI has direct field experience with — Pure, Symplectic Elements, Worktribe, Converis, DSpace and DSpace-CRIS, EPrints, VIVO, Dataverse, Invenio-RDM. The CERIF mapping in the checklist is vendor-neutral and applies equally to other CRIS or repository products. If your system supports the underlying entities (Person, Project, Output, Funding, plus the domain-specific extensions), the steps transfer.
- How do I validate my implementation?
- Three validation surfaces. First, the deposit form should refuse a record missing required fields rather than warn and accept. Second, the resulting metadata should round-trip through the federation layer your institution uses (OpenAIRE Guidelines 4.0 for European federation, DataCite Commons for DOI-anchored discovery, Crossref for article-anchored discovery) without upstream errors. Third, walk a real-world record through the sample-workflow path on this page and confirm the structured fields capture what the prose describes.
- Where do I report errors in the checklist?
- Open a comment via the dictionary-feedback flow at /dictionary/contribute. Editorial corrections — wrong vendor module names, deprecated standards, broken integration paths — are queued into the next release cycle. Substantive disagreements on the operational guidance are routed to the working group for review and may motivate a checklist revision.
- Is this checklist enough to certify my implementation?
- No. The checklist gives you the operational baseline; certification against federation profiles (CoreTrustSeal, OpenAIRE-compliant, COAR-aligned) is a separate process with its own audit. Treat the checklist as the engineering scaffolding and the certification as the institutional sign-off that the scaffolding is being used.
