Ceremonial Technology Design Patterns: Research Synthesis

Research Date: March 5, 2026
For: IAIP Ceremonial Technology Design Skill
Synthesized from: 5 parallel research tracks covering Indigenous data sovereignty, decolonial design, real projects, extraction patterns, and Indigenous technologists' frameworks

Purpose: Extract operational patterns for embedding Indigenous protocols into system architecture, showing how relational values translate to code, governance, and data flows.

Executive Summary

Ceremonial Technology is not a theoretical construct—it is being built today by Indigenous communities, decolonial designers, and Indigenous-led tech initiatives. Research across 5 parallel tracks reveals:

OCAP & CARE principles translate directly to architecture: Data Ownership → Provenance Models; Control → Governance Engines; Access → Permission Inversion; Possession → Federated Data Residency.
Community veto points are architecturally enforceable: Constitutional veto (governance as root authority), Classification veto (T3 as default), Consent veto (FPIC as ongoing middleware), Kill switches (immediate revocation).
Six relational architecture patterns have been deployed in production: Data Sovereignty Layers, Federated Governance, Reciprocity Enforcement, Community Veto Gates, Pluriversal Interfaces, and Care Infrastructure.
Five real projects demonstrate working ceremonial technology: Mukurtu CMS (cultural protocol as access control), Local Contexts TK Labels (governance metadata), Te Hiku Papa Reo (kaitiakitanga over language), Australian Indigenous Data Network (linked data under Indigenous governance), FNIGC/OCAP Infrastructure (federated data sovereignty).
Extractive systems have identifiable architectural markers: Data Enclosure, Algorithmic Opacity, Consultation Theater, Universal Solutionism, Perpetual Licenses, Performative Sovereignty, Surveillance-as-Default, Innovation Extraction.
Indigenous technologists center relational accountability as the core principle: Technology as Kin (not tool), Data as Relative (not resource), Country-Centered Design, Sovereignty Before Service, Seven Generations Thinking, Abundance Over Scarcity.

Key Findings

Finding 1: OCAP Principles Are Architectural Requirements, Not Policy Documents

The OCAP® framework (Ownership, Control, Access, Possession) developed by the First Nations Information Governance Centre (FNIGC) is often treated as a governance philosophy. Research shows it must be embedded as technical architecture to be enforceable.

Ownership requires provenance metadata architecture where every data object is tagged with its originating community as legal owner (immutable, non-transferable without consent)
Control requires a governance middleware layer that gates all data state transitions (collection → analysis → publication → sharing)
Access inverts the typical open-by-default model: all data starts restricted; access is granted by community decision via explicit permission tokens
Possession demands federated architecture where community data physically resides on sovereign infrastructure—not just policy, but technical architecture

Implication for Design: Systems claiming to support OCAP must have these architectural features visible in the data model, access control layer, and deployment topology. If OCAP "support" is only in documentation, it is not enforced.

Finding 2: The Tiered Sovereign Data Framework (TSDF) Solves the Default Classification Problem

The Affiliated Tribes of Northwest Indians published a GitHub-enforceable standard that radically reverses typical security defaults.

T0 (Open) ← → T3 (Sovereign Maximum Protection)

The innovation: T3 is the default classification. Data over-classified is correctable; under-classified may cause irreversible harm.

This is architecturally critical because:

All new data enters systems at T3 by default
Reclassification to T2/T1/T0 requires explicit community multi-signature approval
Database triggers or middleware enforce T3 as the starting state
Downgrades can be audited, logged, and reversed

Implication for Design: Most security frameworks default to "least privilege for access" but "open by default for data." TSDF inverts this: assume maximum protection, require explicit community decision to relax restrictions.

Finding 3: Cultural Protocol Access Control (Mukurtu) Proves Relational Access Is Architecturally Feasible

The Warumungu and broader Indigenous communities (via Mukurtu CMS) demonstrate that access control can model social relationships and ceremonial standing, not just generic roles.

How it works:

Every digital object is bound to Cultural Protocol entities (representing relational standing: gender, kinship, ritual status, place-based relations)
Protocol intersection logic evaluates whether a user holds the combination of relationships required to access an object
Community Records (polyvocal metadata) allow multiple authoritative descriptions of the same object—rejecting the colonial assumption of "one truth"
Access is enforced at the webserver level (Drupal private file system), preventing URL-guessing bypasses

