Decolonial Design Patterns & Relational Architecture

Research Agent: Design Justice & Decolonial Tech Movements Date: 2026-03-05 Purpose: Identify design patterns, frameworks, and architectural principles from decolonial design movements that foreground relationships over extraction — informing what relational systems actually look like for the IAIP Ceremonial Technology Design skill.

Key Findings

1. Design Justice (Costanza-Chock, 2020) provides 10 network principles that redefine the designer as facilitator, center impacted communities in decision-making, and demand that outcomes remain under community control. The framework explicitly names the "matrix of domination" (white supremacy, heteropatriarchy, capitalism, colonialism) as forces encoded in default design. (Costanza-Chock, "Design Justice," MIT Press 2020; Design Justice Network Principles)

2. OCAP® Principles (First Nations Information Governance Centre) — Ownership, Control, Access, Possession — constitute the most operationally mature Indigenous data sovereignty framework. They translate directly into technical architecture: community-operated data centers, consent management APIs, data localization requirements, and governance-layer access controls. (FNIGC, fnigc.ca/ocap-training)

3. CARE Principles for Indigenous Data Governance (Global Indigenous Data Alliance) — Collective Benefit, Authority to Control, Responsibility, Ethics — complement FAIR principles by centering people and purpose rather than data interoperability alone. They expose how "open data" can be extractive when it ignores power asymmetries. (Carroll et al., "The CARE Principles for Indigenous Data Governance," Data Science Journal, 2020; GIDA, gida-global.org/care)

4. Local Contexts TK Labels are a functioning technology implementation of Indigenous data governance — customizable metadata tags that embed cultural protocols, provenance, and access conditions directly into digital repositories. They are operationally deployed in museums, scientific databases, and heritage collections via an API-enabled Hub. (Local Contexts, localcontexts.org)

5. Arturo Escobar's "Designs for the Pluriverse" (2018) theorizes autonomous design rooted in relational ontology — where entities exist primarily through relationships, not as isolated objects. His concept of "radical interdependence" reframes autonomy not as isolation but as being deeply grounded in specific territories, knowledges, and relations. (Escobar, "Designs for the Pluriverse," Duke University Press, 2018)

6. Ruha Benjamin's "Race After Technology" (2019) names the "New Jim Code" — how discriminatory practices are encoded into seemingly neutral technical systems. She advocates abolitionist tools that critically interrogate tech while co-designing with marginalized communities. The Ida B. Wells Just Data Lab operationalizes this. (Benjamin, "Race After Technology," Polity, 2019)

7. Platform Cooperativism (Trebor Scholz) provides concrete architectural alternatives to extractive platforms: worker-owned governance, algorithmic transparency, democratic oversight of platform rules, multi-stakeholder co-ops. Over 1 million workers now participate globally. (Scholz, "Platform Cooperativism," Rosa Luxemburg Stiftung; platform.coop)

8. Care Ethics in Technology Design shifts system architecture toward relational autonomy — co-decision interfaces, adaptive consent models, and transparent AI reasoning that centers ongoing negotiation among stakeholders rather than one-time consent. (Oxford AI Ethics, "Care, Autonomy, and Technology Workshop Report," 2024)

9. Federated/Decentralized Architecture (Mastodon/Fediverse) embodies data sovereignty at the infrastructure level: community-governed instances, no centralized surveillance, data portability, chronological timelines (rejecting engagement-maximizing algorithms), and community-defined moderation. (ActivityPub protocol; Mastodon, joinmastodon.org)

10. Detroit Community Technology Project / Equitable Internet Initiative demonstrates community-owned network infrastructure: neighborhood-governed wireless networks, resident-trained Digital Stewards, $10/month access, privacy-by-design governance, and disaster resilience features — a model of infrastructure as relationship. (DCTP, detroitcommunitytech.org/eii)

Design Justice Framework → Architecture Decisions

The Design Justice Network's 10 Principles translate to architecture as follows:

