Real Ceremonial Technology Projects & Implementations

Research Date: 2026-03-05 Research Angle: Existing Projects & Architectural Case Studies Purpose: Extract specific design decisions that make technical systems "relational" rather than extractive, for use in the IAIP Ceremonial Technology Design skill.

Key Projects

Project 1: Mukurtu CMS

Relational Value

Cultural Protocol as first-class architectural primitive. Access to knowledge is not determined by generic roles (admin/user) but by relational standing within community—gender, kinship, ritual status, place-based relations. The system encodes the principle that knowledge has relationships, not just permissions.

Architectural Choices

1. Protocol-Entity Binding: Every digital heritage object (node) is bound to one or more Cultural Protocol entities. These are not tags—they are governing relationships that determine visibility at runtime via Drupal access control hooks.
2. Community Records (Polyvocal Metadata): A single artifact can carry multiple narrative descriptions from different community members. The data model rejects the colonial assumption of "one authoritative description." Each Community Record is a first-class entity, not a comment.
3. Protocol Intersection Logic: When an item has multiple protocols, the system evaluates the intersection of the user's group memberships against all assigned protocols. This mirrors real ceremonial access—you must hold the right combination of relationships.
4. Private File System Enforcement: Digital assets are served through Drupal's private file system, enforcing access at the webserver level (Apache/Nginx), not just the application layer. This prevents URL-guessing bypass.
5. TK Labels as Extended Metadata: Traditional Knowledge Labels are metadata fields that travel with objects, signaling community-defined use conditions beyond Western copyright. These are machine-readable (Dublin Core extensions) and human-readable.
6. Roundtrip Import/Export: Collections can be exported and re-imported across Mukurtu instances while preserving protocol assignments—community governance travels with the data.

Community Control Mechanism

• Community-managed protocols: Non-technical community members create, edit, and assign Cultural Protocols through an admin UI—no code changes required.
• Regional Mukurtu Hubs: Federated support network where Indigenous communities steer feature development.
• Advisory board governance: Feature priorities are set by Indigenous communities, not the development team.

Data Model

• Collective ownership: Communities, not individuals, own collections.
• Granular access tiers: Open, restricted, or custom (e.g., "women's knowledge," "clan-specific," "seasonal").
• Self-hosted option: Communities can host their own instance, maintaining physical and legal possession of data.

Lessons for Architects

• Access control should model social relationships, not just roles. Mukurtu's protocol system proves that culturally-grounded access control is technically feasible within standard CMS architecture.
• Polyvocal data models (multiple authoritative descriptions per object) are architecturally simple but epistemologically revolutionary.
• Community configurability without code is essential—if protocol changes require a developer, the system is not truly community-controlled.

Links

• Project site: https://mukurtu.org/
• GitHub (v3): https://github.com/MukurtuCMS/mukurtucms
• GitHub (v4): https://github.com/MukurtuCMS/Mukurtu-CMS
• Architecture overview: https://mukurtu.org/about/
• User manual: https://docs.mukurtu.org/
• Case study (NEH): https://www.neh.gov/article/mukurtu-digital-platform-does-more-manage-content
• Kim Christen on Indigenous Knowledge Systems: https://des4div.library.northeastern.edu/indigenous-knowledge-systems-and-mukurtu-cms/

Project 2: Local Contexts Hub & TK/BC Labels

Relational Value

Indigenous authority encoded as portable, machine-readable metadata that travels with data across systems. The project addresses a fundamental power asymmetry: once Indigenous knowledge enters institutional databases, communities lose the ability to signal how it should be used. TK Labels restore that voice at the data level.

Architectural Choices

1. Label Ontology in SKOS/RDF: TK Labels are formalized as concepts in Simple Knowledge Organization System (SKOS) and Resource Description Framework (RDF). This makes Indigenous use-conditions interoperable with semantic web infrastructure—labels can be queried, linked, and reasoned about programmatically.
2. RESTful API with Project-Scoped Access: The Local Contexts Hub exposes a REST API (Django/Python) where labels are retrieved by project ID. Only projects with Public or Discoverable visibility are API-accessible—community-controlled visibility is enforced at the API layer.
3. Label-as-Metadata-Extension Pattern: Labels attach to existing metadata schemas (Dublin Core, EAD, MODS, Darwin Core) as extensions. This is architecturally critical—it means labels can be adopted without replacing institutional systems. They layer Indigenous governance onto existing infrastructure.
4. Sandbox Environment for Integration Testing: A separate sandbox instance (sandbox.localcontextshub.org) allows institutions to test label integration before going live—reducing risk of misimplementation.
5. Institutional Integration Modules: Purpose-built connectors for systems like Dataverse, GBIF, and museum collection management systems. Each module maps label metadata into the target system's schema while preserving semantic integrity.
6. Community Customization Workflow: Labels are not fixed—communities customize label text, conditions, and context through the Hub's admin interface. Each label instance reflects a specific community's governance framework.

