Moderation Policy — Lounge & Co.

🚧 DRAFT — Pre-launch counsel review required. Internal procedures document; describes how Lounge & Co.’s trust & safety team enforces the Acceptable Use Policy and the Community Guidelines. Authored 2026-05-17 as part of the pre-launch legal-doc cascade.

Effective: [PENDING LAUNCH DATE] · Last revised: 2026-05-17 (draft v1) · Audience: Lounge & Co. trust & safety team, founders, on-call rotation, external counsel.

---

1. Purpose and scope

This Moderation Policy describes the internal procedures Lounge & Co. uses to:

• Detect prohibited content + behavior (per AUP §3 and §4)
• Triage flagged items at scale
• Apply enforcement actions consistently
• Handle appeals
• Document decisions for auditability and Section 230 defense
• Manage sub-processor moderation vendors (Hive ships with our next milestone — see ROADMAP N6; Sift Phase 2)

This is not a user-facing document. Users see the AUP + Community Guidelines.

2. Moderation stack

Three layers of moderation operate in parallel:

2.1 Automated detection (Hive — ships with our next milestone)

Pre-MVP posture. Pre-MVP relies on founder triage of the queue described in this section plus member-side reports for surface coverage; Hive auto-classification ships with our next milestone per the BUSINESS_MODEL.md §0.10 pre-MVP lock and the ROADMAP N6 entry. The thresholds + auto-block flows below describe the post-N6 steady state; pre-N6, every flag is founder-triaged from the central moderation_queue populated by the in-app report form.

Hive’s API (post-N6) classifies:

• Image content uploaded to posts, profile photos, venue logos, event imagery — NSFW, violence, drug/alcohol-to-minor depictions, hate symbols.
• Video content uploaded to posts — the same visual classes frame-sampled across the clip, plus the audio track (speech moderation); video additionally passes the dedicated CSAM stage (§3.2) before any processing or visibility, per the quarantine-first pipeline (ADR-021).
• Text content in posts, comments, DMs, venue listings — harassment, hate speech, threats, spam patterns.

Hive returns a confidence score per category. Lounge & Co. sets thresholds per category in config/moderation/hive_thresholds.json:

Thresholds reviewed quarterly + adjusted based on false-positive / false-negative rates from founder triage.

CSAM is NOT a row in this table. The score-band table above is Hive Visual Moderation — content-policy classification (a single per-category confidence score with auto-block / review / allow bands). CSAM detection is a separate, dedicated stage — Hive CSAM Detection (hash + ML) — and it is NOT a “0.50+ Hive-visual-moderation score → block + report” rule (an earlier draft mistakenly listed CSAM as such a row; corrected here). CSAM runs two detectors with a confidence-split reporting path — a known-CSAM hash match reports to NCMEC directly; an ML signal flags novel material and is routed to liaison review first. The full CSAM flow is §3.2; the detection mechanics are ADR-014 (layer 3); the mandatory-reporting obligation is CSAM_NCMEC_REPORTING.md. The visual-moderation score bands here are content moderation, never the CSAM / NCMEC regime.

2.2 User reports (every member surface)

Every post, comment, DM, profile, and venue listing has an in-app report flow. Reports route to the central moderation queue (Phase 1: founder-triage; Phase 2+: trust & safety team).

Report categories presented to user (locked verbatim with the code’s category enum + the AUP §3.8 enumeration — drift is caught by packages/db/test/schema.test.ts):

1. Harassment / Bullying (harassment_bullying)
2. Spam (spam)
3. Off-topic (off_topic)
4. Illegal content (illegal_content)
5. Impersonation (impersonation)
6. Hate speech (hate_speech)
7. Other (other) — required free-text

Sexually-explicit, violent / graphic, and other category cuts not in the user-report taxonomy above are routed through the Hive auto-classifier (post-N6) and via the founder-triage critical-content flow (§3.2) when surfaced as “Other” with a free-text explanation.

User reports are processed under the tier-graduated SLA in Section 4 — best-effort 24-hour response for routine reports with a 72-hour hard cap, and a 4-hour aim / 24-hour hard cap for emergency safety categories. SLA enforced via Better Stack on-call rotation + automatic escalation at 12 hours before hard cap.

2.3 Founder triage + (Phase 3+) trust & safety team

Items in the review queue (Hive flagged below auto-block but above allow threshold + all user-reported items) are reviewed by humans.

Phase 1: founders triage in rotation. Phase 2: dedicated trust & safety reviewer hire when MAU > 5,000. Phase 3: full-time T&S lead at MAU > 25,000.