Key Insight: Design Justice does not merely add "community input" — it restructures who holds architectural authority. The community is not a user; the community is a co-architect with governance power.

Relational Architecture Patterns

Pattern 1: Data Sovereignty Layer (OCAP®/CARE)

Problem: Data about communities flows to external systems without community control. Solution: An architectural layer that enforces:

• Ownership registry: Every data object has a declared community owner.
• Consent API: Granular, revocable, ongoing consent management — not one-time click-through.
• Possession enforcement: Data physically resides where the community determines (data localization).
• Access control with cultural protocols: Access governed by community-defined rules, not just role-based access control (RBAC). The Local Contexts TK Labels provide a working model.
• Benefit accounting: Any use of data must demonstrate collective benefit back to the originating community.

Real implementation: FNIGC-compliant data centers; Local Contexts Hub API integration.

Pattern 2: Federated Governance Architecture

Problem: Centralized platforms impose uniform rules and extract value to a single entity. Solution: Federated systems where:

• Each community instance is self-governing (own moderation, own rules, own data policies).
• Inter-instance communication via open protocols (cf. ActivityPub).
• No single point of surveillance or control.
• Community-defined boundaries: instances choose who to federate with and who to block.
• Governance is composable — communities can adopt, adapt, or reject governance modules.

Real implementation: Mastodon/Fediverse; Decidim participatory democracy platform (modular Ruby on Rails architecture with "participatory spaces" and composable governance components).

Pattern 3: Reciprocity Enforcement Layer

Problem: Open systems are exploited by free-riders who extract without contributing. Solution: Architectural mechanisms that encode reciprocity:

• Reciprocal licensing: Code contributions required for commercial use (cf. Reciprocal Public License 1.5).
• Benefit-sharing protocols: When a system generates value from community data/knowledge, a defined portion returns to the community.
• Contribution tracking: System tracks contributions and ensures balanced exchange over time.
• Exit rights with data portability: Communities can leave with their data intact — the opposite of lock-in.
• Relational accounting: Not just financial — tracks knowledge contributions, governance participation, care labor.

Real implementation: Platform cooperatives (Up&Go, CoopCycle); Social.coop (cooperative Mastodon instance); Reciprocal Public License.

Pattern 4: Community Veto Gate / Consent Architecture

Problem: "Consultation" is performative — communities advise but don't decide. Solution: Governance gates embedded in technical workflows:

• Deployment requires community approval — not just notification.
• Adaptive consent: Consent is ongoing, revocable, and contextual — not a one-time agreement.
• Harm threshold triggers: If system metrics cross community-defined harm thresholds, automatic pause.
• Community override: Community governance body can halt, modify, or redirect system behavior.

Real implementation: Decidim's participatory processes with citizen proposals, amendments, and accountability follow-up; OCAP®-compliant research platforms with community review gates.

Pattern 5: Pluriversal Interface Layer

Problem: Systems impose a single ontology (Western, quantitative, individualist). Solution: Architecture that supports multiple ways of knowing simultaneously:

• Multi-ontological data models: Support narrative, relational, seasonal, and ceremonial data alongside quantitative metrics.
• Cultural protocol metadata: Every data object can carry cultural context (cf. TK Labels).
• Translation, not flattening: Interfaces that mediate between knowledge systems without reducing one to the other.
• Community-defined categories: Taxonomies and classifications emerge from communities, not imposed by designers.

Real implementation: Local Contexts TK/BC Labels with customizable metadata; Indigenous language revitalization platforms.

Pattern 6: Care Infrastructure Pattern

Problem: Systems optimize for efficiency, ignoring the relational labor of maintenance. Solution: Architecture that centers ongoing care:

• Stewardship roles as system actors: Digital Stewards (cf. DCTP model) — trained community members who maintain and adapt infrastructure.
• Relational health metrics: System monitors relationship quality, not just uptime.
• Adaptive interfaces: Systems accommodate changing needs (especially for vulnerable populations).
• Co-decision interfaces: Multiple stakeholders can input perspectives and negotiate.
• Transparent reasoning: System logic is visible and contestable by all relational actors.