Community Control Mechanism

• Community-initiated projects: Only registered Indigenous communities or authorized institutions can create label projects.
• Visibility controls: Communities choose Public, Discoverable, or Private visibility for each project.
• Label customization: While label categories (TK Attribution, TK Non-Commercial, etc.) are standardized, the specific text, conditions, and guidance within each label are community-authored.
• API key authentication: Institutional API access is managed through registered keys, creating an audit trail of who accesses community-governed metadata.

Data Model

• Labels travel with data: Once attached, labels persist across exports, imports, and cross-platform transfers.
• Dual addressing: Labels are both human-readable (visual iconography + explanatory text) and machine-readable (RDF/SKOS).
• FAIR + CARE alignment: The system explicitly supports both FAIR (Findable, Accessible, Interoperable, Reusable) and CARE (Collective Benefit, Authority to Control, Responsibility, Ethics) principles.

Lessons for Architects

• Governance metadata should be portable, not platform-locked. TK Labels work because they are standards-based (RDF/SKOS), not proprietary.
• Layer, don't replace. The extension-metadata pattern is a powerful design for adding relational governance to extractive systems without requiring those systems to be rebuilt.
• Machine-readability enables enforcement at scale. Human-readable labels are educational; machine-readable labels enable automated policy enforcement.

Links

• Project site: https://localcontexts.org/
• TK Labels overview: https://localcontexts.org/labels/traditional-knowledge-labels/
• Hub platform: https://localcontextshub.org/
• API documentation (v2): https://localcontexts.org/support/api-guide/v2/
• GitHub: https://github.com/localcontexts/localcontextshub
• RDF ontology: https://idn-au.github.io/lc-vocs/tk-labels.html
• GBIF integration pilot: https://techdocs.gbif.org/en/data-publishing/local-contexts-pilot
• Dataverse integration: https://guides.dataverse.org/en/6.9/installation/localcontexts.html

Project 3: Te Hiku Media / Papa Reo

Relational Value

Kaitiakitanga (guardianship/stewardship) as the governing principle for AI training data and models. Te Hiku Media demonstrates that the most extractive technology (machine learning) can be redesigned around Indigenous values—the community that provides the data governs the models built from it. This is the clearest existing example of anti-extractive AI architecture.

Architectural Choices

1. Community-Controlled Training Data Pipeline: Speech data is gathered through direct partnership with tribal elders and fluent speakers. The data pipeline includes cultural authentication—not just technical quality control but verification that recordings carry appropriate cultural context.
2. On-Premises / Community-Controlled Storage: Training data is stored on Māori-controlled systems, explicitly not on cloud platforms or big tech infrastructure. This is a deliberate architectural choice that trades scalability for sovereignty.
3. Kaitiakitanga License (Legal-Technical Hybrid):
   • Permission-based access: No automatic "open" access. Every use requires explicit Te Hiku Media approval.
   • Non-commercial by default: Commercial use prohibited unless explicitly authorized.
   • Derivative works bound: Any work derived from licensed resources inherits the Kaitiakitanga License—guardianship propagates through the dependency chain.
   • Tikanga compliance: Access conditioned on adherence to Māori customs, not just legal terms.
   • Living license: Terms evolve as community needs change—the license is not frozen at publication.
4. Small-Corpus Optimization: ASR and NLP models are optimized for smaller, higher-quality corpora rather than the data-hungry approach of Silicon Valley. This is both a technical innovation (efficient training) and a values alignment (quality of relationship over quantity of extraction).
5. Multiple Specialized Tools Under One Governance Umbrella: Papa Reo (speech recognition), Kaituhi (writing tools), Whare Kōrero (language resources), Rongo (additional tools)—each with its own Kaitiakitanga License instance, but all under Te Hiku Media's unified governance.

Community Control Mechanism