Architectural Pattern: ``` Data Object → [Protocol 1, Protocol 2, Protocol 3] User → [Group: Women, Clan: X, Initiated: Ritual Y] Access Decision = Intersection of User's Groups with Object's Required Protocols ```

Implication for Design: Access control should model the social structure that actually determines who should access what, not abstract generic roles.

Finding 4: Portable Governance Metadata (TK Labels) Layers Relational Authority onto Extractive Systems

The Local Contexts Hub & Traditional Knowledge (TK) Labels address a critical problem: once Indigenous knowledge enters institutional databases, communities lose the ability to govern how it is used.

The Solution:

TK Labels are formalized as machine-readable metadata (SKOS/RDF)
Labels travel with data across systems via standardized metadata extensions (Dublin Core, EAD, MODS, Darwin Core)
Communities author label text, conditions, and use guidance
Labels are both human-readable (iconography + text) and machine-readable (RDF/SKOS), enabling automated policy enforcement

Architectural Innovation: Layer, Don't Replace Instead of requiring institutions to rebuild systems, labels layer Indigenous governance onto existing infrastructure. This is powerful because:

Institutions don't need to overhaul their database schemas
Communities maintain authority over what labels say
Tooling exists (Dataverse, GBIF connectors) to automatically enforce label rules
Labels survive across exports, imports, and platform migrations

Implication for Design: Add relational governance to existing systems via standardized, portable metadata layers—this scales faster than replacing institutions' technical infrastructure.

Finding 5: Community Veto Points Must Be Architecturally First-Class, Not Afterthoughts

Across OCAP, CARE Principles, Nadlii platform, and TSDF, six community veto mechanisms appear:

Constitutional Veto: Community governance body is root certificate authority; no external entity can override
Classification Veto: T3 is default; reclassification requires multi-signature community approval
Consent Veto: FPIC (Free, Prior, Informed Consent) is ongoing and revocable (not a one-time checkbox); middleware checks consent state before every data operation
Digital Kill Switch: Privileged revocation channel that instantly halts all data access, invalidates tokens, halts processing, triggers secure deletion
Research Ethics Gate: No research can proceed without community approval of research protocols and benefit-sharing arrangements
AI/ML Prohibition Tiers: Communities can categorically prohibit AI/ML on certain data classes (e.g., T3 data cannot enter training sets under any circumstances)

Implication for Design: These veto mechanisms should be first-class primitives in the architecture, not bolted on as afterthoughts. If a community can only veto through a manual support ticket, that is not real veto authority—it is theater.

Finding 6: Relational Database Architecture Is Not the Same as Relational-Values Architecture

"Relational" has two meanings in tech:

Relational databases (tables, rows, SQL) — technically efficient but epistemologically neutral
Relational architecture in the Indigenous sense — systems designed to foreground relationships, reciprocity, and accountability

Example: A relational database can store data about Indigenous communities in ways that enable surveillance and extraction. Technical relationality doesn't guarantee relational values.

The Distinction:

Extractive systems (relational DB or not): One-way data flows, unbounded collection, aggregation without community benefit, third-party leakage, no audit trail of who accessed what
Relational-values systems: Two-way flows with community feedback, bounded collection (only data needed for stated purpose), disaggregation by geography/time to prevent re-identification, zero third-party leakage, complete audit trails, community benefit-sharing

Implication for Design: Being "relational" in structure means nothing without relational values embedded in data governance and incentive structures.

Finding 7: Wilson's Relational Accountability Provides the Ethical Framework

Shawn Wilson's Research Is Ceremony proposes that knowledge is inseparable from relationships, and every action must honor those relationships.

The Four R's as system requirements:

R	Meaning	Architectural Implication
Respect	Honoring Indigenous authority over knowledge	Community approval gates all data operations
Relevance	Knowledge is useful only if meaningful to community stakeholders	Feedback loops; community defines success metrics
Reciprocity	Knowledge-sharing flows both directions	Data access rights are bidirectional; institutions share findings back with communities
Responsibility	Accountability for consequences across time and relationships	Seven-generations thinking; long-term impact assessment; extractive consequences are architecturally prevented

Implication for Design: Every system component should ask: "Does this action honor or violate relationships? Is it reciprocal? Is it accountable to future generations?"

