Trust & safety

Keep the platform lawful, synthetic, adult-only, and controlled from day zero.

Nocturne reduces risk by limiting who can create content, what members can submit, and which interaction surfaces exist. Hermes is a moderation router and triage layer, not an autonomous final authority for high-stakes decisions.

Content boundary

Synthetic-only, non-referential content policy

Rule	Meaning	Reason
No real-person targeting	No prompts, captions, tags, or production workflows that intentionally imitate a real person.	Reduces likeness, NCII, defamation, and platform safety risk.
No celebrity/public figure likeness	No "make this look like X" or public-figure sexualization.	Prevents obvious rights and reputational conflicts.
No minors or age ambiguity	No child, teen, school-coded, "barely legal," or ambiguous youth framing.	Absolute safety boundary.
No real reference images without rights	Avoid workflows where a real person's face/body is used as a sexualized source reference.	Protects consent and takedown posture.
AI-generated disclosure	The service should clearly state that published media is synthetic.	Aligns user expectations and reduces deception risk.
Fast takedown path	If a plausible likeness or rights complaint arrives, remove or quarantine first, review second.	Non-adversarial handling is cheaper and safer than fighting edge cases.

Interaction surface design

Risk ladder

Surface	Launch stance	Safety model
Catalog viewing	MVP	Creator-published only; no user publishing path.
Signals / polls	MVP foundation implemented locally	Owner grants finite Signals and creates fixed poll options; members can vote once per poll only when confirmed, entitled, and holding an available Signal.
Request box	MVP foundation implemented locally	Freeform text is screened by deterministic local Hermes rules, accepted only into a private owner queue when allowed/quarantined/locked for review, visible in the gated `/owner` dashboard, and rejected before queueing for no-link/evasion cases; there is no direct public posting or attachment path.
Anonymous reactions	MVP browser controls implemented locally	Predefined CSRF-protected buttons only, aggregated for owner review against visible catalog/media targets; no comments, public member display, or activity feed.
Aggregate unlock goals	MVP foundation implemented locally	Owner-authored goals compute progress from aggregate reactions or fixed poll-option votes and expose only count/threshold progress; no public profiles, leaderboards, or activity feeds.
Rewards / contests	Later	Fulfillment beyond content unlocks requires contest rules, opt-in contact/payment method, and region restrictions review.
Discord satellite	Optional later	Not core product; may expose users to third-party identity/social graph.
Native lounge chat	Deferred	Only after Hermes, policy queues, staffing/ops, and enforcement tooling are mature.
DMs / attachments	No launch path	High abuse risk and poor fit with solo operation.

Current participation guardrails

What the MVP foundation enforces now

Participation records attach to pseudonymous member_id values only.
Voting, request submission, and browser reactions require active entitlement, confirmed self-custody recovery, and CSRF-protected authenticated browser forms or local CLI authority where applicable.
poll_vote and content_request Signals are finite allowances and are consumed when used.
Polls and options are owner-created; members do not create public poll options.
Request bodies are screened by local Hermes rules, stored only as private owner queue data when accepted for review, and reject URL-like content before queueing.
Request records carry moderation state, rule, reason, policy version, and screening timestamp for owner review in CLI reports and the gated /owner dashboard; members only see their own recent private request statuses through /participation.
Reactions are limited to predefined kinds, appear on catalog/media pages as member-local controls, and summarize to owners as aggregate counts only.
Unlock goals are owner-authored, source only aggregate reactions or aggregate fixed-option poll votes, and show active member progress as count/threshold without member identities or rankings.
No chat, DMs, attachments, public profiles, public leaderboards, raw IP logging, or raw user-agent logging exists in the participation schema.

Next safety dependency: calibrate Hermes rules, add enforcement/evidence records, define reward/contest operations, and harden production owner operations before this surface is widened beyond local/private testing.

Hermes

Moderation router and policy assistant

Hermes responsibilities