• Te Hiku Media as kaitiaki (guardian): The organization holds guardianship on behalf of iwi (tribal) communities, not as a corporate owner.
• Explicit permission for every use: No blanket licenses. Each use case is evaluated against community benefit.
• License as living document: Community needs change; the license changes with them. This is governance-as-code that acknowledges temporal relationships.
• Anti-digital-colonization stance: The architecture was designed explicitly in response to big tech attempts to harvest Māori language data for commercial models.

Data Model

• Data remains with community: Physical and legal possession stays with Te Hiku Media / iwi.
• Models are community assets: Trained AI models belong to the community that provided training data, not to the model developers.
• Guardianship, not ownership: The conceptual frame is kaitiakitanga (guardianship for future generations), not ownership (control for present benefit).

Lessons for Architects

• Licensing is architecture. The Kaitiakitanga License is not a legal afterthought—it is a core architectural component that determines what can be built, by whom, and for whose benefit.
• Anti-extraction requires physical control. Community-controlled storage is not just a policy preference; it is a necessary architectural choice when the threat model includes corporate data harvesting.
• Small data can be better data. Optimizing for smaller, high-quality, relationally-authenticated datasets produces models that are both technically sound and culturally grounded.
• Derivative propagation (copyleft for guardianship) prevents the "laundering" of Indigenous data through intermediary tools.

Links

• Papa Reo: https://papareo.nz/
• Papa Reo API Kaitiakitanga License: https://papareo.io/kaitiakitanga
• Kaitiakitanga License (GitHub): https://github.com/TeHikuMedia/Kaitiakitanga-License
• License text: https://github.com/TeHikuMedia/Kaitiakitanga-License/blob/tumu/LICENSE.md
• Te Hiku Media: https://tehiku.nz/
• Data sovereignty explanation: https://tehiku.nz/te-hiku-tech/te-hiku-dev-korero/25141/data-sovereignty-and-the-kaitiakitanga-license
• Te Hiku GitHub org: https://github.com/TeHikuMedia
• NVIDIA case study: https://blogs.nvidia.com/blog/te-hiku-media-maori-speech-ai/
• Māui Hudson on tikanga & tech: https://www.mea.nz/korero/tikanga-technology-maui-hudson-on-indigenous-data-sovereignty-ai

Project 4: Australian Indigenous Data Network (IDN)

Relational Value

Indigenous governance over linked data infrastructure. The IDN demonstrates that even the most "open" technical standards (linked data, RDF, DCAT) can be deployed under Indigenous governance frameworks. The relational value is that interoperability does not require surrender of sovereignty—data can be connected without being extracted.

Architectural Choices

1. Prez Linked Data Publishing Platform: The IDN uses "Prez," an open-source linked data publishing tool, to deliver its Indigenous Data Catalogue. Prez serves metadata as machine-readable RDF while respecting community-defined access and governance constraints.
2. DCAT/RDF/SKOS Standards Stack: The catalogue uses international standards (Data Catalogue Vocabulary, Resource Description Framework, Simple Knowledge Organization System) for interoperability. This means Indigenous data can participate in global research infrastructure on Indigenous terms.
3. Programmatic FAIR + CARE Scoring: The system implements automated assessment of datasets against both FAIR principles (technical quality) and CARE principles (Indigenous governance quality). This dual scoring is a unique architectural innovation—it measures both interoperability and relationality.
4. Multi-Catalogue Architecture: The platform publishes multiple linked catalogues: demonstration datasets, an agents database (people/organizations), vocabularies, and spatial reference data (languages, land use, treaty areas). This multi-catalogue design reflects relational complexity rather than flattening it.
5. Co-Design Methodology as Infrastructure: The IDN's technical architecture was developed through ARDC-facilitated co-design workshops with Indigenous communities. The workshops are not just consultation—they produce design requirements that directly shape the platform's technical specifications.
6. Spatial Data Integration: Indigenous language boundaries, land use patterns, and treaty areas are encoded as spatial linked data, connecting cultural governance to geographic reality.

Community Control Mechanism

• University of Melbourne Indigenous Studies Unit leadership: The IDN is led by Indigenous scholars, not by a tech team.
• Co-design workshops: Technical decisions require community input—workshop reports are published (e.g., on Zenodo) for transparency.
• CARE principles as technical requirements: Each dataset in the catalogue is assessed against CARE, making governance compliance a measurable, not aspirational, property.
• Open-source transparency: All code and catalogue data are on GitHub, enabling community audit.