Real Ceremonial Technology Projects

Project 1: Mukurtu CMS (Warumungu / Washington State University)

Core Relational Value: Cultural Protocol as first-class access control primitive

What It Does: Indigenous communities describe their cultural knowledge objects (stories, songs, photos, histories) and assign Cultural Protocols that determine who can see/use each object based on relational standing (gender, kinship, ritual initiation, seasonal access).

Architectural Choices That Enable Relationality:

Protocol-Entity Binding: Objects are not owned by individuals or departments but by communities via named Cultural Protocols
Community Records (Polyvocal Metadata): A single object can have multiple authoritative descriptions from different community members—the system stores all versions without ranking them
Protocol Intersection Logic: Access control evaluates the combination of relationships a user holds against the requirements of all protocols assigned to an object
Private File System Enforcement: Downloads are served through Drupal's private file system, preventing URL guessing
Roundtrip Preservation: Communities can export collections and re-import them to other Mukurtu instances while preserving protocol assignments

Community Control:

Communities define their own Cultural Protocols (no code changes)
Communities manage metadata and descriptions (no technical team involved)
Communities set visibility rules (who sees what)
Self-hosted option available for communities wanting full technical custody

Lessons for Architects:

Access control can model relational standing, not just roles
Polyvocal metadata (multiple authoritative descriptions) is technically simple but epistemologically revolutionary
Community configurability without code is essential for true community control
Ceremonial relationships can be enforced at the OS-level (private file systems) for security

Links:

Project 2: Local Contexts Hub & TK Labels (Global Indigenous Data Alliance)

Core Relational Value: Indigenous authority encoded as portable, machine-readable metadata

What It Does: Communities create Traditional Knowledge (TK) and Biocultural (BC) labels that travel with data, signaling Indigenous governance requirements. Labels are machine-readable (RDF/SKOS) so systems can enforce them automatically.

Architectural Choices That Enable Relationality:

SKOS/RDF Ontology: Labels are formal semantic web resources, interoperable with institutional systems
REST API with Project-Scoped Access: Only communities that own the project can modify labels; visibility is community-controlled
Label-as-Metadata-Extension Pattern: Labels layer onto existing metadata schemas (Dublin Core, EAD, Darwin Core) without replacing them
Institutional Connectors: Purpose-built modules for Dataverse, GBIF, museum systems ensure labels are properly enforced when data is accessed through those platforms
Sandbox Environment: Institutions can test label implementations before going live

Community Control:

Communities create and customize their own label projects
Communities choose visibility (Public, Discoverable, or Private)
Communities author label text and conditions
API key authentication creates an audit trail of institutional access

Data Model Innovation:

Labels are dual-addressed: human-readable (icons + text) and machine-readable (RDF)
Labels are immutable once attached to data objects (can't be removed without community consent)
Labels support both FAIR (Findable, Accessible, Interoperable, Reusable) and CARE (Collective benefit, Authority to control, Responsibility, Ethics) principles

Lessons for Architects:

Governance metadata should be portable (standards-based) not platform-locked
Layering relational authority onto extractive systems is more practical than replacing them
Machine-readable governance enables automated enforcement at scale
Communities should define label conditions, not algorithms

Links:

https://localcontexts.org/
https://localcontextshub.org/
API docs: https://localcontexts.org/support/api-guide/v2/
GBIF integration: 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 Papa Reo (Māori Language, Aotearoa/New Zealand)

Core Relational Value: Kaitiakitanga (guardianship) license embedded in language AI architecture

What It Does: Te Hiku Media builds speech recognition (ASR) and natural language processing systems for the Māori language under a Kaitiakitanga License that prevents commercial extraction and ensures community benefit.

Architectural Choices That Enable Relationality:

Kaitiakitanga License as Architecture: The license is not just legal language—it is encoded into the model deployment. Commercial use is technically prevented; community use is prioritized.
Data Residency on Māori Land: Language data and models are hosted on infrastructure controlled by Te Hiku and Māori communities, not external cloud providers
Transparent Training Data: Communities know exactly what data was used to train the models (no hidden scraping)
Community-First API Access: Māori language learners, educators, and community projects get free/prioritized access; commercial entities pay premiums or are declined
Seasonal & Contextual Adaptation: Model training respects Māori calendars, ceremonial contexts, and regional dialects—not treating language as a generic extraction target

Community Control:

Te Hiku (Māori community) sets all priorities (not funders or tech leaders)
Language policy decisions are made by Māori speakers, not engineers
Benefits (funding, training) flow back to Māori communities
No commercial training on Māori language data without explicit consent

Lessons for Architects:

Licenses can be architecturally enforced, not just legally binding
Language technology can be designed for community flourishing instead of extraction
Data residency is a key relational control mechanism
Contextual adaptation (seasons, ceremonies) should be first-class, not afterthoughts

Links:

https://tehiku.nz/
Papa Reo project: https://paparea.tehiku.nz/
Kaitiakitanga License discussion: https://www.tehiku.nz/news

Project 4: Australian Indigenous Data Network (Linked Data Under Indigenous Governance)

Core Relational Value: Indigenous governance architecture applied to semantic linked data

What It Does: The Australian Indigenous Data Network (IDN) uses the Prez linked data platform to publish Indigenous data (language, culture, history) under governance models built on OCAP principles and FAIR+CARE scoring.

Architectural Choices That Enable Relationality:

DCAT/RDF with FAIR+CARE Scoring: Every dataset is scored on FAIR metrics (Findable, Accessible, Interoperable, Reusable) AND CARE metrics (Collective benefit, Authority to control, Responsibility, Ethics), surfacing governance status alongside technical quality
Federated Governance Model: Multiple Indigenous communities maintain their own data under a common semantic framework
Sovereignty-First Data Publishing: Communities decide which data is public, which is restricted, and control all export/reuse rules
Semantic Interoperability Without Homogenization: SKOS vocabularies and DCAT catalogs allow data to be shared across communities while preserving distinct epistemologies
Linked Data Audit Trail: Full provenance tracking shows where data originated, who accessed it, and what it was used for

Community Control:

Indigenous communities curate their own datasets
Communities define access restrictions (CARE Principles applied)
Communities set reuse conditions via machine-readable ODRL policies
Communities can audit access and enforce restrictions

Data Model:

Each dataset includes provenance, community attribution, and access conditions
Linked data relationships are semantically meaningful (not just technical links)
FAIR+CARE scoring helps data consumers understand governance requirements

Lessons for Architects:

Linked data (semantic web) can be designed for relational governance, not just data integration
Federated architectures allow community autonomy within interoperable frameworks
Combining FAIR and CARE metrics surfaces both technical and ethical quality
Audit trails and full provenance are non-negotiable for accountability

Links:

Australian Indigenous Data Network: https://www.ardc.edu.au/indigenous-data-sovereignty
Prez platform: https://prez.dev/
FAIR+CARE scoring: https://www.ardc.edu.au/fair-care/

Project 5: FNIGC & OCAP® Infrastructure (First Nations Canada)

Core Relational Value: Complete data sovereignty infrastructure—OCAP principles operationalized end-to-end

What It Does: The First Nations Information Governance Centre (FNIGC) operates community-controlled survey systems, data repositories, and federated data centres where First Nations communities maintain physical and legal possession of data about themselves.

Architectural Choices That Enable Relationality:

Federated Data Centre Network: Data never leaves community jurisdiction; external researchers request access through community governance channels
Tiered Classification System: Data is classified T0-T3 with T3 being maximum protection, community-controlled reclassification
Benefit-Sharing Agreements: Revenue sharing and research result sharing are encoded into data access agreements
Community-Controlled Survey Infrastructure: First Nations design their own surveys (not external researchers imposing questions)
Multi-Nation Governance: Multiple First Nations can federate their data while maintaining individual sovereignty

Community Control:

First Nations own and control all data collection
First Nations set all access rules and conditions
First Nations approve all research proposals
First Nations collect all benefits (funding, research results, intellectual property)

Impact:

$9M NIH-funded Native BioData Consortium RADx Tribal Data Repository demonstrates the model at scale
Cheyenne River Sioux Tribe operates sovereign genomic biorepository on tribal land
First Nations use data for self-determined research priorities (not imposed by funders)

Lessons for Architects:

OCAP principles require end-to-end infrastructure design, not just databases
Physical possession is a relational and technical control mechanism
Federated architecture allows multiple sovereign communities to share infrastructure while maintaining individual authority
Benefit-sharing must be structurally enforced, not just promised

Links:

FNIGC: https://fnigc.ca/
OCAP Training: https://fnigc.ca/ocap-training/
Native BioData Consortium: https://nativebio.org/
RADx Tribal Data Repository: https://genomics.ucsc.edu/news/2023/12/indigenous-scientists-awarded-9m-to-establish-the-first-radx-tribal-data-repository-that-upholds-indigenous-data-sovereignty/

Design Patterns for Ceremonial Technology

Pattern 1: Data Sovereignty Layer

When to Use: When data needs community governance but systems already exist that are hard to replace

How It Works:

Metadata layer (ontology + governance rules) travels with data
Portable format (RDF/SKOS, ODRL, TK Labels) works across platforms
Institutional connectors enforce governance rules at access points
Communities author and control the metadata

Example:

Local Contexts TK Labels layer governance onto institutional databases (museums, universities, genomic repositories)
Australian Indigenous Data Network publishes DCAT records with FAIR+CARE scoring

Implementation Steps:

Define a shared metadata schema for governance (what decisions must be recorded?)
Create connectors for major systems used by stakeholders (Dataverse, GBIF, etc.)
Train community data stewards to create/maintain governance metadata
Build enforcement into system hooks (API middleware, database triggers)
Audit all access against metadata rules

Pattern 2: Federated Governance

When to Use: When multiple communities need autonomy but want to share infrastructure or data

How It Works:

Each community maintains sovereign control over their data
Communities federate at the governance layer (shared decision-making body)
Technical infrastructure is shared but data residency is respected
Cross-community queries require multi-party consent

Example:

FNIGC federated data centres (multiple First Nations, each sovereign)
Australian Indigenous Data Network (multiple Indigenous communities publishing linked data)

Implementation Steps:

Establish a governing body representing all communities
Build technical infrastructure that respects data residency (federated queries, not data warehouses)
Create consent workflows for cross-community data sharing
Implement audit trails that respect each community's governance rules
Use semantic interoperability (linked data) to enable sharing without homogenization

Pattern 3: Reciprocity Enforcement

When to Use: When data access should involve mutual benefit, not unidirectional extraction

How It Works:

Data access agreements include explicit reciprocity clauses (community gets research results, funding, training)
Reciprocity is architecturally enforced: researchers cannot publish results without community approval
Communities receive automatic shares of revenue from commercial use
System tracks fulfillment of reciprocity agreements

Example:

OCAP principles encode "Control" over research results
CARE Principles include "Responsibility" for collective benefit
Nadlii platform enforces reciprocity via governance middleware

Implementation Steps:

Define reciprocity terms in data access agreements (data governance, not just legal)
Build approval gates: research cannot progress without community consent to reciprocity terms
Implement revenue-sharing triggers (automatic payment distribution)
Create audit dashboard showing reciprocity fulfillment to communities
Escalate failures to enforcement (revoke access, legal action)

Pattern 4: Community Veto Gate

When to Use: When communities need the ability to halt operations due to harm, misuse, or policy violation

How It Works:

Communities have a privileged decision channel (faster than legal processes)
Veto can be constitutional (sovereignty-based), categorical (e.g., "no AI/ML on this data"), or consent-based (revocation)
Veto is architecturally first-class: not a support ticket, but a system control
Veto triggers immediate effects (access revocation, processing halt, deletion cascade)

Example:

TSDF: Communities can revoke data classifications (e.g., T3 data cannot enter AI training)
Mukurtu kill switch: Communities can instantly hide objects or change access protocols
Nadlii consent layer: Communities can revoke FPIC, halting all use

Implementation Steps:

Design veto mechanisms for different decisions (constitutional, categorical, consent-based)
Implement as first-class system controls, not advisory processes
Build immediate consequence triggers (access invalidation, pipeline halt)
Ensure audit trails record who vetoed what and when
Test veto mechanisms regularly to ensure they work under failure conditions

Pattern 5: Pluriversal Interface

When to Use: When systems serve communities with different epistemologies, protocols, or languages

How It Works:

Systems present different interfaces to different communities based on their protocols
Knowledge objects are described in multiple languages/frameworks simultaneously
Each community's worldview is respected, not forced into a single classification
Translational work happens at the interface layer, not in data storage

Example:

Mukurtu Community Records: same object described differently by different people
Australian Indigenous Data Network: SKOS vocabularies allowing multiple taxonomies
Papa Reo: Māori language models respect regional dialects and ceremonial contexts

Implementation Steps:

Identify the communities this system serves and their distinct epistemologies
Design data schema that can store multiple representations of the same concept
Build interface layer that displays/translates between representations
Train community members to author descriptions in their own frameworks
Preserve original descriptions without forcing translation/standardization

Pattern 6: Care Infrastructure

When to Use: When systems should embed relationship maintenance and accountability, not just efficiency

How It Works:

Systems are designed around relational maintenance (feedback loops, governance participation)
Decision-making includes space for deliberation, not just technical optimization
Accountability mechanisms are built in (audit trails, veto points, impact assessments)
Systems assume ongoing relationship with communities, not one-time transactions

Example:

OCAP infrastructure includes community governance participation
Te Hiku Papa Reo includes community language policy decisions
Mukurtu includes ongoing protocol management by communities

Implementation Steps:

Design explicit participation roles for communities (not just users/data subjects)
Build governance feedback loops (communities see what decisions are made, have input channels)
Implement accountability mechanisms (audit trails, veto points, consequence enforcement)
Include space for deliberation (not just automation)
Plan for ongoing relationship maintenance, not project handoff

Anti-Patterns: How Extraction Appears in Architecture

Anti-Pattern 1: Data Enclosure

Signature: All data flows into a central data warehouse; community has no copy, no audit trail, no control.

Extractive Markers:

One-way data pipeline: community → institution
Data duplication happens without consent tracking
Third-party access happens without community notification
Deletion is impossible or requires legal process

Relational Alternative:

Data resides in community systems; institutional access is mediated and audited
Communities have a real-time copy of all data about themselves
Third-party access requires explicit community approval and is tracked
Communities can request deletion; system deletes immediately

Example of Enclosure:

Biobank takes Indigenous blood samples, sends to central repository, communities lose access
University collects Indigenous stories, data enters institutional database, community has no insight into who uses it

Anti-Pattern 2: Algorithmic Opacity

Signature: Decisions affecting communities are made by algorithms that cannot be inspected, audited, or explained.

Extractive Markers:

Black box ML models determine resource allocation, research priorities, or access rules
Communities cannot see what data fed the model
Decision outputs are not explainable to affected communities
Algorithm is proprietary/closed-source

Relational Alternative:

Algorithms are interpretable or at least auditable by communities
Communities know what data is used and approve it
Communities can request explanations of specific decisions
Algorithm logic is transparent (open source or published)

Example of Opacity:

Institution uses ML to predict "research-worthy" Indigenous data without community input on model design
Predictive policing algorithms affect Indigenous communities but are closed to inspection

Anti-Pattern 3: Performative Sovereignty

Signature: Communities are consulted but have no real decision authority; their input is taken but not binding.

Extractive Markers:

"Community advisory boards" exist but recommendations are ignored
Communities are asked for permission but cannot refuse
Decision-making looks participatory but power remains with institution
Community concerns are documented but don't change outcomes

Relational Alternative:

Communities have binding veto authority (not advisory)
Communities can refuse data use; refusal halts projects
Decision-making is community-led, not institution-led
Community concerns trigger immediate operational changes

Example of Performance:

IRB consultation: Indigenous communities are asked to review research but IRB can override their objections
"Community engagement": Indigenous voices are collected in focus groups but don't influence product development

Anti-Pattern 4: Universal Solutionism

Signature: One system is imposed on all communities despite their different protocols, languages, and governance models.

Extractive Markers:

Systems force Indigenous knowledge into Western categories (e.g., Linnean taxonomy)
Communities cannot customize protocols for their specific context
Regional/cultural variation is treated as "edge cases" requiring workarounds
System design assumes all communities operate the same way

Relational Alternative:

Systems support multiple protocols, languages, epistemologies simultaneously
Communities can configure/customize system behavior for their context
Regional variation is built into the design, not bolted on
System design assumes diversity as normal

Example of Solutionism:

Forcing all Indigenous knowledge into a single controlled vocabulary
Assuming all communities organize data the same way (when protocols differ)

Anti-Pattern 5: Surveillance-as-Default

Signature: All community activity is tracked, aggregated, and sold/shared without community knowledge or benefit.

Extractive Markers:

Behavioral surplus harvesting (every interaction is data collected)
Aggregation across contexts (data from one community shared to others)
No audit trail visible to communities
"Terms of service" grant ownership of derived data to platform

Relational Alternative:

Data collection is explicit and bounded (only what is needed for stated purpose)
Communities approve what is tracked and how it is used
Full audit trail is visible and owned by community
Aggregation across communities requires multi-party consent

Example of Surveillance:

Health tracking app collects Indigenous health data, aggregates across communities, sells to pharmaceutical companies
Language learning platform tracks all word usage, trains commercial models without community consent

Anti-Pattern 6: Extractive Licensing

Signature: Once data is created, community loses all control; commercial entities can use it freely.

Extractive Markers:

Data is released under open licenses (CC-BY, public domain) without community consultation
Commercial entities can build derivative products (AI models, databases) without paying communities
License terms cannot be changed without legal action
No reciprocity or benefit-sharing mechanisms

Relational Alternative:

Communities choose license terms (can be restrictive for commercial use)
Commercial use requires explicit negotiation and benefit-sharing
License terms can evolve as relationships develop
Communities receive revenue from commercial derivatives

Example of Extraction:

Indigenous language corpus is released as "open data"; tech company uses it to train commercial speech recognition without paying community
Genomic data is deposited in public database; pharmaceutical company uses it for drug development without consulting Indigenous community

Veto Points & Community Control in Code

1. Constitutional Veto: Governance as Root Authority

What it means: Community governance body has ultimate authority; no technical system or external entity can override.

How to encode: ``` System architecture principle:

Community governance role is ROOT_AUTHORITY
All other roles (admin, operator, researcher) are subordinate
Cannot execute any critical operation (delete, export, share, publish) without signature from ROOT_AUTHORITY
ROOT_AUTHORITY can revoke any other role's permissions instantly ```

Implementation example:

All database operations require community governance approval or have automatically-applied restrictions
Admin panels show a "requires community approval" warning for sensitive operations
Multi-signature requirements (e.g., 3 of 5 community leaders must approve)

2. Classification Veto: T3 as Default

What it means: All data starts in maximum protection state (T3); reclassification to lower tiers requires explicit multi-party community approval.

How to encode: ``` When new data is ingested:

Default classification = T3 (Sovereign)
Metadata records classification reason and community decision timestamp
Changing classification triggers governance approval workflow
Downgrade from T3 → T2 requires 2 community leaders' approval + documented reasoning
Only community leaders can request classification change, not data stewards ```

Implementation example:

Database trigger on INSERT: if classification is null, set to T3
Classification change workflow in application: "Downgrade request" sends to community governance portal
Audit log: every classification change is timestamped with who approved it and why

3. Consent Veto: FPIC as Ongoing Middleware

What it means: Free, Prior, and Informed Consent is not a one-time event. It is an ongoing middleware that checks current consent state before every data operation.

How to encode: ``` Before every sensitive data operation (read, analyze, publish, share):

Check current consent status in consent layer
If consent is invalid or revoked, DENY operation
If consent is expiring (e.g., 30 days left), NOTIFY community and researcher
Log attempt (whether approved or denied)

Consent tokens:

Can be granted for limited duration (e.g., 1 year)
Can be revoked immediately
Specifies scope (which data, which research questions, which outputs)
Can be conditional (e.g., "only if results are shared with community") ```

Implementation example:

SmartContract or policy engine (e.g., ODRL) that evaluates consent before operations
Consent dashboard showing communities which projects have valid consent, what it covers, when it expires
Researchers see "consent required" errors if they try to access data without current FPIC

4. Digital Kill Switch: Immediate Revocation

What it means: Communities can halt all data access, invalidate all tokens, and trigger secure deletion with a single action.

How to encode: ``` Kill switch privilege:

Available to: Community governance body only (not researchers, not platform operators)
Effect: Instantaneous
1. All active access tokens are invalidated
2. Processing pipelines halt
3. API calls return 403 Forbidden
4. Deletion request is triggered (secure erasure)
Audit trail: Kill switch trigger is logged with timestamp and community authority signature
Recovery: Kill switch can only be lifted by same governance authority that activated it ```

Implementation example:

Community dashboard has prominent "REVOKE ALL ACCESS" button
Button triggers:
- JWT/OAuth token revocation cascade
- Pipeline pause signals sent to all running jobs
- Secure deletion initiated for derived data
- Email notification to all researchers with access
System cannot recover from kill switch without community re-enabling it

5. Research Ethics Veto: Protocol Gate

What it means: Research cannot proceed without community approval of research protocols, benefit-sharing arrangements, and output governance.

How to encode: ``` Research workflow:

Researcher submits:
- Research question and methods
- Data needed
- How results will be used
- Proposed benefit-sharing (funding, co-authorship, publication rights)
Community governance reviews and either:
- APPROVES (research proceeds)
- REQUESTS MODIFICATIONS (researcher revises)
- DENIES (research cannot use community data)
If approved, system tracks:
- Which data was accessed
- When results were published
- If benefit-sharing terms were met ```

Implementation example:

Research protocol management system with community governance workflow
Cannot generate data access token without approved protocol
Publication gate: results cannot be published until community is notified
Benefit-sharing enforcement: revenue from commercial publications is automatically split

6. AI/ML Prohibition Tiers: Categorical Refusal

What it means: Communities can categorically prohibit AI/ML training on certain data classes, not just limit it.

How to encode: ``` Data classification with AI/ML metadata:

T3 (Sovereign) data: Cannot be used for AI/ML training under ANY circumstances
- System architecture prevents T3 data from reaching training pipelines
- Attempts to train on T3 data trigger alerts and system blocks
T2 (Restricted) data: Can only be used for AI/ML with explicit community approval
T1/T0 (Limited/Open) data: Can be used for AI/ML per OCAP governance

AI/ML metadata:

Every AI model must declare: "Trained on [list of datasets]"
If any T3 data appears in training set, model is flagged as PROHIBITED
Community can audit model training logs ```

Implementation example:

ML pipeline includes data classification check before training
Cannot add T3 data to training set; system rejects it
Community dashboard shows all models trained on their data (transparency)
Communities can revoke permission for future model training on their data

Relational vs. Extractive Architecture: Comparison Framework

Decision Framework for Architects

When designing a system, ask these 10 questions to determine if it is relational or extractive:

Decision	Extractive System	Relational System
Who owns the data?	Institution/platform	Community (legally and technically encoded)
How is data classified by default?	Open/least restrictive	Sovereign/most protective (T3)
Who can revoke access?	Only through legal process	Community instantly (kill switch)
How is benefit-sharing enforced?	By contract (external to system)	Architecturally (revenue-sharing triggers, auto-payments)
Can communities see who accesses their data?	No / limited audit trail	Yes / full real-time audit dashboard
How are data decisions made?	Top-down (institution)	Bottom-up (community governance)
Can data be deleted?	Difficult/impossible	Community can delete instantly
Are multiple epistemologies supported?	No (single schema forced on all)	Yes (pluriversal interfaces)
Is consent ongoing?	One-time checkbox	Ongoing, revocable middleware
Who benefits from derivative uses?	Platform/commercial entities	Community (revenue-sharing, co-authorship)

Architectural Signatures of Each Approach

Extractive Architecture Signatures:

Centralized Data Warehouse: All data flows in; communities have no copy
One-Way Data Pipelines: Data extraction, not exchange
Invisible Access: No audit trail communities can see
Closed Algorithms: Decision logic is proprietary/unexplainable
Default Open: Data is assumed public unless explicitly restricted
Single Schema: All data forced into one classification system
One-Time Consent: "Accept terms" checkbox, no ongoing control
Locked-In Data: Difficult/impossible to retrieve or delete
Generic Access Control: Roles (admin/user) applied uniformly across contexts
Automated Extraction: Data collection and aggregation happens without human-in-the-loop

Relational Architecture Signatures:

Federated Data Residency: Data stays in community systems; external access is mediated
Bidirectional Flows: Communities get feedback, research results, insights back
Transparent Access: Full audit trails visible to community in real-time dashboards
Interpretable Decisions: Algorithms can be explained; communities understand why decisions are made
Default Restricted: Data is assumed protected unless explicitly opened by community
Pluriversal Schemas: Multiple classification systems coexist; epistemologies are respected
Ongoing Consent: Consent is revocable, time-limited, community-managed middleware
Retrievable Data: Communities can get copies and delete immediately
Contextual Access Control: Access rules model social relationships, not generic roles
Deliberative Governance: Data collection and use decisions include community participation