3. Workflow

Pre-MVP posture. The flows below describe the post-N6 steady state. Pre-MVP, every flow is founder-triaged from the central moderation_queue populated by the in-app report form — Hive auto-classification + the auto-block branches ship with our next milestone (see BUSINESS_MODEL.md §0.10 and ROADMAP N6). The appeals flow (§3.3) ships pre-MVP per N34 with the AUP §6 reviewer-separation rule enforced in code at PATCH /api/superadmin/moderation/appeals/:id.

3.1 Standard flow

Content posted / DM sent  →  Hive scan*  →  [auto-block* | review queue | allow]
                              ↓
                         If review queue:
                              ↓
                         Triage UI in superadmin/moderation
                              ↓
                         Reviewer: [approve | remove | escalate]
                              ↓
                         Audit log entry
                              ↓
                         Notify reporting user (if applicable)
                              ↓
                         Notify content author of action (if applicable)

* Pre-MVP: no Hive scan and no auto-block — every flag founder-triaged from the queue.

3.2 Critical-content flow (CSAM, credible violence threats)

Image uploaded  →  Hive CSAM Detection (hash + ML)  →  on a signal:
                       ↓
                  Quarantine (never published / served)
                       ↓
                  Immediate enforced account restriction
                       ↓
                  Preserve original + account metadata
                  (access-minimized to the reporting liaison)
                       ↓
                  [CSAM hash match]  →  NCMEC CyberTipline report
                  [CSAM ML signal]   →  liaison review first, then report
                  [Violence threat]  →  local law-enforcement coordination via counsel
                       ↓
                  Strict append-only audit entry (csam.detected / csam.preserved)
                       ↓
                  Counsel review within 48 hours

CSAM detection is performed by Hive CSAM Detection — a dedicated capability that is strictly separate from the Hive Visual Moderation policy classifier in §3.1 (the visual-moderation classifier produces NSFW / violence / drugs / weapons / hate per-class scores and never touches the CSAM regime). Hive CSAM Detection runs two detectors, and the reporting path splits by detection confidence:

• Hash match against a known-CSAM corpus is the high-confidence path → preserve-and-report to NCMEC directly.
• ML classifier flags novel material at a confidence the platform does not auto-report on → the image is routed to liaison review first, and a CyberTipline report is filed only after the designated reporting liaison confirms.

CSAM is a zero-tolerance category. Detection is not a single “>0.50 → auto-report” score threshold (that earlier framing conflated CSAM detection with the §3.1 visual-moderation score bands and is corrected here): the hash path reports on a match, and the ML path is liaison-review-first. The preserve-and-report mechanics + the mandatory-reporting obligation live in CSAM_NCMEC_REPORTING.md; the pipeline mechanics live in ADR-014 (layer 3); the product lock is BUSINESS_MODEL §0.11.

3.3 Appeals flow

User receives enforcement action
                       ↓
Within 30 days: User submits appeal via in-app form or [email protected]
                       ↓
Appeals queue (separate from initial-review queue)
                       ↓
Appeal reviewed by reviewer who was NOT involved in original action
                       ↓
Reviewer decision within 14 days
                       ↓
Decision communicated to user via email
                       ↓
Audit log entry on appeal outcome

Appeals decisions are final within the platform; users retain all external legal rights.

Reversal bar — default-keep-removed (locked 2026-05-19). The independent appeals reviewer’s default posture is to uphold the original enforcement action. The burden is on the appellant to provide clear new evidence (additional context, intent clarification, victim-side retraction, evidence of identity confusion, evidence that the original review missed material context). The appeal is overturned only when that evidence materially undermines the original action’s basis.

Default-keep-removed is the deliberate posture for a premium community oriented toward member protection — Lounge & Co.’s brand voice (no engagement maximization, no manipulation patterns) extends to the moderation framing: protection of the reporter and the broader community is the consistent through-line. The MODERATION_POLICY §6 quality-of-moderation metric tracks appeal overturn rate; an overturn rate >15% triggers review of whether the underlying enforcement threshold is set too aggressively.

3.4 Anti-retaliation — reporter identity never disclosed (locked 2026-05-19)

When a user reports content or another member, the reporter’s identity is never disclosed to the reported member. This is a hard non-negotiable rule across every Lounge & Co. surface:

• Enforcement notices to the reported member state the rule violated and the action taken, never the reporter’s name or any identifying information about who submitted the report.
• During appeals, the reporter’s identity remains hidden. The appeals reviewer has access to it; the appellant does not, in any form, ever, regardless of the appeal’s nature.
• Internal audit logs (per ROADMAP N32) capture reporter identity for sub-processor compliance review + counsel-evidence purposes; this data is super-admin-read-only and never surfaces in any user-facing communication.
• The reported member is not even shown an aggregated count of how many people reported them — that count could enable triangulation when the venue or context is small.

The cost of compromising this rule is members declining to report harassment in the future. The chilling effect on reporting is the failure mode this rule exists to prevent. Reporter anonymity is treated as a load-bearing trust-posture invariant; compromise it nowhere, in no edge case, under no pressure.

4. SLA targets

Tier-graduated SLAs (locked 2026-05-19). Aim is the best-effort target; hard cap is the maximum committed response time after which auto-escalation and (for emergency safety categories) auto-conservative-action fires.

Auto-escalation behavior: 12 hours before any item’s hard cap, the super-admin moderation queue surfaces a “about to breach” banner + the system fires email/SMS to founder of record. At hard cap, items auto-promote to “extended review” status — the public-facing tracker shown to the reporting member updates to acknowledge the delay. For emergency safety categories only, the system auto-takes a conservative action (auto-hide the reported content) at 12 hours before hard cap; the action is logged as moderation.auto_conservative_hide in the audit log (operational pre-N32; the hash-chain + OpenTimestamps anchor that earn a stronger evidentiary framing ship with N32).

SLA breaches are surfaced in superadmin-moderation.html and trigger founder on-call escalation via Better Stack.

5. Enforcement consistency

To prevent inconsistent decisions across reviewers, the moderation policy specifies:

5.1 Decision matrix

For each AUP violation category, a default action is specified. Reviewers may escalate or de-escalate based on context but must justify deviations in the audit log.

5.2 Context modifiers

Reviewers may adjust default actions based on:

• Member’s history (clean history → leniency; pattern of borderline behavior → escalation)
• Account age (brand-new accounts more likely to be bad-faith; established accounts more likely to be one-off)
• Public visibility of the violation (a viral hate-speech post does more harm than a DM)
• Intent visible from context (clearly accidental violation vs deliberate provocation)
• Subscription tier (Cellar Club Members held to slightly higher standard given the implicit “this is a connoisseur’s network” expectation)

Deviations from the default action MUST be logged with reasoning in the audit log.

6. Venue-context coordination

When an AUP violation occurs inside a venue workspace:

• Lounge & Co. moderation is platform-level. Member-vs-member violations (DM harassment, post-vs-post harassment, profile reports) are handled by the central trust & safety team. Venues do not moderate Members directly.
• Venue-context violations may be communicated to the venue admin. Example: a Member spamming a venue’s feed with off-topic posts may be flagged to the venue admin via the admin console, who can either escalate to Lounge & Co. or handle in-venue (e.g., revoke approved-membership for a private venue).
• Sustained patterns of Member misconduct at a venue may result in the Member being asked to leave that venue’s membership while remaining on the platform overall. The venue admin can revoke approved-private-venue access; for public venues, the central team can suspend the Member’s specific venue membership without affecting the overall account.
• AUP violations BY a venue (e.g., venue’s published catalog includes prohibited solicitation language) escalate through the venue admin’s primary contact; severe cases result in venue subscription suspension or removal.

Venues do NOT have visibility into Member DM content. Per Community Guidelines, DMs are between Members only.

7. Documentation and audit

7.1 Audit log

Every moderation action generates a structured audit log entry:

{
  "action_id": "uuid",
  "timestamp": "2026-05-17T12:34:56Z",
  "reviewer_id": "founder|t&s-lead|automated-hive",
  "target_type": "post|comment|dm|profile|venue",
  "target_id": "uuid",
  "target_author_id": "uuid (member or venue)",
  "violation_category": "harassment|spam|csam|...",
  "action": "warn|remove|restrict|suspend_temp|suspend_perm|ban",
  "default_action": "warn|remove|...",
  "deviation_reason": "string (required if action != default_action)",
  "context_modifiers": ["history_clean", "tier_2", ...],
  "duration_days": "int (if suspension)",
  "reporter_count": "int (number of user reports)",
  "hive_scores": { "harassment": 0.72, "hate_speech": 0.45 },
  "appeals_eligible": true|false
}

Audit logs retained for 7 years per legal records-retention recommendation. Encrypted at rest. Access-controlled (founders + counsel + auditors).

7.2 Quarterly moderation review

Every quarter the founder + (Phase 2+) T&S lead reviews:

• Action volume by category
• Appeals overturn rate (if >15%, the underlying threshold or default action needs review)
• Hive false-positive rate (sample 50 items/month; if >10% false-positive, adjust thresholds)
• SLA hit rate (target: >95% for 24h initial response)
• Critical-content incidents (root-cause review for every CSAM or credible-violence-threat case)

Overturn-rate denominator framing. The >15% threshold above is computed as count(outcome='overturned') / count(outcome IN ('overturned','upheld')) — the appeal-decision outcomes that represent a substantive review of the enforcement decision. The third terminal outcome, closed_no_action (added by the appeals enum widening in pre-MVP), is procedural closure (appellant withdrew, appeal duplicate, AUP §6 exclusion such as CSAM ban) and is excluded from both numerator and denominator. Counting closed_no_action would inflate the denominator without contributing a calibration signal — procedural closures say nothing about whether the underlying enforcement threshold is set too aggressively. The audit emitter records all three outcomes faithfully; this analytic filters them at query time.

Quarterly review summary documented in docs/internal/moderation-reviews/YYYY-QX.md.

7.5 DMCA takedown procedure

Lounge & Co. will register a DMCA designated agent with the U.S. Copyright Office DMCA Directory per Section 512 before any member-uploaded content is accepted; once registered, the agent’s name, address, and [email protected] contact are published at /dmca.

The designated-agent registration auto-expires and must be renewed with the Copyright Office every 3 years; a named human owner [owner: founder/legal — see launch checklist] holds a calendar reminder to re-file before expiry, since a lapsed registration forfeits the §512 safe harbor.

Takedown notices follow the statutory process:

1. Notice received via DMCA agent (form letter or email to [email protected]). The intake acknowledgment advises notice-senders that, under 17 U.S.C. §512(f), knowingly materially misrepresenting that material is infringing creates liability for damages.
2. Verify notice contains the six statutory elements (identification of work, identification of infringing material, statement of good faith belief, accuracy + perjury statement, contact info, signature).
3. If valid, remove or disable access to the identified material within expeditious standard (target: 24 hours from validated notice).
4. Notify the alleged-infringer Member with copy of notice + counter-notice procedure. The counter-notice procedure advises counter-notice-senders that, under 17 U.S.C. §512(f), knowingly materially misrepresenting that material was removed by mistake or misidentification creates liability for damages.
5. If counter-notice received (also six statutory elements), wait 10–14 business days; if the complainant has not filed a court action within that statutory window, restore the material.
6. Audit log entry for the takedown + restoration if applicable.

Repeat-infringer policy (§512(i) implementation). Each validated takedown increments an audit-logged per-account copyright-strike counter. Per the AUP repeat-infringer termination policy, 3 validated copyright strikes within a rolling 12 months → permanent account termination; no sham reinstatement (cross-ref AUP §5.8 and the §5.1 enforcement matrix). The policy is reasonably implemented in the sense required by BMG Rights Management v. Cox — the strike counter plus the moderation audit log give Lounge a concrete, tracked, enforced mechanism for terminating repeat infringers in appropriate circumstances, not merely a paper policy.

The strike mechanics are specified precisely enough to satisfy the BMG v. Cox “reasonably implemented” standard:

• (a) Strike attaches. A strike attaches to the account when a takedown notice is validated (six statutory elements confirmed) AND the identified content is removed or disabled. A notice that fails validation, or that is withdrawn before the content is disabled, does not attach a strike.
• (b) Strike voids. A strike is voided and removed from the counter if a successful counter-notice results in the content being restored, or if the notice on which it rested is later found invalid. A voided strike does not count toward the rolling-12-month termination threshold.
• (c) Account-level tracking across aliases. Strikes are tracked at the account level. Where Lounge identifies that known aliases or re-registrations belong to the same person, the policy applies across those accounts — a repeat infringer cannot reset the counter by re-registering.
• (d) Pre-termination review. Before termination, a documented review confirms the current strike count and the absence of any successful counter-notice against the strikes being counted. The review and its outcome are recorded in the moderation audit log.

Counsel involvement required for any takedown notice involving content that is clearly transformative or non-infringing on its face, or for any pattern suggesting abuse of the DMCA system.

8. Sub-processor vendor management

8.1 Hive

• Contract execution: pre-launch
• DPA: Hive’s standard DPA + Lounge & Co. addendum specifying: no training on customer data; encryption in transit + at rest; 30-day data retention max
• Disclosed in: Member ToS, Platform Privacy Policy, Venue DPA Template, superadmin-subprocessors.html
• Quarterly review: thresholds + false-positive rate + Hive’s policy updates

