Revisions – ML-Draft-015

DP8 - Meta-communities

Back to Draft Comments Patches History

Revision History

0 patches on this document

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.

What changed between revisions

Comparing Revision 00 (original) with Revision 01. Struck-through text was removed; highlighted text was added.

95 paragraphs added 29 paragraphs removed 10 paragraphs rewritten +91 / −151 characters inside rewritten paragraphs
  1. Removed

    # **DP8: Community-Defined Participation & Governance Zones**

  2. Added

    # DP8 – Collaborative Environment and Meta-Communities

  3. Added

    *The Meta-Layer supports real-time collaboration that travels across the web — so your people are always close.*

  4. Added

    <!-- dp-local-version: 1.0 | standardized: 2026-07-27 -->

  5. Rewritten

    ## **1. Purpose of This Draft**Draft

  6. This draft articulates Desirable Property 8 (DP8) as the condition under which communities can **define, enforce, and evolve participation and governance at the interface layer of the Meta-Layer**.

  7. DP8 establishes that governance is not inherited from platforms, but constructed by communities operating within zones. It defines how participation, influence, and intelligence are structured so that trust remains contextual, enforceable, and resistant to manipulation.

  8. DP8 is not moderation. It is the **system-level design of environments in which interaction occurs**.

  9. Rewritten

    ## **2. Problem Statement**Statement

  10. On today’s web, participation and governance are platform-defined:

  11. 3 unchanged paragraphs
  12. DP8 addresses this by enabling communities to define **zone-specific governance systems** that operate at the interface layer and persist across the web.

  13. Added

    ## Threats and Failure Modes

  14. Added

    DP8 assumes adversaries will combine **identity (DP1), agency (DP2), data flows (DP4), governance (DP8), and incentives (DP9)**. Systems MUST be robust to **multi-vector, cross-zone attacks** and degrade safely.

  15. Added

    ### 3.0 Security and Adversarial Failure Modes (Index)

  16. Added

    DP8 names its failure modes inline throughout the sections that follow, because each mechanism fails in a specific way. The list below indexes that vocabulary so it can be tested, monitored, and referenced as a set.

  17. Added

    **Governance that does not bind**

  18. Added

    - **phantom governance**: rules exist but do not change visibility, amplification, or access - **declarative governance**: governance artifacts are published but not machine-enforceable - **governance stripping**: constraints are lost when content or participants cross a boundary - **module bypass**: a governance module influences outcomes without passing enforcement checks

  19. Added

    **Context and continuity failures**

  20. Added

    - **context collapse**: rules carry silently across zones that do not share norms or risk - **governance fragmentation**: state does not persist across pages, sessions, or systems - **zone conflict ambiguity**: overlapping rules resolve non-deterministically - **interop deception**: transfers claim preservation of governance that did not survive - **semantic mismatch**: signals are reinterpreted incorrectly across implementations

  21. Added

    **Participation and influence failures**

  22. Added

    - **tier gaming** and **fast-track escalation**: influence accrues without verifiable contribution - **privilege ossification**: roles never decay, entrenching early participants - **amplification spoofing**: automation or sybil identities drive high-impact reach - **reputation laundering**: signals are reshaped across contexts to manufacture trust - **cross-zone escalation**: standing in one zone confers illegitimate power in another - **throughput abuse**: volume substitutes for trust

  23. Added

    **Automation failures**

  24. Added

    - **AI governance bypass**: agents act outside zone-defined constraints - **identity masking** and **attribution gaps**: AI is indistinguishable from humans, or unattributable - **scope creep** and **irrevocable delegation**: delegated authority expands or cannot be withdrawn - **automation overrun**: agent actions are neither interruptible nor reversible - **consent bypass via pipelines**: data or inference constraints are lost between stages

  25. Added

    **Systemic failures**

  26. Added

    - **governance capture**: coordinated influence or opaque concentration of decision power - **brigading**: coordinated surges that overwhelm legitimate participation - **composed attack success**: individually mitigated vectors succeed in combination - **perverse incentives**: abuse is profitable, funding further attacks - **fail-open amplification**: under load or uncertainty, systems default to permissive behavior - **governance opacity** and **silent rule drift**: decisions and changes cannot be reconstructed - **governance rigidity**: communities cannot evolve or fork their governance model

  27. Added

    **Why this matters:** These are not incident categories to be triaged after the fact. Each names a condition that can be monitored continuously, and each has a corresponding structural condition elsewhere in DP8.

  28. Added

    ### **3.1 Threat Classes (Extended)**

  29. Added

    - **Sybil Attacks**: many identities controlled by few actors - **Brigading**: coordinated surges to influence outcomes - **Governance Capture**: concentration of power via roles or opaque processes - **Reputation Laundering**: reshaping signals across contexts to gain undue trust - **AI Amplification**: automated agents scaling influence beyond constraints - **Cross-Zone Escalation**: importing status or signals to bypass local rules

  30. Added

    ### **3.2 Composed (Multi-Vector) Attacks**

  31. Added

    Adversaries may combine: - AI agents + human click-farms - identity cycling + cross-zone escalation - incentive exploits (rewards) + feedback loops - data laundering (DP4) + reputation reuse (DP8)

  32. Added

    Systems MUST detect **correlated anomalies** across time, topology, and identity linkages.

  33. Added

    Failure mode: **composed attack success**, where individually mitigated vectors succeed in combination.

  34. Added

    ### **3.3 Detection Signals and Telemetry**

  35. Added

    - **Temporal**: burstiness, synchronized actions, unusual cadence - **Topological**: tightly clustered interactions, graph anomalies - **Behavioral**: repetitive patterns, low-entropy content, abnormal conversion rates - **Cross-Context**: sudden tier jumps across zones, inconsistent identities

  36. Added

    Systems SHOULD fuse signals into risk scores with **explainable summaries**.

  37. Added

    ### **3.4 Response Playbooks**

  38. Added

    - **Progressive friction**: rate limits, proof escalation, cooldowns - **Containment**: quarantine zones, shadow reduction of amplification - **Rollback**: revert affected rankings or decisions where feasible - **Human review**: escalate high-impact cases with auditable decisions (DP1 linkage)

  39. Added

    Failure mode: **delayed or blunt response** causing collateral damage or missed containment.

  40. Added

    ### **3.5 Transparency vs. Gaming**

  41. Added

    - Provide participant-legible explanations and audit summaries - Protect sensitive thresholds and heuristics

  42. Added

    Failure modes: - **gaming via overexposure** - **opacity via underexposure**

  43. Added

    ### **3.6 Cross-Zone Containment and Signal Sharing**

  44. Added

    - Attacks are **zone-scoped by default**; sharing of sanctions/signals MUST be deliberate and thresholded - Systems SHOULD support **signed, scoped advisories** between zones

  45. Added

    Failure modes: - **cascading harm** (over-sharing) or **blindness** (under-sharing)

  46. Added

    ### **3.7 Incentive Alignment (DP9 Link)**

  47. Added

    - Systems MUST minimize rewards for abusive behavior (no easy profit from spam/brigades) - Rewards SHOULD be tied to **verified, sustained contribution**

  48. Added

    Failure mode: **perverse incentives** that fund attacks

  49. Added

    ### **3.8 Resilience and Safe Degradation**

  50. Added

    - Under uncertainty, systems SHOULD degrade to **safer defaults** (reduced amplification, higher proof requirements) - Maintain service continuity while limiting harm

  51. Added

    Failure mode: **fail-open amplification** under stress

  52. Rewritten

    ## **3. Core Principle**Principle

  53. **Communities must be able to define and enforce the conditions under which participation, influence, and intelligence operate. If governance cannot be enforced under scale, coordination, and adversarial pressure, trust collapses.**

  54. 6 unchanged paragraphs
  55. - **Phantom governance**: rules exist but do not alter outcomes (violates DP2). - **Fail-open amplification**: under load or uncertainty, systems default to permissive amplification (violates DP8 + DP9 alignment). - **Uncontestable decisions**: participants cannot audit or appeal governance actions (violates DP1).

  56. Removed

    ## **4. Core Principles**

  57. Added

    ## Primary Mechanisms and Structural Conditions

  58. Added

    DP8 differs structurally from most Desirable Properties: its mechanisms are specified as an architecture rather than a flat list of conditions. The sections that follow this one carry that specification in depth. This section states the structural conditions that must hold regardless of how the architecture is implemented, and points to where each is elaborated.

  59. Added

    ### Enforcement must occur at the point of interaction

  60. Added

    Governance rules bind before actions propagate, at the interface layer, not in a platform backend that reviews outcomes afterward. Overlays, extensions, and native integrations are the execution surface. Elaborated in **System Architecture** (overlay-based governance, 5.1–5.2) and **Governance Composition** (composition constraints, 8.2).

  61. Added

    ### Policy must be attached to context, not to platforms

  62. Added

    Zones are the unit of governance: composable, overlapping, portable policy containers that declare participation thresholds, governance rules, AI permissions, and trust signals. Rules do not leak silently across zone boundaries, and boundary transitions signal changes in guarantees. Elaborated in **System Architecture** (5.3, 5.4.1–5.4.4).

  63. Added

    ### Capability must be tiered, stateful, and revocable

  64. Added

    Participation maps to enforced tiers with entry conditions, verifiable progression, and decay. Capability cannot be acquired out of band, and high-impact actions require proofs proportional to their reach. Elaborated in **Participation Model**.

  65. Added

    ### Automation must be a governed actor class

  66. Added

    AI agents hold verifiable identity, bounded scope with expiry, disclosure at the interface, and revocation pathways. Agents are subordinate to zone policy at runtime, not to policy documents. Elaborated in **AI Governance (DP12 Link)**.

  67. Added

    ### Governance must be composable without becoming bypassable

  68. Added

    Voting, moderation, reputation, access control, and dispute resolution operate as modules with typed and scoped outputs, declared precedence, and bounded feedback cycles. Elaborated in **Governance Composition**.

  69. Added

    ### Every governance action must produce reconstructable evidence

  70. Added

    Attribution, authority, applied rules, outcome impact, and appeal traces are recorded so that decisions can be audited and contested. Elaborated in **Minimum DP8 Alignment** (10.7) and the auditability requirements of **Path Toward ML-RFC** (12.4).

  71. Added

    ### Degradation must be safe and visible

  72. Added

    Under load, uncertainty, or attack, systems move toward stricter defaults — reduced amplification, higher proof requirements, narrower scopes — and disclose that they have done so. Elaborated in **Core Principles (Normative and Enforceable)** (4.9) and **Threats and Failure Modes**.

  73. Added

    ### Communities must be able to evolve and fork

  74. Added

    Governance stacks are versioned, forkable, and migratable, with explicit signaling to participants when rules change. Continuity of governance does not mean permanence of a single configuration. Elaborated in **System Architecture** (5.4.8) and **Governance Composition** (8.4).

  75. Added

    **Failure mode:** **architecture without conditions**, where a system implements zones, overlays, and modules as features while leaving enforcement, continuity, attribution, or degradation unspecified.

  76. Added

    ## Governance, Accountability, and Agency Surfaces

  77. Added

    Governance in DP8 is the subject matter of the property, not an adjacent concern. What this section adds is the requirement that the governance system itself be governed: that participants and communities can see how rules were made, act on them, and hold their operators accountable.

  78. Added

    A zone can enforce rules perfectly and still be illegitimate if the participants subject to those rules cannot inspect, influence, or leave them.

  79. Added

    Participants must be able to:

  80. Added

    - see which zone they are in, which rules apply, and which guarantees are currently active or degraded - understand their own tier, how it was assigned, what it permits, and what would raise or lower it - see when a governance action affected them, under what authority, and with what stated reason - contest decisions through a defined appeal path with timelines and reachable outcomes - distinguish human from automated actors and inspect the scope of any agent acting in the zone - exit a zone without forfeiting identity, history, or standing held outside it (DP1, DP7)

  81. Added

    Communities must be able to:

  82. Added

    - author, version, and fork their governance configuration without vendor permission - assign, bound, and revoke steward authority, including term limits and decay - audit enforcement in aggregate for bias, over-escalation, and missed harm without exposing individuals - publish precedence rules for overlapping zones and the arbitration path when they conflict - suspend or roll back a rule that produced harm, with the rationale recorded in governance memory - bind third-party tools and agents to zone policy as a condition of operating in the zone

  83. Added

    Stewards must be accountable in the same terms as participants. Moderation, adjudication, and rule configuration are high-impact actions, and DP8 treats them as attributable governance events rather than administrative privileges.

  84. Added

    **Example:** A participant's comment is down-ranked in a civic zone. The interface shows which rule applied, which steward or module executed it, the evidence class cited, and the appeal window. The appeal enters a queue with a published service level, and the outcome is written to governance memory whether or not the appeal succeeds. A quarterly audit reports how often that rule was applied, to whom, and how often appeals reversed it.

  85. Added

    **Failure mode:** **steward exceptionalism**, where enforcement is auditable for participants but discretionary and unlogged for those who hold authority.

  86. Added

    ## Incentives and Power Analysis

  87. Added

    Governance competes with incentives. Where the two diverge, incentives usually win, because they operate continuously while governance operates episodically.

  88. Added

    DP8 therefore treats amplification, visibility, and reputation as economic surfaces, not neutral mechanics. Whoever controls what becomes visible controls what becomes true in practice, and that control has value that others will pay to acquire.

  89. Added

    Predictable pressures on community-defined governance include:

  90. Added

    - **attention arbitrage:** actors invest in tier progression or steward proximity because visibility is monetizable, not because they value the community - **moderation cost shifting:** platforms externalize enforcement labor onto unpaid stewards while capturing the resulting engagement value (DP9, DP17) - **steward capture:** small groups accumulate adjudication authority because turnover is unrewarded and continuity is required for competence - **compliance theater as competitive advantage:** systems adopt the vocabulary of zones and tiers without enforcement, then compete against systems that pay the real cost of enforcing - **engagement-weighted defaults:** ranking systems inherited from the host platform quietly override zone policy at the margin - **sanction externalities:** zones export sanctions and advisories to shift enforcement cost outward, or withhold them to avoid reputational exposure

  91. Added

    DP8 therefore expects:

  92. Added

    - disclosure of the optimization targets operating inside a zone, including any inherited from the host environment - the ability for communities to set hard gates that incentives cannot bypass (DP12), rather than weights that incentives can outbid - compensation or resourcing pathways for stewardship labor, so that governance capacity does not depend on volunteer exhaustion (DP9, DP17) - rotation, decay, and shared authority as structural defenses against entrenchment rather than as norms of good behavior - no material reward for abusive throughput, so that brigading and farming are unprofitable rather than merely prohibited

  93. Added

    **Why this matters:** A zone whose rules are enforceable but whose incentives reward circumventing them will drift toward circumvention. Governance holds only where the cheapest path is also the compliant one.

  94. Added

    ## Community Signals Informing DP8

  95. Added

    Community input across the Meta-Layer submission process, moderation research, and platform governance experience converges on a consistent set of signals. They are not requests for more moderation. They are reports that governance is not real where it matters.

  96. Added

    Recurring signals include:

  97. Added

    - moderation experienced as arbitrary because the rule, the actor, and the evidence are never shown together - rules that apply visibly to ordinary participants and invisibly, if at all, to influential ones - communities that build norms in one environment and lose them entirely when the conversation moves - reputation that cannot be carried, or that arrives stripped of the context that made it meaningful - suspicion that a substantial share of amplification is automated, with no way to verify or contest it - exhaustion among the people who actually do moderation and facilitation work - distrust of appeals processes that accept submissions but produce no observable outcome - concern that AI participants already operate with effective autonomy while governance debates continue - marginalized communities reporting that automated enforcement misreads their context and vocabulary as violation

  98. Added

    These signals identify structural breaks rather than usability defects: enforcement without attribution, continuity without portability, participation without impact, and automation without constraint.

  99. Added

    DP8 treats them as design requirements. A zone that cannot answer "which rule, applied by whom, on what evidence, and how do I contest it" has not implemented governance regardless of how many controls it exposes.

  100. Added

    ## Core Principles (Normative and Enforceable)

  101. DP8 principles are **normative and enforceable**, and interlock with **DP1 (Identity)**, **DP2 (Agency)**, **DP4 (Data)**, and **DP12 (AI)**.

  102. 23 unchanged paragraphs
  103. Failure mode: **fail-open under stress**.

  104. Rewritten

    ## **5. System Architecture**Architecture

  105. ### **5.1 Overlay-Based Governance**

  106. 41 unchanged paragraphs
  107. Failure mode: **governance rigidity**

  108. Rewritten

    ## **6. Participation Model**Model

  109. DP8 defines participation as a **tiered, stateful system** where capability, influence, and accountability increase with demonstrated behavior and verified identity properties (DP1), under enforceable governance (Section 5.4).

  110. 17 unchanged paragraphs
  111. Failure mode: **throughput abuse**, where volume substitutes for trust.

  112. Rewritten

    ## **7. AI Governance (DP12 Link)**Link)

  113. DP8 requires that AI participation be **governed as a first-class actor class** within zones, with enforceable constraints at runtime and clear attribution aligned with DP1 and DP2.

  114. 20 unchanged paragraphs
  115. Failure modes: - **AI opacity**

  116. Rewritten

    ## **8. Governance Composition**Composition

  117. DP8 treats governance as a **composable system of modules** that MUST interoperate without bypassing enforcement (Section 5.4).

  118. 13 unchanged paragraphs
  119. Failure mode: **semantic mismatch**, where signals are misinterpreted across systems.

  120. Removed

    ## **9. Security and Adversarial Considerations**

  121. Removed

    DP8 assumes adversaries will combine **identity (DP1), agency (DP2), data flows (DP4), governance (DP8), and incentives (DP9)**. Systems MUST be robust to **multi-vector, cross-zone attacks** and degrade safely.

  122. Removed

    ### **9.1 Threat Classes (Extended)**

  123. Removed

    - **Sybil Attacks**: many identities controlled by few actors - **Brigading**: coordinated surges to influence outcomes - **Governance Capture**: concentration of power via roles or opaque processes - **Reputation Laundering**: reshaping signals across contexts to gain undue trust - **AI Amplification**: automated agents scaling influence beyond constraints - **Cross-Zone Escalation**: importing status or signals to bypass local rules

  124. Removed

    ### **9.2 Composed (Multi-Vector) Attacks**

  125. Removed

    Adversaries may combine: - AI agents + human click-farms - identity cycling + cross-zone escalation - incentive exploits (rewards) + feedback loops - data laundering (DP4) + reputation reuse (DP8)

  126. Removed

    Systems MUST detect **correlated anomalies** across time, topology, and identity linkages.

  127. Removed

    Failure mode: **composed attack success**, where individually mitigated vectors succeed in combination.

  128. Removed

    ### **9.3 Detection Signals and Telemetry**

  129. Removed

    - **Temporal**: burstiness, synchronized actions, unusual cadence - **Topological**: tightly clustered interactions, graph anomalies - **Behavioral**: repetitive patterns, low-entropy content, abnormal conversion rates - **Cross-Context**: sudden tier jumps across zones, inconsistent identities

  130. Removed

    Systems SHOULD fuse signals into risk scores with **explainable summaries**.

  131. Removed

    ### **9.4 Response Playbooks**

  132. Removed

    - **Progressive friction**: rate limits, proof escalation, cooldowns - **Containment**: quarantine zones, shadow reduction of amplification - **Rollback**: revert affected rankings or decisions where feasible - **Human review**: escalate high-impact cases with auditable decisions (DP1 linkage)

  133. Removed

    Failure mode: **delayed or blunt response** causing collateral damage or missed containment.

  134. Removed

    ### **9.5 Transparency vs. Gaming**

  135. Removed

    - Provide participant-legible explanations and audit summaries - Protect sensitive thresholds and heuristics

  136. Removed

    Failure modes: - **gaming via overexposure** - **opacity via underexposure**

  137. Removed

    ### **9.6 Cross-Zone Containment and Signal Sharing**

  138. Removed

    - Attacks are **zone-scoped by default**; sharing of sanctions/signals MUST be deliberate and thresholded - Systems SHOULD support **signed, scoped advisories** between zones

  139. Removed

    Failure modes: - **cascading harm** (over-sharing) or **blindness** (under-sharing)

  140. Removed

    ### **9.7 Incentive Alignment (DP9 Link)**

  141. Removed

    - Systems MUST minimize rewards for abusive behavior (no easy profit from spam/brigades) - Rewards SHOULD be tied to **verified, sustained contribution**

  142. Removed

    Failure mode: **perverse incentives** that fund attacks

  143. Removed

    ### **9.8 Resilience and Safe Degradation**

  144. Removed

    - Under uncertainty, systems SHOULD degrade to **safer defaults** (reduced amplification, higher proof requirements) - Maintain service continuity while limiting harm

  145. Removed

    Failure mode: **fail-open amplification** under stress

  146. Added

    ## Relationship to Other Desirable Properties

  147. Added

    DP8 is the layer at which the other properties become locally binding. It supplies the context — the zone — in which identity, agency, data, incentives, and automation are constrained in ways a specific community can define and defend.

  148. Added

    - **DP1** supplies the identity and attribution guarantees that make tiers, roles, and governance actions accountable; without it, participation integrity and capture resistance cannot hold - **DP2** supplies participant agency, ensuring zone rules change outcomes participants can perceive and control rather than preferences they merely configure - **DP3** supplies the adaptive governance patterns through which zone rules evolve, fork, and scale beyond a single community - **DP4** supplies purpose binding and consent propagation, so that moderation, ranking, and reputation cannot launder data use through governance actions - **DP5** supplies stable naming and resolution for zones, roles, and governance artifacts so that references survive movement - **DP7** carries governance state across systems and requires honest signaling of what degraded in transit; DP8 defines what must not be silently lost - **DP9** aligns rewards with sustained contribution, so influence cannot be purchased through throughput and stewardship labor is resourced - **DP11** defines the ethical floor for AI participation that zone policy tightens but may not fall below - **DP12** turns zone rules into executable policy objects with receipts; DP8 defines what communities are entitled to govern - **DP13** enforces containment, sandboxing, and rate limits that make zone constraints binding on automated actors - **DP14–DP15** supply transparency and provenance for governance decisions, making auditability and contestability practical - **DP18** supplies feedback and reputation dynamics that participation tiers depend on - **DP20** ensures communities own their governance configuration and can fork it, rather than licensing it from an operator

  149. Added

    A failure in any of these layers surfaces inside DP8 as illegitimate governance: rules that exist, apply unevenly, and cannot be traced or changed.

  150. Added

    ## Non-Goals and Explicit Boundaries

  151. Added

    DP8 does not:

  152. Added

    - prescribe a single governance model, voting method, moderation policy, or tier structure - require communities to converge on shared norms, or treat disagreement between zones as a defect - guarantee that community-defined governance produces good, fair, or wise decisions - eliminate moderation, expertise, delegation, or stewardship roles in favor of pure direct participation - replace legal systems, jurisdictional obligations, or platform liability - promise that every governance guarantee survives every interoperability boundary, only that loss is signaled rather than hidden - treat zone autonomy as a shield against baseline safety, identity, data, and AI constraints defined elsewhere in the stack - assume communities are internally homogeneous or that majority processes protect minorities within them

  153. Added

    DP8 defines the conditions under which community-defined governance is enforceable, portable, attributable, and contestable. It does not define what communities should decide.

  154. Rewritten

    ## **10. Minimum DP8 Alignment (Non-Normative)**(Non-Normative)

  155. Minimum alignment is not a feature checklist. It is the threshold at which governance is **enforceable, portable, and resistant to manipulation, capture, and coordination attacks**.

  156. 27 unchanged paragraphs
  157. Partial implementations that omit enforcement, continuity, or capture resistance MUST NOT be considered aligned with DP8.

  158. Removed

    ## **11. Open Questions**

  159. Added

    ## Open Questions and Future Work

  160. Open questions focus on cross-DP integration and operationalization:

  161. 5 unchanged paragraphs
  162. ### **11.6 Incentive Alignment (DP9)** - What reward models avoid funding abuse while sustaining participation?

  163. Rewritten

    ## **12. Path Toward ML-RFC**ML-RFC

  164. Advancement from ML-Draft to ML-RFC for DP8 requires **demonstrated, adversarially-tested governance systems operating across identity (DP1), agency (DP2), data (DP4), and AI constraints (DP12)**.

  165. 27 unchanged paragraphs
  166. - Governance is proven enforceable under adversarial conditions - Cross-DP integration (DP1, DP2, DP4, DP12) is validated in practice - Interoperability is demonstrated with explicit degradation semantics - Communities can evolve and fork governance without system failure - Participants can understand, audit, and contest governance outcomes

  167. Rewritten

    ## **13. Closing Orientation**Orientation

  168. DP8 defines the conditions under which communities become **sovereign coordination environments** rather than passive audiences.

Revision 03 Currently served
Approved

Published: 2026-08-08

Pages: 12 | Words: 5749

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.

Read this revision Compare with Revision 02
Revision 02
Approved

Published: 2026-08-05

Pages: 12 | Words: 5732

What changed:

Numbered section headings and cross-reference fixes for collaborative review

Read this revision Compare with Revision 01
Revision 01
Approved

Published: 2026-08-04

Pages: 12 | Words: 5705

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.

Read this revision Compare with Revision 00 (original)

Published: 2026-05-04

Pages: 7 | Words: 3449

Read this revision