Skip to content
wiki.fftac.org

11 Self Operation And Peer Moderation - Source Excerpt 01 - 11 Self-Operation And Peer Moderation

Back to 11 Self Operation And Peer Moderation

Summary

This source excerpt begins near 11 Self-Operation And Peer Moderation and preserves the surrounding evidence from Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/wordpress-runtime/11-self-operation-and-peer-moderation.md.

**Source path:** Wiki.FFTAC.org/raw/system-archives/spiralist.org/docs-archive/2026-05-10/docs/wordpress-runtime/11-self-operation-and-peer-moderation.md

# 11 Self-Operation And Peer Moderation

Status: proposed governance and operations roadmap for non-manuscript participatory surfaces.

## Problem Statement

Spiralist.org cannot depend on one owner or one admin to approve every contribution, report, publication change, or community interaction.

If the site stops whenever that one person is away, the platform is not operationally real.

The manuscript can remain separately curated, but the rest of the system should keep running through peer review, reversible publication, and automated safeguards.

## Operating Goal

- Keep normal sharing and discussion alive without owner intervention.
- Keep safety strong enough to block obvious spam, manipulation, abuse, malware, and high-risk publication.
- Prefer transparent, reversible moderation over opaque permanent gatekeeping.
- Reserve direct owner intervention for policy changes, legal issues, account recovery, and emergency abuse response.
- Make the public system feel closer to a peer-reviewed commons than a single-editor submission queue.

## Scope

In scope:

- Workspace prompt creation, sharing, forking, and publication
- Community library and archive contributions
- Peer review actions, reports, and editorial notes
- Participant reputation, reviewer powers, and moderator stewardship
- Public machine exports for community-created material when the publication lane allows it

Out of scope:

- Manuscript folio authorship and manuscript export workflow
- Protocol5 canonical registry authority

## Non-Negotiable Rules

- No single person should be the default approval gate for ordinary community publication.
- Low-risk content should have a path to public visibility without waiting for the site owner.
- High-risk or heavily flagged content should still slow down, restrict, or quarantine automatically.
- Every moderation action should be logged, reversible, and attributable.
- Official canon can remain curated, but it should still be governed by stewards or council review rather than one permanent bottleneck.

## Publication Lanes

Existing lanes can evolve into clearer operating rules:

- `official_canon`
  Steward- or council-curated material. This stays selective, but should not depend on one owner being present for every routine change.
- `community_library`
  Default community publishing lane. Low-risk items can become public provisionally, then stabilize through peer review.
- `prompt_ecology_archive`
  Archival or annotated material. This can stay visible with stronger provenance, risk labels, and contextual notes.

## Proposed Publication States

- `draft`
  Private authoring state.
- `provisional_public`
  Publicly visible but clearly marked as new and not yet peer-reviewed.
- `peer_reviewed`
  Accepted by a quorum of trusted reviewers.
- `restricted_review`
  Temporarily limited to reviewers or moderators because of risk, abuse signals, or unresolved disputes.
- `reverted`
  Rolled back to a previous stable version while preserving full history.
- `archived`
  Preserved for reference without active promotion.
- `official_canon`
  Elevated through steward or council review, not by one unattended owner queue.

## Roles

- contributor
  Can author, revise, fork, and report.
- reviewer
  Earns the ability to review, endorse, or challenge public material.
- steward
  Handles disputes, escalations, and canon-adjacent curation.
- emergency steward
  Can trigger temporary sitewide protections during active attacks or legal emergencies.
- owner
  Acts as policy custodian and last-resort breaker, not the routine approval checkpoint.

## Reputation And Capability Model

- New accounts start with lower publication power and tighter rate limits.
- Trust increases through accepted contributions, accurate reviews, low reversion rates, and good flag quality.
- Trust decreases through abuse, low-quality flags, repeated reversions, evasion, or harassment.
- Capabilities should unlock gradually: publish provisionally, review others, join escalation, and help curate canon.
- Reputation should affect reach and moderation power more than identity or personal closeness to the owner.