Pre-screen request submissions now, and future poll suggestions, display names, and chat messages if those surfaces exist.
Classify policy risk and route items to allow, reject, quarantine, mute, or human review states.
Detect forbidden themes, real-person likeness requests, minors/age ambiguity, harassment, doxxing, spam, evasion, and illegal-content indicators.
Maintain review context: rule matched, suggested action, reason, screening timestamp, and policy version.
Support calibration over time without becoming an unsupervised final authority for severe cases.

Hermes limits

No autonomous final decision for CSAM indicators, credible NCII/likeness complaints, or legal escalations.
No direct publishing of freeform member content.
No opaque punishment without auditable rule reason.
No hidden expansion into user profiling.

Moderation states

State machine baseline

State	Use case	Effect
`allow`	Clearly allowed low-risk content/action.	Proceeds normally.
`allow_shadow_logged`	Allowed but low-confidence or pattern-monitoring case.	Proceeds; minimal event retained for calibration/security.
`soft_reject`	Policy mismatch without severe safety risk.	User receives safe explanation and may revise.
`quarantine`	Borderline, suspicious, or uncertain item.	Hidden from public/member surfaces pending review.
`temp_mute`	Spam, repeated unsafe requests, or evasion patterns.	Temporarily blocks participation features.
`lock_review`	Severe policy trigger, legal/safety concern, or payment/abuse conflict.	Locks relevant content/account path pending owner review.
`ban_revoke`	Confirmed severe or repeated violation.	Revokes access and records minimal enforcement evidence.
`report_escalated`	Required or appropriate external reporting channel.	Preserves necessary evidence and records report metadata.

Onboarding rules

Rules that must be unmistakable

You must be an adult in your jurisdiction and at least meet the platform minimum age requirement.
No minors, CSAM, age-ambiguous sexual content, or attempts to request such content.
No real-person likeness requests, celebrity/public figure sexualization, doxxing, harassment, threats, or illegal links.
No spam, scraping, account resale, payment abuse, or evasion attempts.
Violations may lead to immediate revocation; severe safety/legal cases may be escalated through appropriate channels.

UX requirement: show short plain-language rules during onboarding with checkboxes, and link to the longer terms separately.

Takedown posture

Non-adversarial complaint handling

Provide a public report/takedown intake path before large-scale launch; current foundation exposes /report plus owner CLI commands and a minimal gated /owner browser review surface.
Follow the trust/safety escalation runbook for private-VPS SLA targets, severity triage, external escalation triggers, and evidence minimization.
On credible likeness, NCII, rights, or illegal-content complaint: quarantine first.
Collect only the information needed to evaluate and respond; current public intake avoids login, raw IP addresses, user-agent strings, emails, ID documents, uploads, public posts, and public-controlled quarantine.
Harden public intake without identity tracking; current controls are an 8 KiB body cap, hidden honeypot field, boot-secret-backed stateless token, three-second minimum dwell time, 30-minute form expiry, and 200 active-case owner queue cap.
Record complaint kind, local target, optional evidence digest, decision, timestamp, and action taken.
Remove permanently when the complaint is credible or when the risk is not worth contesting.

Implemented foundation: public /report, takedown-report, takedown-report-list, takedown-report-review, and the gated /owner dashboard create/review private cases, record owner/system/external events, and can archive catalog/request targets or mark media assets quarantined before review finishes. Public form abuse controls are intentionally non-identifying and do not create raw IP/user-agent ledgers. The private-VPS escalation runbook now defines owner SLA targets and quarantine-first handling, but jurisdiction/provider review is still required before public operation.

Future chat gate

Conditions before native chat exists

Hermes can pre-screen messages with clear policy reasons.
No DMs, no attachments, no raw URLs, and slow mode by default.
Moderation queues and ban/revoke flow are implemented.
Community rules are tested through request/poll surfaces first.
The business has proven enough retention/revenue to justify the operational burden.