Real implementation: Detroit Community Technology Project's Digital Stewards program; care ethics-informed health technology design.

Anti-Patterns (Extractive Design)

These are what relational architecture explicitly resists:

Anti-Pattern 1: Data Enclosure

What it looks like: Platform collects user/community data into proprietary silos. Users cannot export, delete, or govern their data. Value flows one direction — from community to corporation. Architectural signature: Centralized databases, no export APIs, Terms of Service that claim perpetual license to user content, no community governance layer. Who benefits: Platform owners, advertisers, data brokers. Relational alternative: Data Sovereignty Layer (Pattern 1).

Anti-Pattern 2: Algorithmic Opacity ("Black Box")

What it looks like: Decisions affecting communities are made by opaque algorithms. No explanation, no contestation, no community input into algorithmic design. Architectural signature: Proprietary ML models, no explainability layer, A/B testing on users without consent, engagement-maximizing optimization. Who benefits: Those who control the algorithm. Relational alternative: Transparent reasoning + Community Veto Gate (Patterns 4 & 5).

Anti-Pattern 3: Consultation Theater

What it looks like: "Community engagement" as PR. Surveys and focus groups that generate no binding commitments. Advisory boards with no authority. Architectural signature: Feedback forms that feed a black hole. No governance integration. Community input is optional and non-binding. No traceability from input to decision. Who benefits: Organizations seeking legitimacy without sharing power. Relational alternative: Community Veto Gate with traceable decision pathways (Pattern 4).

Anti-Pattern 4: Universal Solutionism

What it looks like: One platform for all contexts. Assumes a single ontology, a single user model, a single governance structure. "Scale" as the supreme value. Architectural signature: Monolithic architecture, hardcoded taxonomies, no localization beyond language translation, no governance flexibility. Who benefits: Those whose worldview is encoded as "default." Relational alternative: Pluriversal Interface Layer + Federated Governance (Patterns 2 & 5).

Anti-Pattern 5: Planned Dependency

What it looks like: Systems designed to create lock-in. Switching costs are maximized. Communities cannot leave without losing everything. Architectural signature: Proprietary data formats, no export, no interoperability, subscription models that hold data hostage. Who benefits: Vendors. Relational alternative: Exit rights, data portability, open protocols (Pattern 3).

Anti-Pattern 6: Surveillance as Default

