Moderation queues: Storage, safety, and operations
Moderation decisions are idempotent, appealable, and audit-logged with explicit race handling when multiple reviewers or automation touch the same item; this block does not claim legal sufficiency.
Package status: AI-assisted reference package. Static package validation has passed; implementation scenarios remain not run and human domain review is required before stable adoption.
Decision
Each content item in a moderation queue moves through enumerated decision states with versioned transitions. Human reviewers and automation may propose decisions, but commits are idempotent on decision id and content revision. Decision and audit records are stored durably with minimal evidence payloads, role-scoped access, and profile retention; evidence must not carry unnecessary PII. Concurrent claims resolve with optimistic locking on content revision; stale actions return a conflict for re-read. Appeals reopen removed or limited visibility through under-appeal without erasing audit history. This package defines operational integrity, not whether moderation policies satisfy any jurisdiction's legal requirements.
Scope
- Queue intake, assignment, decision commit, appeal, and enforcement hooks.
- Durable idempotent decision and audit storage with minimal evidence payload rules.
- Evidence access boundaries, forbidden PII fields, and retention profile choices.
- Idempotency keys for automation and human submissions.
- Audit log fields: actor, prior state, new state, reason code, content revision.
- Race handling when two reviewers act on the same item revision.
- Metrics on queue age, appeal rate, and overturn rate.
Outside this block
- Legal sufficiency of moderation policies or government reporting obligations.
- ML model training for classifiers.
- End-user UX copy for appeals.
Contract
- Decision commits require content revision; acting on stale revision returns conflict without partial enforcement.
- Duplicate submission with same idempotency key replays original outcome without double enforcement.
- Terminal states except superseded remain queryable in audit history immutably.
- Appeals may transition from removed or limited visibility to under-appeal only through defined paths.
- Evidence attachments store only minimal operational fields; raw email, government identifiers, and unmasked IPs are forbidden in evidence payloads.
- Decision and audit rows are durable and idempotent on decision_id; exports require audit logging.
- Evidence and audit retention follow profile days; deletion before retention requires compliance-approved hold exceptions.
- Automation cannot silently override a human final decision without elevated role and audit reason.
- Enforcement side effects execute at most once per committed decision id even under retries.
- Queue SLA timers pause fairly when item is awaiting appeal evidence, per profile rules.
Implementation guidance
- Store decision records append-only; project current state from latest valid record.
- Use visibility flags decoupled from raw storage so appeals can restore content without undelete hacks.
- Emit webhooks after durable commit, not before.
Failure handling and safeguards
- If enforcement worker fails post-commit, retry with same decision id until success or operator dead-letter.
- Never delete audit rows on appeal success; add superseding decision instead.
- Rate-limit automation requeues to prevent thrash on contested items.
Verification and operations
- Monitor time-in-queue, conflict rate, duplicate enforcement attempts prevented, and appeal outcomes.
- Sample audits weekly for missing actor or reason codes.
- Execute acceptance scenarios in the target repository; packaged scenarios are not executed evidence.
Adoption assumptions
- Reason codes and SLA numbers in fixtures are profile choices.
- Legal and policy teams own substantive rules independently of this lifecycle contract.