DP12 - Community Governance of AI
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 01 with Revision 02. Struck-through text was removed; highlighted text was added.
# DP12 – Community-BasedCommunity-based AI Governance (V1.1)
*AI systems in the Meta-Layer are governed not by corporations — but by the communities that use them.*
<!-- dp-local-version: 1.0 | standardized: 2026-07-27 | source: DP12 V1.1 -->
## 1. Purpose of This Draft
This draft articulates Desirable Property 12 (DP12) as the condition under which communities can define, execute, audit, and evolve the rules governing AI behavior in shared digital environments.
DP12 does not prescribe a single voting system or governance model. It defines minimum conditions for governance to be executable, contestable, and evolvable.
## 2. Problem Statement
In today’s web, governance of AI systems is largely:
DP12 reframes governance as an operational system: rules that can be authored, executed, observed, and revised in a continuous loop.
## 3. Threats and Failure Modes
### 3.1 Centralized control masquerading as governance
**Why this matters:** Governance that cannot survive movement across systems collapses into local silos, undermining legitimacy and continuity (DP7).
## 4. Core Principle
AI behavior in the meta-layer must be governed by communities through visible, executable, and evolvable rule systems applied at the point of interaction.
**Without this:** AI behavior is shaped by invisible incentives rather than community-defined norms.
## 5. Primary Mechanisms and Structural Conditions
### 5.0 Governance Execution Layer: Policy, Binding, and Enforcement
AI may assist in summarization, simulation, and analysis, but must not replace human ratification for material decisions and must disclose assistance.
## 6. Governance, Accountability, and Agency Surfaces
Governance must be experienced at the interface where decisions matter.
**Example:** A user sees that an AI response was modified by Policy A (v3.2) due to safety constraints; they can view the policy, see prior changes, and file an appeal that triggers a review queue with SLA.
## 7. Incentives and Power Analysis
Governance is effective only if incentives do not undermine it.
- alignment between policy constraints and incentive systems (DP9) - disclosure of material incentives affecting outcomes - community ability to set hard gates that incentives cannot bypass
## 8. Community Signals Informing DP12
Across systems, consistent signals reveal that governance is failing not at the level of values, but at the level of execution and legitimacy:
DP12 treats these signals as evidence that governance must be observable, causal, and continuous—not intermittent or symbolic.
## 9. Non-Goals and Explicit Boundaries
DP12 does not:
- guarantee unanimous agreement or optimal decisions - eliminate expert roles or moderation - replace legal systems or jurisdictional obligations - mandate a single governance mechanism or tooling stack
It defines conditions for **legitimate, executable governance**.
## 10. Minimum Alignment (Non-Normative)
A DP12-aligned system must meet a baseline where governance is not only declared, but operationally binding.
At minimum, systems must:
- bind policies directly to runtime execution points where AI behavior occurs - ensure policies remain executable after transfer across systems, or explicitly declare loss of enforceability - expose active policy state and changes at the interface level in a way participants can understand - produce verifiable governance receipts for all material outcomes (DP15) - provide appeal, correction, and escalation pathways with defined timelines and outcomes - couple governance rules to containment and enforcement systems (DP13) - preserve complete policy history with versioning, rationale, and traceability
If any of these conditions are missing, governance is functionally symbolic, regardless of how comprehensive the written policies appear.
## 11. Open Questions and Future Work
DP12 surfaces a set of unresolved design tensions at the intersection of governance, AI behavior, and cross-system interoperability. These questions are not blockers; they are invitations to experiment with bounded, auditable approaches that can evolve under real-world conditions.
- balancing local autonomy with cross-system consistency (DP7) - preventing coordinated capture while enabling broad participation - scaling deliberation without overload (sampling, delegation, AI assistance) - representing complex policies accessibly without losing precision - liability and responsibility for AI-mediated outcomes across jurisdictions
## 12. Relationship to Other Desirable Properties
DP12 functions as the execution layer that activates the broader meta-layer system.
- DP3 defines how governance evolves; DP12 ensures those decisions actually run - DP4 constrains what data can be used; DP12 ensures those constraints are enforced in practice - DP7 ensures governance artifacts move across systems; DP12 ensures they remain executable after they move - DP9 shapes incentives; DP12 ensures incentives cannot bypass governance constraints - DP11 defines ethical expectations; DP12 binds them to real system behavior - DP13 enforces rules through containment; DP12 defines what must be enforced - DP14–DP15 ensure transparency and provenance; DP12 produces the receipts that make governance auditable - DP20 defines who owns governance; DP12 ensures ownership translates into actual control
Without DP12, other properties remain declarative. With DP12, they become operational.
## 13. Foresight and Failure Design
DP12 assumes governance will be actively contested by both human and automated actors, especially as AI systems scale and adapt.
Governance failure is inevitable at scale. Silent, untraceable, or uncorrectable failure is not.
## AI Governance Processes
DP12 requires that governance be executable, but execution presupposes decisions. This section specifies the processes by which communities produce, revise, and retire the policy objects that the execution layer binds to behavior.
Process design is where governance legitimacy is won or lost. A system can bind policy perfectly to runtime and still be illegitimate if the policies were authored by a few, adopted without notice, and never revisited.
### Proposal and standing
Communities must define who may propose a rule, what a proposal must contain, and how it enters consideration.
- proposals declare scope, affected actors, expected behavioral change, and enforcement hooks - standing to propose is stated explicitly, including whether affected non-members may petition - proposals are versioned artifacts from the moment they are filed, not messages in a channel
**Failure mode:** **agenda capture**, where the ability to put a question forward is the real locus of power.
### Deliberation with bounded load
Deliberation must scale without collapsing into either noise or delegation to whoever has the most time.
- time-boxed comment periods with published start and end - structured argument capture, so positions and evidence are linked to the proposal rather than scattered - sampling, juries, or randomized panels where full participation is impractical - AI-assisted summarization permitted, disclosed, and never authoritative (5.10) - explicit protection for minority positions in the record
**Failure mode:** **deliberation fatigue**, where volume ensures that only the most invested participate and their preferences are recorded as consensus.
### Norm-adaptive mediation
Where rules govern discourse, mediation should adjust to community norms rather than apply static enforcement. Soft interventions — modulated visibility, reflection prompts, friction before amplification — can achieve alignment without punitive action, and their calibration is itself a governance decision subject to review.
**Failure mode:** **static enforcement**, where rules written for one moment are applied unchanged as context, membership, and risk shift.
### Ratification and thresholds
Adoption must be a defined event with a recorded outcome.
- quorum, threshold, and tie-breaking rules stated before the vote - material decisions require human ratification; AI may analyze and simulate but not ratify (5.10) - adoption produces a signed policy object with version, rationale, and effective date - notice periods before enforcement begins, proportional to the change's impact
**Failure mode:** **silent adoption**, where a rule takes effect before those subject to it can observe that it changed.
### Delegation and representation
Participants may delegate governance capacity, and delegation must remain accountable.
- scopes are explicit and revocable at any time (5.8) - term limits and decay prevent entrenchment - delegates' votes and rationales are visible to those who delegated to them - concentration of delegated authority is measured and disclosed
**Failure mode:** **representation drift**, where delegation is durable and revocation is theoretically available but practically inert.
### Emergency and expedited pathways
Automated systems act faster than deliberation. Rapid response must exist without becoming the normal path.
- emergency policies are scoped, time-bound, and expire automatically unless ratified - authority to invoke is named in advance, as is the notification requirement - every emergency action enters the ordinary review queue afterward - repeated invocation of the same emergency provision triggers mandatory permanent review
**Failure mode:** **permanent emergency**, where expedited authority becomes the governing mode.
### Appeal and correction
Governance produces wrong outcomes; the process must metabolize that.
- defined appeal paths with published timelines and reachable outcomes - standing to appeal for those affected, not only those sanctioned - reversal produces a receipt and, where feasible, remediation of the original effect - patterns of reversal feed back into rule revision rather than only individual relief
**Failure mode:** **appeal as absorption**, where objections are collected, resolved individually, and never change the rule that produced them.
### Federated coordination across jurisdictions
Some AI risks exceed any single community's scope. DP12 anticipates cross-jurisdictional coordination for norm-setting and emergency response, structured to prevent centralized domination: mutual recognition of policy objects, scoped advisory sharing, and explicit limits on what coordination bodies may compel.
**Failure mode:** **coordination capture**, where cross-community structures become the venue through which local autonomy is overridden.
### Review, sunset, and retirement
Rules accumulate. Governance must include a path out.
- scheduled review dates attached to every policy object at adoption - sunset conditions for rules addressing temporary conditions - retirement produces a record explaining what changed and what replaced it - governance memory retains superseded rules and their rationale (5.4)
**Failure mode:** **rule sediment**, where obsolete constraints persist because no process retires them and enforcement becomes selective by necessity.
**Why this matters:** The execution layer determines whether rules bind. Process determines whether they deserve to.
## Policy-Bound Verification
Governance that binds policy to behavior must be able to demonstrate that it did so. Without verification, a governance receipt is a claim about enforcement rather than evidence of it, and a community cannot distinguish a system that follows its rules from one that reports following them.
Policy-bound verification is the requirement that the connection between a policy object and an observed outcome be independently checkable.
### Determinism as a verification precondition
Runtime binding must be reproducible: the same inputs, under the same policy version, produce the same governed outcome. Where models introduce nondeterminism, the governed decision — allowed, modified, blocked, escalated — must remain stable even when the generated content varies.
**Failure mode:** **unreproducible enforcement**, where outcomes cannot be re-derived and therefore cannot be audited.
### Receipts as verifiable artifacts
Governance receipts (5.0) must be more than logs. A receipt should be signed, tamper-evident, and sufficient for a third party to check the claimed evaluation.
A verifiable receipt includes:
- policy identifiers and exact versions applied - a hash or reference to the inputs and conditions evaluated - the decision, any modification applied, and any override invoked - the components that executed the evaluation, with attestations - the zone and authority under which the decision was made - links to prior receipts in the same chain of decisions
**Failure mode:** **receipt theater**, where records are produced that cannot be checked against anything.
### Policy simulation and pre-deployment testing
Policies must be testable before they bind. Communities should be able to run a candidate policy against historical or synthetic cases and observe what would have changed.
- conformance suites for policy objects, versioned alongside them - differential testing between policy versions, reporting behavioral deltas - publication of simulation results as part of ratification (see AI Governance Processes)
**Failure mode:** **blind adoption**, where rules are enacted without knowing what they will do.
### Drift detection between intent and behavior
Adaptive systems learn to satisfy the letter of a constraint while defeating its purpose. Verification must therefore measure outcomes, not only compliance events.
- continuous sampling of governed interactions against policy intent - detection of surface compliance with divergent outcomes - alerting when enforcement rates change without a corresponding policy change - explicit measurement of the gap between declared and observed behavior (**Foresight and Failure Design**)
**Failure mode:** **specification gaming**, where the audit passes and the harm continues.
### Independent verifiability
A community must not be required to trust the operator's own attestation.
- receipts and policy objects are exportable and checkable outside the system that produced them - third parties can replay a decision given the policy version and recorded inputs - attestations are anchored so that after-the-fact revision is detectable - verification does not require access to private participant data (DP4)
**Failure mode:** **self-audit monopoly**, where only the enforcing party can confirm enforcement.
### Override and exception accounting
Overrides are legitimate and must be accounted for as first-class governance events.
- every override records authority, scope, duration, and rationale (5.0) - override rates are published and reviewed as an aggregate signal - undisclosed exception pathways are treated as a compliance failure, not a configuration detail
**Failure mode:** **shadow exception layer**, where formal policy holds for most traffic and quietly does not for some.
### Verification across boundaries
When policies move between systems, verification must move with them or the loss must be declared (5.9, DP7).
- receiving systems state whether they can enforce the transferred policy, partially enforce it, or only record it - verification artifacts from the origin remain checkable after transfer - degradation of enforceability is signaled at the boundary, not discovered afterward
**Failure mode:** **verification laundering**, where a policy transferred into a weaker environment retains the appearance of enforcement.
### Participant-facing verification
Verification that only auditors can perform does not restore participant trust.
- participants can retrieve the receipt for a decision that affected them - receipts are rendered in plain language with the technical artifact available beneath - appeal paths accept receipts as evidence and produce receipts in turn
**Example:** A participant's post is modified by an AI moderation policy. The receipt names Policy A v3.2, the evaluated conditions, the modification applied, and the executing component's attestation. The participant exports the receipt, an independent auditor replays the decision against the published policy version and reproduces the outcome, and the community's monthly report shows the enforcement rate for that policy alongside its override count.
**Why this matters:** Governance becomes authoritative at the point where its claims can be checked by someone with no stake in the answer. Until then, communities are asked to trust that rules bound behavior — which is the condition DP12 exists to end.
## Relationship to Other Desirable Properties
DP12 functions as the execution layer that activates the broader meta-layer system.
- DP3 defines how governance evolves; DP12 ensures those decisions actually run - DP4 constrains what data can be used; DP12 ensures those constraints are enforced in practice - DP7 ensures governance artifacts move across systems; DP12 ensures they remain executable after they move - DP9 shapes incentives; DP12 ensures incentives cannot bypass governance constraints - DP11 defines ethical expectations; DP12 binds them to real system behavior - DP13 enforces rules through containment; DP12 defines what must be enforced - DP14–DP15 ensure transparency and provenance; DP12 produces the receipts that make governance auditable - DP20 defines who owns governance; DP12 ensures ownership translates into actual control
Without DP12, other properties remain declarative. With DP12, they become operational.
## Non-Goals and Explicit Boundaries
DP12 does not:
- guarantee unanimous agreement or optimal decisions - eliminate expert roles or moderation - replace legal systems or jurisdictional obligations - mandate a single governance mechanism or tooling stack
It defines conditions for **legitimate, executable governance**.
## Minimum DP12 Alignment (Non-Normative)
A DP12-aligned system must meet a baseline where governance is not only declared, but operationally binding.
At minimum, systems must:
- bind policies directly to runtime execution points where AI behavior occurs - ensure policies remain executable after transfer across systems, or explicitly declare loss of enforceability - expose active policy state and changes at the interface level in a way participants can understand - produce verifiable governance receipts for all material outcomes (DP15) - provide appeal, correction, and escalation pathways with defined timelines and outcomes - couple governance rules to containment and enforcement systems (DP13) - preserve complete policy history with versioning, rationale, and traceability
If any of these conditions are missing, governance is functionally symbolic, regardless of how comprehensive the written policies appear.
## Open Questions and Future Work
DP12 surfaces a set of unresolved design tensions at the intersection of governance, AI behavior, and cross-system interoperability. These questions are not blockers; they are invitations to experiment with bounded, auditable approaches that can evolve under real-world conditions.
- balancing local autonomy with cross-system consistency (DP7) - preventing coordinated capture while enabling broad participation - scaling deliberation without overload (sampling, delegation, AI assistance) - representing complex policies accessibly without losing precision - liability and responsibility for AI-mediated outcomes across jurisdictions
## 14. Path Toward ML-RFC
Advancing DP12 requires moving from specification to demonstrated practice: reference implementations, interoperable policy artifacts, and live governance pilots that prove rules can bind behavior across contexts. Progress should be measured by working systems and verifiable outcomes, not declarations alone.
- standardize policy object schemas and receipt formats - publish reference implementations for runtime policy binding - test governance loops in live communities with varied risk profiles - align with identity/accountability layers for attribution (DP1) - iterate with civil society, developers, and regulators
Progress should be demonstrated through working systems, not only specifications.
## 15. Closing Orientation
DP12 is the point at which governance stops being descriptive and becomes authoritative.
Published: 2026-08-08
Pages: 9 | Words: 4202
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: 4186
What changed:
Numbered section headings and cross-reference fixes for collaborative review
Published: 2026-08-04
Pages: 9 | Words: 4145
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-05-04
Pages: 6 | Words: 2574
What changed:
The upgraded DP12 shifts governance from a conceptual or participatory idea into a fully executable system. The earlier version emphasized community involvement—rules, dialogue, and memory—but the new version introduces a governance execution layer with structured policy objects, runtime binding, and enforcement coupling. Governance is no longer just “deciding rules”; it is now binding those rules deterministically to AI behavior at the point of interaction, with verifiable governance receipts that show exactly which policy was applied and why.
A major addition is portability and interoperability of governance itself. The upgraded draft ensures that policies, decisions, and authority can move across systems without losing meaning or enforceability. It explicitly tackles governance degradation across environments—something the original only implied. This includes semantic preservation, enforcement equivalence, and explicit signaling when governance weakens. In other words, governance is no longer local—it becomes infrastructure that travels with the user and the community.
Finally, DP12 now treats governance as a continuous operational loop with real power over incentives and system behavior. It integrates directly with containment (DP13), incentives (DP9), and auditability (DP14–15), ensuring that rules cannot be bypassed by economic pressures or hidden system logic. It also introduces stronger mechanisms for conflict resolution, override visibility, and governance memory. The net effect: governance is no longer advisory or symbolic—it becomes causal, inspectable, and enforceable under real-world conditions.