Data Model

• Linked data under Indigenous governance: Data is connected but not surrendered. The linked data standards enable interoperability while the governance layer controls access and use.
• DCAT metadata profiles: Custom metadata profiles extend standard DCAT to include Indigenous governance fields.
• FAIR + CARE dual compliance: Every dataset is scored on both axes, preventing the common failure mode where "FAIR" is used to override Indigenous governance concerns.

Lessons for Architects

• Standards-based ≠ extractive. Linked data and RDF are often associated with "open data" ideology, but the IDN proves they can serve Indigenous governance equally well.
• Measure what matters. The dual FAIR+CARE scoring system makes governance compliance visible and auditable—you can't manage what you don't measure.
• Co-design is not decoration. When workshop outputs directly shape technical specifications, the resulting architecture reflects relational values by construction, not by retrofit.
• Spatial data is relational data. Encoding language boundaries and treaty areas as linked data connects governance to place in a technically rigorous way.

Links

• IDN site: https://idnau.org/
• IDN Data Catalogue: https://data.idnau.org
• GitHub catalogue data: https://github.com/idn-au/catalogue-data
• Indigenous Data Governance resources: https://idnau.org/resources/idg
• ARDC project page: https://ardc.edu.au/project/improving-indigenous-research-capabilities/
• ARDC article: https://ardc.edu.au/article/improving-indigenous-research-capabilities-through-data/
• Co-design workshop report (Zenodo): https://zenodo.org/records/10807353
• TK Labels RDF vocabulary: https://idn-au.github.io/lc-vocs/tk-labels.html

Project 5: FNIGC & OCAP® Infrastructure

Relational Value

Ownership-Control-Access-Possession as a complete data sovereignty framework with operational infrastructure. OCAP® is not merely a policy statement—it is an operational blueprint that has shaped the technical infrastructure of First Nations data collection, storage, and dissemination across Canada for over two decades. The relational value is that data about a people belongs to that people at every layer of the stack.

Architectural Choices

1. Community-Initiated Data Collection: National surveys (e.g., the First Nations Regional Health Survey) are designed, conducted, and controlled by First Nations communities. The technical architecture begins at data creation, not data storage—instruments, sampling, and methodology are community-governed.
2. FNIGC-Managed Secure Storage: Data is stored in secure systems controlled by FNIGC or by individual First Nations. The architecture enforces the "Possession" principle—physical and technical custody of data resides with First Nations infrastructure, not government or university servers.
3. Formal Data Access Protocols: Access to datasets requires formal agreements, community review, and explicit authorization. The technical implementation includes review processes, agreements management, and audit trails.
4. Regional Data Centre Architecture: A distributed model where regional First Nations organizations maintain local data centres and participate in national governance. This federated architecture prevents single points of control or extraction.
5. Capacity Building as Infrastructure: OCAP® training programs are integral to the technical architecture. The system is designed so that community members—not external consultants—operate the infrastructure. Training is not supplementary; it is a load-bearing component.
6. Data Repatriation Workflows: Technical processes for auditing external databases (government, academic, corporate) and reclaiming First Nations data. This is infrastructure for reversing extraction, not just preventing it.

Community Control Mechanism

• OCAP® certification: Organizations must demonstrate compliance with OCAP® principles to participate in data governance.
• Community review panels: Data access requests are evaluated by community representatives, not by technical administrators.
• Federated governance: Regional organizations have autonomy within the national framework—no single entity controls all data.
• Data agreements as enforceable contracts: Access protocols are legally binding, not aspirational guidelines.

Data Model

• Collective ownership: First Nations collectively own data about their communities—this is a foundational axiom, not a policy choice.
• Tiered access: Different levels of data (aggregate, community-level, individual) have different access requirements.
• Possession = sovereignty: Physical custody of data is treated as a necessary condition for meaningful governance.
• Repatriation rights: The data model includes mechanisms for reclaiming data held by external parties.

Lessons for Architects

• Sovereignty starts at data creation. If the community doesn't control how data is collected, downstream governance is fundamentally compromised.
• Physical possession is a technical requirement. Cloud-first architecture is incompatible with data sovereignty when the cloud provider is not the data subject.
• Capacity building is infrastructure. A system that requires external experts to operate is not truly community-controlled, regardless of its governance policies.
• Repatriation architecture (workflows for reclaiming externally-held data) is as important as prevention architecture—extraction has already happened, and systems must account for recovery.
• Federated > centralized for sovereignty. Distributed architecture prevents single points of control.

Links

• FNIGC: https://fnigc.ca/
• OCAP® training: https://fnigc.ca/ocap-training/
• OCAP® fact sheet: https://www.uottawa.ca/library/sites/g/files/bhrskd381/files/2022-12/bestpractices_fnigc_ocap_fact_sheet_en_final.pdf
• First Nations Data Governance Strategy (AFN): https://afn.ca/wp-content/uploads/2021/10/Jonathan-Dewar-Presentation.pdf
• OCAP® and Data Sovereignty (FNIGC presentation): https://osi-bis.ca/wp-content/uploads/2023/04/AARON-FRANKS-FNIGC-First-Nations-Principles-of-OCAP.pdf
• Wikipedia: https://en.wikipedia.org/wiki/First_Nations_principles_of_OCAP
• First Nations Governance Practices: https://opentextbc.ca/indigenousdigitalliteracies/chapter/first-nations-governance/

Cross-Project Patterns

Pattern 1: Access Control Models Social Relationships, Not Just Roles

Every project replaces generic role-based access (admin/editor/viewer) with relationship-based access (kinship, protocol standing, community membership, tribal affiliation). This is the most consistent architectural pattern across all five projects.

Technical implementation: Custom access control hooks that evaluate group membership intersections, not just role hierarchies.

Pattern 2: Governance Metadata Travels With Data

TK Labels (Local Contexts), Cultural Protocols (Mukurtu), Kaitiakitanga License terms (Te Hiku), CARE scores (IDN), and OCAP® agreements (FNIGC) all attach governance information to the data itself, not to the platform hosting it.

Technical implementation: Metadata extensions using standards like RDF/SKOS/Dublin Core, or custom license propagation through derivative works.

Pattern 3: Physical Possession as Architectural Requirement

Te Hiku Media's on-premises storage, FNIGC's community data centres, Mukurtu's self-hosting option, and IDN's community-controlled catalogue all treat physical data custody as a non-negotiable design requirement, not a deployment preference.

Technical implementation: Self-hosted infrastructure, private file systems, explicit rejection of cloud-first patterns when sovereignty is at stake.

Pattern 4: Community Configurability Without Code

All five projects enable non-technical community members to create, modify, and assign governance rules (protocols, labels, licenses, access agreements) through administrative interfaces.

Technical implementation: Admin UIs for governance configuration, customizable label/protocol templates, visual workflow tools.

Pattern 5: Polyvocality and Multiple Authorities

Mukurtu's Community Records, Local Contexts' community-customized labels, and IDN's multi-catalogue architecture all reject the assumption of a single authoritative description. Multiple legitimate perspectives coexist within the system.

Technical implementation: Multiple narrative entities per object, community-scoped label customization, multi-catalogue architectures.

Pattern 6: Standards-Based But Not Standards-Captured

All projects use international standards (Dublin Core, DCAT, RDF, SKOS, REST APIs) but layer Indigenous governance on top of these standards rather than being constrained by them. Interoperability does not require surrender.

Technical implementation: Metadata extensions, custom ontologies, governance overlays on standard schemas.

Pattern 7: Licensing as Architecture

Te Hiku's Kaitiakitanga License, Mukurtu's GPL + protocol system, and FNIGC's data access agreements demonstrate that legal instruments are architectural components—they determine what can be built, by whom, and under what conditions.

Technical implementation: License files as repository artifacts (GitHub), copyleft-style propagation for guardianship, enforceable data sharing agreements.

Pattern 8: Capacity Building as Load-Bearing Infrastructure

FNIGC's OCAP® training, Mukurtu's regional hubs, IDN's co-design workshops, and Te Hiku's community partnerships all treat training and capacity building as infrastructure, not as supplementary activities.

Technical implementation: Training programs integrated into deployment workflows, co-design outputs that directly produce technical specifications.

Architectural Decision Framework for Ceremonial Technology

Based on these five projects, an architect evaluating whether a system is "relational/ceremonial" vs. "extractive" should ask:

Sources

Mukurtu CMS

