DP20 - Community Ownership
Patches and comments are scoped to the whole document family, not to a single revision. When you open a revision, highlights show what still applies to that revision body; anything anchored to text a later revision removed is listed as needing re-anchoring, and anything that can no longer be merged at all is marked obsolete. See all patches.
Comparing Revision 00 (original) with Revision 01. Struck-through text was removed; highlighted text was added.
# DP20 – Community Ownership
*The Conditions for Ownership That Can Be Exercised*
<!-- dp-local-version: 1.0 | standardized: 2026-07-27 -->
## 1. Purpose of This Draft
DP20 treats these signals as design requirements, not feedback to be addressed after failure.
## 9. Foresight and Failure Design
DP20 assumes ownership systems will be tested by capture attempts, economic pressure, and governance failure.
Common failure paths include:
- concentration of ownership among early or privileged actors - erosion of rights through informal overrides or hidden control layers - suppression of exit or fork pathways to preserve centralized power - divergence between formal ownership and actual value capture
DP20 requires designing safeguards in advance, including:
- transparent allocation and reallocation mechanisms - enforceable limits on concentrated control - clear and executable fork and exit procedures - public postmortems linking failures to structural changes
Failure is expected. Illegible failure is not.
Foresight in DP20 also means anticipating success. Ownership structures fail differently when they grow: a small cooperative can govern by conversation, while a large one cannot. DP20 therefore expects communities to plan the transitions in advance rather than discover them under stress.
Scale transitions that require pre-designed responses:
- **From informal to formal.** Founding trust does not survive membership growth. Charters, rosters, and decision records must exist before informal authority becomes contested. - **From volunteer to funded.** Introducing money into a volunteer commons reorders status. Compensation criteria and conflict-of-interest rules should be set before the first payment, not after the first grievance. - **From single zone to federation.** Ownership artifacts that assumed one community must survive contact with many (DP7, DP8). Cross-zone recognition rules should be written while stakes are still low. - **From founders to successors.** Every founding cohort eventually leaves. Succession, key rotation, and archive custody are ownership functions, not administrative details. - **From growth to decline.** Communities shrink. Dissolution with dignity, including asset disposition and memory preservation, is part of ownership design (DP22).
Pre-mortem practice DP20 expects:
- name the three most likely capture vectors for this specific community, and the control that would detect each - state in advance what evidence would indicate that ownership has become theater - define the trigger conditions under which a fork is considered legitimate rather than hostile - rehearse an exit at least once, so that portability claims are tested rather than asserted - record what the community would refuse even if it were profitable, and where that refusal is written down
Failure design is not pessimism. It is the difference between a community that can survive its own mistakes and one that discovers its structure only when it breaks.
## 10. Knowledge Graph Stewardship
Communities do not only own spaces, funds, and governance artifacts. They also produce the semantic substrate that makes shared understanding possible: vocabularies, taxonomies, tags, annotations, curated links, corrections, glossaries, and the relationships that connect them. This substrate is a knowledge graph, whether or not it is called one.
Knowledge graphs are unusually vulnerable to quiet expropriation. They are built incrementally by many people, they carry no obvious authorship, and their value appears only in aggregate. A platform can absorb decades of community curation without any single act that looks like a taking.
DP20 therefore treats collective knowledge structures as ownable, governable, and forkable assets.
### 10.1 What is being stewarded
- **Vocabularies and ontologies:** the terms a community uses, their definitions, and their relationships - **Classification schemes:** categories, tags, and topic hierarchies, including their edge cases and exclusions - **Annotations and overlays:** notes, corrections, context, and interpretive layers attached to shared artifacts - **Curation and linkage:** which sources are considered relevant, credible, or connected, and by whom - **Provenance records:** who asserted what, when, and on what basis (DP15) - **Glossary and translation layers:** cross-language term mappings and contested terminology (DP23) - **Governance memory:** the record of how definitions changed and why (DP22)
### 10.2 Stewardship obligations
Ownership of a knowledge graph is custodial rather than proprietary. A community holding one accepts obligations:
- maintain provenance so that assertions can be traced to their source and revisited - keep definitions versioned, so that meaning drift is visible rather than silent - credit curation labor, including the unglamorous work of merging duplicates and fixing broken relationships - resolve conflicting assertions through published process rather than by last-writer-wins - preserve minority and contested interpretations instead of collapsing them into a single canonical entry - publish the license and reuse terms under which the graph may be consumed - retain the ability to correct or attenuate entries about people (DP4, DP18)
### 10.3 Rights the community must hold
- **Export rights.** The graph must be extractable in an open, documented form, including relationships and provenance, not only flattened content. - **Fork rights.** A community that diverges must be able to take its semantic layer with it and continue evolving it independently (DP7). - **Consent rights over derived use.** Bulk consumption for model training, resale, or downstream inference is a collective decision, not a default permission (DP4, DP11–DP13). - **Attribution rights.** Systems that build on a community graph must disclose that dependency. - **Refusal rights.** Communities may decline to encode knowledge that is sacred, protected, or dangerous to expose, and that refusal must be recordable rather than treated as a data gap.
### 10.4 Failure modes
- **Curation extraction:** a platform monetizes or trains on community-built structure while contributing nothing to its maintenance - **Ontology capture:** a well-resourced actor gains effective control of definitions, shaping what the community can express - **Schema lock-in:** the graph is technically exportable but semantically meaningless outside its original tooling - **Silent redefinition:** terms change meaning without versioning, invalidating past assertions retroactively - **Curation debt:** maintenance is unfunded, quality degrades, and the graph becomes unreliable while still being trusted - **Consent bypass through derivation:** embeddings, summaries, or inferred relationships are treated as new works exempt from community terms
**Example:** A community maintains a topic taxonomy used by several tools. Its charter states that the taxonomy is exported monthly in an open format, that model training on it requires a governance vote, that three stewards are compensated for maintenance, and that a fork inherits full provenance history.
**Why this matters:** If communities own their spaces but not their semantics, someone else still decides how their knowledge can be described, found, and used.
## 11. Relationship to Other Desirable Properties
DP20 anchors ownership within the broader meta-layer system.
- DP3 defines how governance evolves under ownership - DP4 constrains how collectively generated data can be used - DP5–DP7 enable portability of identity, assets, and ownership artifacts - DP6 and DP9 determine how value flows and incentives interact with ownership - DP12 ensures ownership-linked governance can execute in practice - DP15 ensures ownership claims and actions are provable - DP17 ensures ownership structures can sustain themselves financially - DP18–DP19 provide the participation and reputation inputs that mature into ownership
DP20 binds these properties into a coherent model of collective power.
DP20 also depends on the memory and language properties. DP22 preserves the governance lineage that makes ownership history legible over time, and DP23 ensures that ownership terms, charters, and votes remain accessible to members who do not share a dominant language. Ownership that cannot be read by its own members is ownership in name only.
## 9.12. Non-Goals and Explicit Boundaries
DP20 does not:
- require all systems to be collectively owned - eliminate private enterprise or hybrid ownership models - guarantee equal distribution of value or influence - remove the need for legal structures and compliance
DP20 defines the conditions under which ownership claims are legitimate and enforceable. It does not prescribe a single model.
The following boundaries are stated explicitly, because "community ownership" is a phrase frequently used to describe its opposite.
**DP20 does not mandate tokens.** Tokenization is one instrument among many. Cooperatives, trusts, associations, stewardship councils, and non-transferable membership rights are equally admissible. A token that grants no decision rights is not ownership regardless of market depth.
**DP20 does not require blockchains.** Verifiable records may be maintained through several means. What matters is that ownership history is tamper-evident and independently checkable (DP15), not which ledger technology produces that property.
**DP20 does not guarantee profit or surplus.** Many commons will run at cost. DP20 requires that whatever surplus exists be visible and allocated under published rules, not that surplus be produced.
**DP20 does not equate ownership with unanimity.** Collective ownership includes the authority to decide over objection, bounded by minority protections and exit rights. Consensus is a method, not a requirement of legitimacy.
**DP20 does not abolish operators.** Communities may delegate operational authority to staff, vendors, or foundations. Delegation is legitimate when it is scoped, revocable, and recorded.
**DP20 does not make forking costless.** It requires that forking be possible with continuity of identity, memory, and economic position. It does not promise that forking will be painless or that both branches will thrive.
**DP20 does not override rights of individuals.** Collective ownership of a space does not confer collective ownership of its members' data, attention, or labor. Individual sovereignty under DP2 and DP4 constrains what a community may decide.
**DP20 does not resolve legal form.** Jurisdictional recognition of collective entities varies widely and will remain a constraint. DP20 requires honesty about the gap between digital rights bundles and legal enforceability rather than pretending the gap does not exist.
**DP20 does not treat membership as property.** Participation rights may be non-transferable by design. Preventing the sale of membership is compatible with, and often necessary for, durable community ownership.
## 10.13. Minimum DP20 Alignment (Non-Normative)
Minimum alignment defines the threshold where ownership is **real, enforceable, and not misleading**.
Systems that omit execution, auditability, or exit MUST NOT be considered aligned.
The following statements describe what those conditions look like in practice. They are non-normative and are offered as an assessment aid rather than a conformance test.
### 13.1 Published rights bundle
There is a charter or equivalent document stating who the members are, what decisions they control, what share of surplus they hold, what audit rights exist, and how the charter itself may be amended.
### 13.2 Legible membership
Membership criteria, current membership, and the process for joining and leaving are visible to members. Informal power that operates outside the roster is identified rather than tolerated silently.
### 13.3 Binding decision surface
At least one class of consequential decision is actually decided by members, with a record showing the question, the participation, the outcome, and its execution (DP12).
### 13.4 Surplus and cost visibility
Members can see revenue, costs, reserves, and allocation for the current period, at a granularity sufficient to detect extraction (DP17).
### 13.5 Exercisable exit
Export of identity, memory, relationships, and ownership artifacts is documented, tested, and available without permission from an operator. Fork procedures are written before they are needed.
### 13.6 Anti-capture controls
There are published limits on concentrated control, including caps, quorum rules, rotation, or veto protections, and a record of when those controls were invoked.
### 13.7 Collective data authority
Uses of collectively generated data, including derived and aggregated forms, require a member-facing authorization pathway rather than a terms-of-service default (DP4).
### 13.8 Steward accountability
Delegated roles have scope, term, compensation, conflict-of-interest disclosure, and a removal procedure that members can initiate.
### 13.9 Continuity plan
Succession, key custody, archive stewardship, and dissolution terms exist in writing, so that the community can survive the departure of any individual.
## 11.14. Open Questions and Future Work
Key open questions include:
- how to design ownership models that function across jurisdictions - how to balance tokenized and non-tokenized ownership structures - how to maintain privacy while supporting interoperable ownership credentials (DP4) - how to protect minority voices without blocking collective action - how to measure contribution across visible and invisible labor (care, moderation, coordination) - how to handle liability for collective decisions across legal systems - how AI agents participate in ownership structures, if at all (DP11–DP13)
These questions reflect the boundary between social legitimacy and technical implementation.
## 12. Relationship to Other Desirable Properties
DP20 anchors ownership within the broader meta-layer system.
- DP3 defines how governance evolves under ownership - DP4 constrains how collectively generated data can be used - DP5–DP7 enable portability of identity, assets, and ownership artifacts - DP6 and DP9 determine how value flows and incentives interact with ownership - DP12 ensures ownership-linked governance can execute in practice - DP15 ensures ownership claims and actions are provable - DP17 ensures ownership structures can sustain themselves financially - DP18–DP19 provide the participation and reputation inputs that mature into ownership
DP20 binds these properties into a coherent model of collective power.
## 13. Foresight and Failure Design
DP20 assumes ownership systems will be tested by capture attempts, economic pressure, and governance failure.
Common failure paths include:
- concentration of ownership among early or privileged actors - erosion of rights through informal overrides or hidden control layers - suppression of exit or fork pathways to preserve centralized power - divergence between formal ownership and actual value capture
DP20 requires designing safeguards in advance, including:
- transparent allocation and reallocation mechanisms - enforceable limits on concentrated control - clear and executable fork and exit procedures - public postmortems linking failures to structural changes
Failure is expected. Illegible failure is not.
Further questions raised by knowledge graph stewardship and scale transitions:
- what minimum schema should describe an ownership object so that it remains meaningful across zones and tools - how should a fork inherit provenance, reputation, and knowledge graph history without importing the disputes that caused the split - what licensing model best protects community-curated semantic layers from extraction while remaining genuinely open - how should consent for model training on community knowledge be expressed, revoked, and verified downstream - how should compensation for invisible maintenance labor be assessed without turning care work into a metric to be gamed (DP18) - what governance form allows a community to refuse a lucrative offer without that refusal becoming a liability for its stewards - how should dissolution allocate assets, archives, and namespaces when members disagree about legitimate succession (DP5, DP22) - how can ownership rights remain intelligible to members across languages and literacy levels (DP23)
## 14.15. Path Toward ML-RFC
Advancing DP20 toward ML-RFC requires:
- standardizing ownership object and receipt formats - developing reference implementations of community-owned systems with open accounting - aligning ownership models with interoperability and identity standards - testing fork and exit mechanisms in real communities - integrating legal and cooperative expertise into design processes
Progress should be demonstrated through functioning systems, not only conceptual agreement.
## 15.16. Closing Orientation
DP20 is where the meta-layer turns participation into power.
Published: 2026-08-08
Pages: 9 | Words: 4441
What changed:
Synced from the book local rail (content/local/dpN.md), which carries the current working text for this chapter: expanded sections, renamed and renumbered headings, and editorial cleanup since the last revision. Published as a new revision so prior revisions stay intact.
Published: 2026-08-05
Pages: 9 | Words: 4426
What changed:
Numbered section headings and cross-reference fixes for collaborative review
Published: 2026-08-04
Pages: 9 | Words: 4419
What changed:
Synced from the book local rail (content/local/dpN.md), which carries the current working text for this chapter: expanded sections, renamed and renumbered headings, and editorial cleanup since the last revision. Published as a new revision so prior revisions stay intact.