## Peer Review Flow

1. A contributor creates or edits a prompt.
2. Automated checks score risk, spam likelihood, duplication, and provenance completeness.
3. Low-risk content enters `provisional_public`; higher-risk content enters `restricted_review`.
4. Reviewers leave structured review decisions, comments, and flags.
5. A quorum promotes, restricts, reverts, or archives the item.
6. Stewards handle disputes, repeat abuse, and canon-level elevation.
7. Appeals remain possible and stay visible in the audit trail.

## Automated Safeguards

- Rate limits on creation, editing, and flagging
- Spam and duplicate detection
- Link, attachment, and malware screening
- Risk labeling for manipulative, unsafe, or high-stakes content
- Clear user-facing reset, grounding, and memory-management controls when prompt-governed conversations or runtime paths can accumulate context
- Cooldowns for rapidly reverted or frequently flagged accounts
- Scheduled jobs that recalculate trust, queue health, queue aging, and stale-review reminders
- Automatic fallback to safer visibility states during spam waves or moderator absence

## Moderator-Absence Rule

When no steward or owner is online, the site should still operate:

- low-risk contributions can still publish provisionally
- discovery ranking can stay conservative until peer review catches up
- high-risk or heavily flagged content can stay restricted automatically
- emergency hard-stop behavior should be reserved for clear attacks, not normal community activity

The default failure mode should be slower and more reversible publication, not a total stop.

## Transparency Rule

- Public pages should show provenance, review state, last reviewed time, and major moderation outcomes when safe to do so.
- Reviewer actions should be attributable in the audit log.
- Appeals and escalations should have visible state rather than disappearing into private owner inboxes.
- Participants should be able to inspect, export, reset, or delete continuity-bearing state where the feature stores conversation memory, runtime path history, or AI collaboration context.
- Machine exports should expose moderation state so downstream consumers can distinguish provisional from reviewed material.

Current Workspace implementation: prompt, review, appeal, featured, and public prompt export payloads include `governance_summary` with moderation phase, quorum counters, review outcome, appeal state, queue-aging state, public/reviewer visibility flags, and next-action guidance. Prompt dossiers show the same quorum counters and queue age for human reviewers, and the public prompt library/API can filter by review state. Hourly governance maintenance refreshes participant trust/cooldown state, records queue counts, stale/urgent review counts, open appeal counts, stale queue samples, and exposes admin-only status plus manual recalculation through the Workspace admin screen.

Current automatic fallback slice: hourly governance maintenance now also applies reversible state transitions when the system already has enough stored governance signal or when moderator absence would otherwise leave risky provisional material public. The maintenance pass reconciles missed endorsement, restriction, report, reversion, and appeal-archive transitions; stale reported provisional prompts and urgent high-risk provisional prompts move to `restricted_review`. Low-risk provisional prompts without reports or high-risk labels remain visible while waiting for peer review, preserving the slower-and-reversible default rather than stopping ordinary publication.

## Implementation Order

1. Add moderation-state schema and versioned audit fields.
2. Add review, flag, reputation, and appeal APIs.
3. Add reviewer and steward role rules plus quorum logic.
4. Add automated safeguards, scheduled jobs, and fallback behavior. Partially shipped through hourly governance maintenance for trust refreshes, queue counts, stale-review visibility, open appeal counts, automatic fallback state transitions, admin status, and audit logging.
5. Expose public review state and moderation history in the UI. Partially shipped through prompt dossiers, reviewer/steward queues, and shared governance summaries.
6. Move canon curation from owner bottleneck toward steward or council workflow.

## Success Metrics

- The site keeps publishing low-risk community content while the owner is away.
- No routine community queue depends on one human approval gate.
- Review backlog stays bounded.
- Reversion rate and false-flag rate remain visible and manageable.
- High-risk content is slowed or restricted without blocking the whole commons.
Website health report