8.2 Sift (Phase 2)

Added Phase 2 for trust/safety signals (account-takeover detection, content velocity anomalies). Same vendor-management discipline as Hive.

8.3 Trust & safety team scaling

9. Section 230 posture

Lounge & Co. is a “provider of an interactive computer service” under 47 U.S.C. § 230(c)(1) and benefits from Section 230 immunity for member-published content. The 2024–2026 erosion line (Anderson v. TikTok, Lemmon v. Snap) turns on the recommendation-vs-hosting distinction, so the posture is structured in three explicit layers rather than treated as one undifferentiated “platform content” claim.

Layer (i) — Hosting member UGC. Member-authored posts, reviews, photos, and messages are third-party content. Hosting, storing, and transmitting them is immunized under 47 U.S.C. §230(c)(1) — Lounge is not the “information content provider” of this material.

Layer (ii) — Pattern-A ranking, display, and citing of member UGC. §230(c)(1) immunity reaches not only hosting (layer i) but also the ranking, display, and citing of member-authored UGC — posts, ratings, and tasting notes ordered in feeds. Algorithmic ordering of that member UGC on the main surface uses transparent, content-neutral signals; it is curation of third-party content, not Lounge’s own speech, so §230(c)(1) immunizes the act of ranking the third-party posts. Keeping this layer scoped to ranking member UGC (rather than concierge output) is load-bearing: it preserves the §0.6 concierge-ranking framing while keeping the §230 immunity claim honest.

Layer (ii-backup) — First Amendment editorial discretion. Separately and independently of §230, the platform’s editorial-curation choices in ordering member UGC are expressive activity protected under Moody v. NetChoice (2024). This is a distinct defense from the §230(c)(1) third-party-content immunity above — the First Amendment shield protects the act of curating as Lounge’s own expression, whereas §230 protects Lounge from liability for the third-party content itself. The two are presented as separate, layered defenses, not one blurred claim.

Layer (iii) — Concierge output and Featured Venues are Lounge’s own first-party product. Three things are Lounge & Co.’s own first-party / product-design output, NOT third-party content, and therefore fall outside §230 entirely: (1) the concierge’s recommendations of venues, products, and pairings; (2) the concierge’s generated prose (a synthesized recommendation sentence the AI authors, as distinct from the member UGC it ranks or cites); and (3) the Featured Venues shelf. None of these is defended by §230 — the defense is instead the no-warranty / “advisor, not authority” / informational-only / content-neutrality-and-labeling framing in Member ToS §8.5.

To maintain §230 immunity where it applies (the hosting and member-UGC-ranking of layers i–ii) and document good faith across all layers:

• Good-faith moderation under documented policy. This document, paired with the AUP and Community Guidelines, is that documented policy.
• Notice-and-takedown for DMCA + clear AUP violations demonstrates good-faith effort to remove violating content.
• Audit trail of moderation decisions is the evidentiary record courts look for in Section 230 challenges.

Statutory carve-outs from §230. §230 immunity is not absolute. Two exceptions are expressly acknowledged:

• FOSTA-SESTA (sex-trafficking). §230(e)(5) withdraws immunity for conduct violating federal sex-trafficking statutes (18 U.S.C. §1591 / §2421A). The 21+ TOT-gated, moderated, single-vertical posture does not exempt Lounge from this carve-out; trafficking-adjacent content routes to the emergency-safety critical-content flow and law-enforcement referral.
• Intellectual-property claims. §230(e)(2) excludes IP claims from §230 immunity; copyright is governed instead by the DMCA §512 safe harbor (see §7.5).

Ranking vs paid placement. Pattern-A ranking on the main flow excludes paid placement entirely — no venue buys rank in the main surface. The separately-labeled Pattern-C “Featured Venues” shelf IS paid placement and is Lounge & Co.’s own commercial speech, disclosed as such and held outside the content-neutral main flow (cross-ref Community Guidelines and §0.6).

Counsel review of this policy + the AUP + the ranking principle is required pre-launch to confirm the documented posture lines up with current Section 230 jurisprudence.

10. Changes to this policy

Material revisions to this Moderation Policy require:

1. Counsel review (~$500–1,500 per revision cycle).
2. Trust & safety team review for operational feasibility.
3. Update of any threshold values referenced in config/moderation/.
4. Notification to existing venue subscribers if the changes affect venue-level enforcement.

Revision history: