DP18 - Feedback Loops & Reputation
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.
# DP18 – Feedback Loops and Reputation
*The Conditions for Learning, Recognition, and Repair*
<!-- dp-local-version: 1.0 | standardized: 2026-07-27 -->
## 1. Purpose of This Draft
Failure mode: **trust through surveillance**, where the system claims safety by collecting more data than communities can legitimately govern.
## 8. Governance Requirements
## 8. Governance, Accountability, and Agency Surfaces
Feedback and reputation systems are governance systems. They must themselves be governable.
Failure mode: **hidden reputation law**, where invisible formulas determine social standing and access.
### 8.1 Accountability surfaces
Governance claims about feedback and reputation must be checkable by the people they affect. DP18 therefore expects named surfaces rather than general assurances:
- a published feedback charter per zone, stating what is collected, who reads it, and what response commitments apply - a reputation register listing active reputation domains, their issuers, their rubrics, and the decisions they gate - a decision log linking governance changes to the feedback, evidence, or incidents that prompted them - a steward roster identifying who reviews disputes, on what timeline, and under whose oversight - an audit trail for changes to weighting, thresholds, and automated triage - an escalation route when a steward is themselves the subject of a complaint
Where a system cannot name the surface, it cannot claim the accountability.
### 8.2 Participant agency surfaces
Accountability without leverage produces informed powerlessness. DP18 requires that participants hold usable controls over their own signals and standing:
- see which reputation domains describe them, in which zones, and with what evidence - correct, annotate, or contest an attestation, and see the outcome of that contest - withhold or scope consent for reputation telemetry that is not necessary for a claimed function - export contribution history and reputation artifacts under DP4 and DP7 terms - request attenuation or repair after a defined period, and understand the criteria - decline reputation-gated roles without losing baseline participation rights
**Example:** A contributor opens their reputation panel, sees a "reliability" attestation issued by a moderation steward, disagrees with the underlying evidence, files a challenge, and receives a dated decision with reasoning and an appeal option.
**What this feels like:** Standing is something you can inspect and argue with, not something applied to you.
**Without this:** Reputation becomes an administrative fact about people that they can neither read nor answer.
Failure mode: **consultation without leverage**, where participants are told how the system works but cannot act on anything they learn.
## 9. Incentives and Power Analysis
Feedback and reputation systems redistribute power whether or not they intend to. Whoever defines valid signals, sets weights, issues attestations, and controls decay controls who becomes visible, trusted, paid, and promoted.
DP18 therefore treats incentive design as a governance question rather than a tuning question.
### 9.1 Who gains power from feedback systems
- **Signal definers** decide what counts as evidence. If only structured tickets count, participants who communicate in conversation, voice, or a second language lose standing (DP21, DP23). - **Attestation issuers** convert observation into durable claims. Concentrated issuance recreates gatekeeping under a new name. - **Weight setters** determine whose experience moves a decision. Weighting is policy, not math. - **Interface owners** decide what is easy to report and what requires effort. Friction is an allocation of voice. - **Aggregators** who hold cross-zone reputation data gain leverage over zones that cannot verify their inferences.
### 9.2 Predictable incentive distortions
- **Metric substitution:** systems optimize for measurable approval instead of durable contribution, because approval is cheaper to collect. - **Volume advantage:** participants with time and fluency accumulate reputation faster than participants with equal skill and less availability. - **Recognition asymmetry:** visible work such as posting accrues reputation while invisible maintenance such as triage, mediation, and care does not. - **Complaint deterrence:** where reporting is costly or exposing, harm goes unrecorded and the system reads silence as health. - **Steward overload:** unfunded review capacity turns response commitments into backlog, and backlog into cynicism (DP17). - **Score arbitrage:** where reputation unlocks compensation, actors invest in signal production rather than in the work the signal was meant to represent.
### 9.3 Counter-incentives DP18 expects
- fund review, mediation, and repair capacity as core functions rather than volunteer surplus - credit maintenance and care work explicitly as reputation domains (DP9, DP20) - weight signals from affected groups rather than from the loudest cohort - cap the decision weight any single issuer can hold, and rotate issuance - decay reputation so that standing reflects current participation rather than seniority - prohibit reputation-linked rewards from depending on signals participants cannot inspect - publish who benefits from each reputation domain, so that beneficiaries are legible
**Example:** A zone notices that its "helpfulness" domain is dominated by participants in one time zone. It rebalances by crediting asynchronous mentoring and by rotating the stewards who issue attestations.
Failure mode: **reputation as rent**, where early or well-positioned participants convert accumulated standing into permanent advantage that newer contributors cannot reach.
## 10. Community Signals Informing DP18
DP18 did not originate as an abstraction. It reflects recurring signals from communities that have lived through extractive feedback and punitive reputation.
Signals repeatedly expressed by participants, moderators, and maintainers include:
- "We answer surveys and nothing changes." Feedback is collected as sentiment, not as a governance input. - "I don't know why my standing dropped." Reputation effects arrive without explanation or appeal. - "One mistake follows me forever." Communities want accountability with a path back, not permanent exile. - "The loudest people set the agenda." Feedback volume is mistaken for feedback representativeness. - "Moderation work is invisible." Care, triage, and de-escalation carry weight in practice but not in recognition. - "Reporting is dangerous." Participants withhold reports because exposure risk exceeds expected remedy. - "My reputation is trapped." Contribution history cannot move between tools, so leaving means starting over (DP7). - "Scores feel like credit ratings." Participants distinguish sharply between contextual trust and generalized scoring. - "AI summarized us wrong." Communities want to see, and contest, how synthesis was produced (DP12, DP14). - "We need to know if it worked." Participants want evidence that changes made in their name improved outcomes.
These signals converge on a single structural request: make the loop complete and make the memory fair. DP18 encodes that request as design conditions rather than as goodwill.
Community signals are inputs to DP18, not ratification of it. They are recorded here so that later revisions can be checked against the concerns that motivated the property.
## 9.11. Evaluation Criteria
A DP18-aligned implementation should be evaluated against the following questions.
### 9.111.1 Signal quality
- Are feedback signals typed, scoped, and attributable at the right level? - Can systems distinguish evidence, opinion, endorsement, complaint, and appeal? - Are low-confidence signals prevented from causing high-impact outcomes without review?
### 9.211.2 Loop closure
- Can participants see whether feedback was received, routed, reviewed, and acted upon? - Do system changes link back to feedback or evidence? - Are non-actions explained where appropriate?
### 9.311.3 Context preservation
- Is reputation scoped to zones and contribution domains? - Does portable reputation carry rubrics, provenance, and limits? - Are degraded signals clearly labeled?
### 9.411.4 Contestability and repair
- Can participants dispute inaccurate reputation signals? - Are there appeal timelines and responsible stewards? - Do reputation states decay, renew, or repair over time?
### 9.511.5 Anti-gaming and safety
- Are feedback loops bounded against amplification spirals? - Are coordinated attacks, sybil behavior, and reputation farming mitigated? - Are reporting systems protected against weaponization?
### 9.611.6 Privacy and proportionality
- Is reputation based on necessary signals rather than totalizing surveillance? - Are sensitive feedback records protected? - Can participants understand which signals affect rights, rewards, or access?
### 9.711.7 Inclusion
- Can marginalized and less-resourced participants provide feedback meaningfully? - Are feedback channels multilingual, asynchronous, and accessible? - Are affected groups visible in system learning without being exposed to retaliation?
## 10.12. Implementation Patterns
### 10.112.1 Reputation domains instead of reputation scores
Use separate reputation domains for different capabilities rather than one universal score.
Example domains:
- trusted annotator - reliable bridge builder - safe moderator - responsive maintainer - accurate fact-checker - inclusive facilitator - responsible AI operator
### 10.212.2 Confidence-weighted signals
Signals should include uncertainty. A verified expert correction, a peer endorsement, an anonymous concern, and a bot-like mass vote should not carry the same weight.
### 10.312.3 Receipts everywhere
Feedback, moderation, role changes, rewards, and reputation updates should produce receipts that can be audited without exposing unnecessary private data.
### 10.412.4 Decay by default
Signals should age unless renewed by current evidence. Decay prevents permanent lock-in and reduces the power of old or stale interactions.
### 10.512.5 Role renewal cycles
Reputation-linked roles should require periodic review or renewal, especially for stewards, moderators, grant reviewers, and high-impact AI operators.
### 10.612.6 Affected-group weighting
Feedback from those directly affected by a policy or harm may require special visibility or routing, while still protecting against capture.
### 10.712.7 Deliberative escalation
High-impact reputation changes should move from automated detection to human or community review before affecting access, compensation, or public standing.
### 10.812.8 Reputation portability bundles
Portable reputation should export as bundles containing claims, provenance, rubrics, expiry, dispute status, and interpretation limits.
### 10.912.9 Community retrospectives
Communities should periodically review whether feedback loops are actually improving governance, safety, inclusion, and contribution quality.
## 11.13. Relationship to Other Desirable Properties
### DP1 – Identity and Accountability
Communities should be able to own and govern their feedback data, reputation schemas, and contribution histories.
## 12. Open Questions for ML-RFC Development
1. What minimum schema should define a feedback object across the meta-layer? 2. What minimum schema should define a reputation object? 3. Which reputation dimensions should be standardized, and which should remain zone-defined? 4. How should reputation decay be represented across systems? 5. What privacy-preserving methods can support reputation without centralized surveillance? 6. How should communities distinguish endorsement, expertise, contribution, care, and popularity? 7. What rights should participants have when reputation affects access, compensation, or visibility? 8. How should non-human agents receive, carry, and contest reputation? 9. What signals are safe to make portable across zones? 10. How can marginalized communities govern feedback without being overexposed or tokenized? 11. What forms of feedback should trigger mandatory governance review? 12. How can reputation-linked roles avoid ossification and capture? 13. What are the rollback standards for failed reputation experiments? 14. How should feedback systems disclose AI summarization, clustering, or weighting?
## 13. Minimal DP18 Compliance Checklist
## 14. Non-Goals and Explicit Boundaries
DP18 is frequently misread as an argument for more measurement. It is not. The following are explicit non-goals, stated so that implementers cannot claim DP18 for systems it was written to prevent.
**DP18 does not create a universal reputation score.** There is no single number, tier, or trust level that follows a person across the meta-layer. Reputation is domain-scoped and zone-scoped by construction, and any system that collapses domains into one general standing has left DP18, not implemented it.
**DP18 does not authorize social credit.** Reputation may describe contribution within a bounded context. It may not be used to rank persons generally, to condition access to essential services, or to produce behavioral compliance through generalized scoring.
**DP18 does not justify surveillance.** Feedback and reputation are not a warrant for continuous telemetry. Signals must be necessary for a declared function, minimized, and governed under DP4. "We needed the data to compute trust" is not a defense.
**DP18 does not make feedback binding.** A signal is a legitimate input to a decision, not a decision. Communities remain free to decline requests, provided the decision and its reasoning are visible. DP18 requires loop closure, not majority rule by complaint volume.
**DP18 does not replace governance.** Feedback informs governance under DP3 and DP8; it does not substitute for deliberation, rights, or due process. Automated adaptation driven by signals must remain bounded and human-ratifiable.
**DP18 does not prescribe one interface, schema, or algorithm.** Zones may implement feedback objects, rubrics, and weighting differently. DP18 constrains the properties those implementations must preserve: typing, provenance, contestability, decay, and receipts.
**DP18 does not promise neutrality.** Any feedback system encodes choices about what counts. DP18 requires those choices to be published, versioned, and contestable rather than presented as objective measurement.
**DP18 does not guarantee that harm will be caught.** It requires that reporting exist, be safe, and be answerable. Absence of reports is not evidence of absence of harm, and no implementation may treat a quiet dashboard as a health claim.
**DP18 does not permit permanent records as punishment.** Accountability without a path to repair is exile. Retention that cannot decay, expire, or be contextualized is outside DP18 regardless of accuracy.
**DP18 does not extend to identity verification.** Establishing who someone is belongs to DP1. DP18 governs the memory of what was contributed and how it was experienced.
**DP18 does not require that all reputation be portable.** Portability is bounded by rubric fidelity. Where meaning cannot survive transfer, DP18 prefers visible degradation over silent translation (DP7).
## 15. Minimum DP18 Alignment (Non-Normative)
A system claiming DP18 alignment SHOULD demonstrate:
- structured feedback objects - visible feedback routing and response commitments - reputation scoped by zone and contribution domain - published reputation logic where it affects access, rewards, or visibility - decay, renewal, and repair mechanisms - dispute and appeal pathways - protection against sybil attacks, brigading, and reputation farming - privacy-preserving data practices - AI feedback processing with disclosure and human oversight - adaptation receipts linking feedback to changes - safeguards against runaway amplification loops - explicit interoperability semantics for reputation portability
The following statements describe what each of those conditions means in practice. They are non-normative and are offered as an assessment aid rather than as a conformance test.
### 15.1 Signal integrity
Feedback is captured as typed, scoped objects with provenance and confidence metadata. Evidence, opinion, endorsement, complaint, and appeal are distinguishable. Low-confidence signals cannot trigger high-impact outcomes without review.
### 15.2 Loop closure
Every accepted signal has a state a participant can observe: received, routed, under review, acted upon, declined with reasoning, or deferred. Changes to rules or systems reference the signals that informed them.
### 15.3 Contextual memory
Reputation exists as named domains bound to zones and rubrics. No general-purpose score is exposed. Cross-zone use carries rubric, issuer, and limits, or is labeled as degraded.
### 15.4 Contestability and repair
Participants can inspect, annotate, and challenge attestations that describe them. Challenges have owners and timelines. Standing decays, renews, and can be repaired under published criteria.
### 15.5 Proportionate data practice
Collection is minimized and purpose-bound. Public recognition and private telemetry are separated. Reporters have protection appropriate to their risk, including pseudonymous pathways where safe.
### 15.6 Bounded automation
AI participation in clustering, summarization, or weighting is disclosed, sampled for accuracy, and ratified by humans before it affects rights, compensation, or access.
### 15.7 Anti-gaming posture
Amplification loops are damped. Coordinated inauthentic signaling, reputation farming, and weaponized reporting have named mitigations and observable incident handling.
### 15.8 Governance of the loop itself
The rules governing feedback and reputation are published, versioned, and amendable through the zone's governance process, with a record of who changed what and why.
## 16. Open Questions and Future Work
1. What minimum schema should define a feedback object across the meta-layer? 2. What minimum schema should define a reputation object? 3. Which reputation dimensions should be standardized, and which should remain zone-defined? 4. How should reputation decay be represented across systems? 5. What privacy-preserving methods can support reputation without centralized surveillance? 6. How should communities distinguish endorsement, expertise, contribution, care, and popularity? 7. What rights should participants have when reputation affects access, compensation, or visibility? 8. How should non-human agents receive, carry, and contest reputation? 9. What signals are safe to make portable across zones? 10. How can marginalized communities govern feedback without being overexposed or tokenized? 11. What forms of feedback should trigger mandatory governance review? 12. How can reputation-linked roles avoid ossification and capture? 13. What are the rollback standards for failed reputation experiments? 14. How should feedback systems disclose AI summarization, clustering, or weighting?
## 14.17. Path Toward ML-RFC
DP18 is currently an ML-Draft and serves as exploratory scaffolding for how feedback loops and reputation can function as accountable learning infrastructure in the meta-layer.
DP18 is expected to evolve iteratively, with partial RFCs emerging for specific components rather than a single monolithic specification.
## 15.18. Closing Orientation
DP18 makes the meta-layer capable of learning.
Published: 2026-08-08
Pages: 13 | Words: 6227
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: 13 | Words: 6210
What changed:
Numbered section headings and cross-reference fixes for collaborative review
Published: 2026-08-04
Pages: 13 | Words: 6200
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.