What it looks like: Opt-out data collection. Behavioral tracking as the business model. User data converted into "prediction products" (Zuboff's "surveillance capitalism"). Architectural signature: Pervasive telemetry, third-party trackers, dark patterns in privacy settings, centralized logging of all user activity. Who benefits: Advertisers, data brokers, states. Relational alternative: Federated architecture with community-defined data policies (Pattern 2).

Real Projects Using These Patterns

1. Decidim — Participatory Democracy Platform (Barcelona)

• What: Open-source (AGPLv3) participatory democracy platform, built on Ruby on Rails with modular architecture.
• Relational patterns implemented: Federated Governance, Community Veto Gate, Pluriversal Interface.
• Architecture: Modular "participatory spaces" (processes, assemblies, initiatives) composed of pluggable "components" (proposals, debates, budgets, accountability). API-enabled. Governed by a multi-stakeholder association (Decidim Free Software Association) with General Assemblies and thematic committees.
• Scale: 30+ countries, thousands of deployments.
• Key insight: The governance of the platform mirrors the governance the platform enables. The platform for democratic participation is itself democratically governed.
• URL: https://github.com/decidim/decidim | https://decidim.org

2. Local Contexts TK Labels — Indigenous Data Governance Technology

• What: Digital metadata infrastructure for embedding Indigenous cultural protocols into data systems.
• Relational patterns implemented: Data Sovereignty Layer, Pluriversal Interface, Community Veto Gate.
• Architecture: Web-based Hub with API integration. Indigenous communities create Community Accounts, develop customized TK and Biocultural (BC) Labels, and apply them to specific digital objects. Institutions use Notices to acknowledge Indigenous interests. Authority to apply Labels rests exclusively with Indigenous communities.
• Key insight: Governance is encoded in metadata. Cultural protocols become machine-readable, visible to anyone accessing the digital object, and backed by community authority.
• URL: https://localcontexts.org

3. Detroit Community Technology Project — Equitable Internet Initiative

• What: Community-owned, neighborhood-governed wireless internet networks in Detroit.
• Relational patterns implemented: Care Infrastructure, Federated Governance, Reciprocity Enforcement.
• Architecture: Mesh wireless + fiber networks. Neighborhood organizations (Grace in Action, Church of the Messiah, etc.) govern their local networks. Digital Stewards program trains residents in wireless engineering and community organizing. $10/month, contract-free. Privacy and consent embedded in governance practices.
• Key insight: Infrastructure is relationship. The network is maintained by people who live in the neighborhood, accountable to their neighbors, trained as both technical and relational stewards.
• URL: https://detroitcommunitytech.org/eii

4. Platform Cooperatives — Worker-Owned Digital Infrastructure

• What: Digital platforms owned and governed democratically by their workers.
• Relational patterns implemented: Reciprocity Enforcement, Federated Governance, Care Infrastructure.
• Examples:
  • Up&Go (NYC): Cleaning professionals' cooperative platform.
  • CoopCycle (Europe): Bike delivery workers' cooperative platform.
  • Social.coop: Cooperative Mastodon instance.
• Key insight: Algorithmic decisions are subject to democratic oversight. Platform rules, payment structures, and reputation systems are open to member scrutiny and revision.
• URL: https://platform.coop

Theoretical Foundations: A Synthesis

The patterns above draw from distinct but convergent intellectual traditions:

What "Reciprocity" Means in Code

This question — central to the IAIP Ceremonial Technology skill — deserves explicit treatment:

Reciprocity is not a transaction. It is not "I give data, you give service." That is exchange. Reciprocity in relational/Indigenous thought is an ongoing obligation to maintain relationship balance.

In code, reciprocity manifests as:

1. Contribution tracking that includes invisible labor: Not just git commits — but governance participation, care labor, knowledge sharing, mentorship. A system that only tracks code contributions reproduces the extractive valuation of "productive" work.

2. Benefit-return protocols: When a system derives value from a community's data, knowledge, or participation, architectural mechanisms automatically return defined benefits. Not voluntarily. Structurally.

3. Reciprocal licensing: The Reciprocal Public License (RPL) requires that derivative works return contributions to the commons. This is reciprocity in licensing architecture.

4. Exit rights as reciprocity's test: If a community cannot leave a system with their data and relationships intact, there is no reciprocity — only capture. Data portability is a minimum condition for relational integrity.

5. Ongoing consent as relational maintenance: Consent is not a one-time checkbox. It is the continuous practice of maintaining the relationship. Adaptive consent architectures (revocable, contextual, evolving) embody this.

6. The system asks before it takes: Every data access, every analysis, every use of community knowledge triggers a governance check. The default is closed (community must open), not open (community must close). This inverts the extractive default.

Sources

Primary Academic Works

1. Costanza-Chock, Sasha. Design Justice: Community-Led Practices to Build the Worlds We Need. MIT Press, 2020. https://designjustice.mitpress.mit.edu/
2. Benjamin, Ruha. Race After Technology: Abolitionist Tools for the New Jim Code. Polity, 2019.
3. Escobar, Arturo. Designs for the Pluriverse: Radical Interdependence, Autonomy, and the Making of Worlds. Duke University Press, 2018.
4. Scholz, Trebor. "Platform Cooperativism: Challenging the Corporate Sharing Economy." Rosa Luxemburg Stiftung, 2016. https://rosalux.nyc/wp-content/uploads/2020/11/RLS-NYC_platformcoop.pdf
5. Scholz, Trebor. Own This! How Platform Cooperatives Help Workers Build a Democratic Internet. Verso, 2023.
6. Carroll, Stephanie Russo, et al. "The CARE Principles for Indigenous Data Governance." Data Science Journal 19, no. 1 (2020). https://datascience.codata.org/articles/dsj-2020-043
7. Couldry, Nick, and Ulises Mejias. The Costs of Connection: How Data Is Colonizing Human Life and Appropriating It for Capitalism. Stanford University Press, 2019.
8. Zuboff, Shoshana. The Age of Surveillance Capitalism. PublicAffairs, 2019.

Frameworks & Principles

9. Design Justice Network Principles. https://designjustice.org/read-the-principles
10. FNIGC OCAP® Principles. https://fnigc.ca/ocap-training/
11. CARE Principles for Indigenous Data Governance (GIDA). https://www.gida-global.org/care
12. Local Contexts TK Labels. https://localcontexts.org/labels/traditional-knowledge-labels/
13. CARE Principles — Australian Research Data Commons. https://ardc.edu.au/resource/the-care-principles/

Projects & Platforms

14. Decidim — Participatory Democracy Framework. https://github.com/decidim/decidim
15. Detroit Community Technology Project — Equitable Internet Initiative. https://detroitcommunitytech.org/eii
16. Platform Cooperativism Consortium. https://platform.coop
17. Mastodon / Social Sovereignty. https://blog.joinmastodon.org/2025/12/the-world-needs-social-sovereignty/
18. Social.coop — Cooperative Mastodon Instance. https://social.coop
19. Local Contexts Hub. https://localcontexts.org

Academic Papers & Reports

20. "Decolonizing Philosophy of Technology: Learning from Bottom-Up and Top-Down Approaches to Decolonial Technical Design." Philosophy & Technology (2021). https://link.springer.com/article/10.1007/s13347-021-00489-w
21. "Towards Pluriversality: Decolonising Design Research and Practices." CoDesign (2024). https://www.tandfonline.com/doi/pdf/10.1080/15710882.2024.2379704
22. "Pluriversal Technologies: A Decolonial Typology of Knowledge." Research Policy (2026). https://www.sciencedirect.com/science/article/pii/S0048733326000491
23. "Proactive Solutions in Implementing Tribal Digital Sovereignty." ASU American Indian Policy Institute (2026). https://aipi.asu.edu/sites/g/files/litvpz4546/files/2026-02/05_FINAL%2B2-2-26%2B04_Proactive%2BSolutions_Final%20%281%29.pdf
24. Oxford AI Ethics. "Care, Autonomy, and Technology Workshop Report." 2024. https://www.oxford-aiethics.ox.ac.uk/sites/default/files/2024-01/Care%20Autonomy%20and%20Technology%20Workshop%20Report%20-%20EH%2008-01-24.pdf
25. "Digital Colonialism and the Data Commons." 3CL Foundation. https://www.3cl.org/digital-colonialism-and-the-data-commons/
26. "Seeking to Unlearn Colonial Patterns in Systems Change." RSD Symposium (2024). https://rsdsymposium.org/wp-content/uploads/2024/07/Seeking-to-Unlearn-Colonial-Patterns-in-Systems-Change.pdf
27. Ada Lovelace Institute. "Working with the CARE Principles: Operationalising Indigenous Data Governance." https://www.adalovelaceinstitute.org/blog/care-principles-operationalising-indigenous-data-governance/
28. Reciprocal Public License 1.5 Analysis. https://dev.to/zhangwei42/unveiling-reciprocal-public-license-15-a-deep-dive-into-fair-code-open-source-sustainability-10k5
29. "Cooperatives and the Digital Commons: Governance, Sustainability, and Shared Infrastructure." Platform.coop. https://platform.coop/blog/cooperatives-and-the-digital-commons-governance-sustainability-and-shared-infrastructure/

This research was conducted for the IAIP Ceremonial Technology Design skill development, specifically to ground the skill's architectural assessment capabilities in concrete decolonial design patterns rather than abstract philosophy alone.