• https://mukurtu.org/
• https://mukurtu.org/about/
• https://github.com/MukurtuCMS/mukurtucms
• https://github.com/MukurtuCMS/Mukurtu-CMS
• https://docs.mukurtu.org/
• https://des4div.library.northeastern.edu/indigenous-knowledge-systems-and-mukurtu-cms/
• https://www.neh.gov/article/mukurtu-digital-platform-does-more-manage-content
• https://humanitiesforall.org/projects/mukurtu-an-indigenous-archive-and-publishing-tool
• https://sustainableheritagenetwork.org/digital-heritage/mukurtu-cms-communities-cultural-protocols-and-categories
• https://www.interaccess.org/tf-case-studies/mukurtu
• https://www.imls.gov/grant-spotlights/mukurtu-software-preserves-indigenous-digital-heritage-through-technologies-today
• https://knowledgebase.arts.ubc.ca/mukurtu/

Local Contexts Hub & TK Labels

• https://localcontexts.org/
• https://localcontexts.org/labels/traditional-knowledge-labels/
• https://localcontextshub.org/
• https://localcontexts.org/support/api-guide/v2/
• https://github.com/localcontexts/localcontextshub
• https://idn-au.github.io/lc-vocs/tk-labels.html
• https://techdocs.gbif.org/en/data-publishing/local-contexts-pilot
• https://guides.dataverse.org/en/6.9/installation/localcontexts.html
• https://www.wipo.int/edocs/mdocs/tk/en/wipo_iptk_ge_17/wipo_iptk_ge_17_presentation_10anderson.pdf
• https://sustainableheritagenetwork.org/system/files/atoms/file/KimChristenWithey_TribalArchivesTraditionalKnowledgeandLocalContexts.pdf

Te Hiku Media / Papa Reo

• https://papareo.nz/
• https://papareo.io/kaitiakitanga
• https://github.com/TeHikuMedia/Kaitiakitanga-License
• https://github.com/TeHikuMedia/Kaitiakitanga-License/blob/tumu/LICENSE.md
• https://tehiku.nz/
• https://tehiku.nz/te-hiku-tech/te-hiku-dev-korero/25141/data-sovereignty-and-the-kaitiakitanga-license
• https://github.com/TeHikuMedia
• https://blogs.nvidia.com/blog/te-hiku-media-maori-speech-ai/
• https://www.mea.nz/korero/tikanga-technology-maui-hudson-on-indigenous-data-sovereignty-ai
• https://www.taiuru.co.nz/maori-data-sovereignty-licences/
• https://www.rnz.co.nz/news/te-manu-korihi/527405/maori-media-company-head-peter-lucas-jones-named-on-time-magazine-list-for-preserving-te-reo-through-ai

Australian Indigenous Data Network (IDN)

• https://idnau.org/
• https://data.idnau.org
• https://github.com/idn-au/catalogue-data
• https://idnau.org/resources/idg
• https://ardc.edu.au/project/improving-indigenous-research-capabilities/
• https://ardc.edu.au/article/improving-indigenous-research-capabilities-through-data/
• https://zenodo.org/records/10807353
• https://mspgh.unimelb.edu.au/centres-institutes/onemda/research-group/indigenous-studies-unit/indigenous-data-network

FNIGC & OCAP®

• https://fnigc.ca/
• https://fnigc.ca/ocap-training/
• https://www.uottawa.ca/library/sites/g/files/bhrskd381/files/2022-12/bestpractices_fnigc_ocap_fact_sheet_en_final.pdf
• https://afn.ca/wp-content/uploads/2021/10/Jonathan-Dewar-Presentation.pdf
• https://osi-bis.ca/wp-content/uploads/2023/04/AARON-FRANKS-FNIGC-First-Nations-Principles-of-OCAP.pdf
• https://en.wikipedia.org/wiki/First_Nations_principles_of_OCAP
• https://opentextbc.ca/indigenousdigitalliteracies/chapter/first-nations-governance/

Cross-Cutting / CARE Principles

• https://datascience.codata.org/articles/dsj-2020-043
• https://ardc.edu.au/resource/the-care-principles/
• https://indigenousdatalab.org/care-data-maturity-model/
• https://usindigenousdatanetwork.org/2024/01/the-care-data-maturity-model/
• https://indigenousnavigator.org/news/indigenous-navigator-indigenous-data-sovereignty-and-the-care-principles
• https://localcontexts.org/operationalizing-care-principles-and-indigenous-data-sovereignty-in-genomic-research-projects/
• https://fatsil.org/indigenous/data-sovereignty/
• https://nni.arizona.edu/our-work/research-policy-analysis/indigenous-data-sovereignty-governance
• https://indigenousdatalab.org/