Publishing & Sharing

Publishing is the moment your work goes from "saved on my account" to "visible to other people." RoleCall treats it as a deliberate, versioned act — every publish creates a frozen snapshot, every snapshot has a number, and every snapshot is what your audience subscribes to. You can pull a version back, push a new one over the top, or sit at a private draft forever.

This page covers the whole lifecycle: the status states a piece of content moves through, the Publish Version modal you fill in to push an update, what each content type ships with when it goes public, what changes once you've published, how versions and subscribers interact, what fork rules look like at publish time, and how PlotLight (the companion app) participates in the same lifecycle.

If you've read Characters and Discovery, Library & Forking, most of the terms here will already be familiar — this doc focuses on the publish action itself and everything that hangs off it.

---

The Lifecycle, In Plain Language

Every piece of shareable content — every Character, Preset, Lorebook, Persona, Prompt, Guided Response, Regex Script, and Series — moves through a small set of status states. The status is the single switch that controls who can see the content and where it appears.

Status	Who can see it	Appears in Discovery	Notes
Draft	Only you	No	Work-in-progress. The default state for anything new or imported.
Private	Only you	No	Finished, but personal. Used when you want to keep something polished but not public.
Published	Everyone	Yes	Live on Discovery. Other users can subscribe, rate, favourite, and rewrite it.
Pending Review	You and moderators	No	Sent here when a creator on the free Audience tier submits to publish — sits in a queue for staff approval.
Archived	Only you (read-only)	No	Soft-deleted. The content is hidden from your library views but kept around so existing chats and forks still work.

Draft and Private look identical from the outside (both invisible to everyone else), but they read differently in your own library: Draft flags "this is still in progress," while Private flags "this is finished, just not public." Tooling can use that signal — for example, the library filter has separate Draft and Private chips.

Once a piece of content moves to Published the first time, it gets a published_at timestamp that sticks even if you later flip it back to Private. That timestamp is what Discovery uses to compute "newest," what your Portfolio uses for activity feeds, and what subscribers see in their version history.

When You'd Use Each Status

• Draft — While you're still writing. The autosave system stamps a delta snapshot every 30 seconds against your draft, so you can always roll back internally without anyone else seeing the half-finished state.
• Private — When you've finished something but it's a personal project, or it embarrasses you, or it depends on private context you don't want to share. Private content still appears in your own Discovery searches if you filter by "Mine," and it can still be added to Series, scenes, and your Portfolio's owner-only blocks.
• Published — The real release. Anyone can find it, subscribe, rate, and rewrite. Audience-tier creators (the free plan) land in Pending Review when they push Publish — see below.
• Pending Review — Set automatically when a free-tier creator submits to publish. Filtered out of Discovery at the database layer so nothing leaks. Staff approves (flips to Published) or rejects (flips back to Private). You keep working with the content during review.
• Archived — When you want something out of your active library without losing the data. Chats that referenced an archived item still work; the content just stops showing up in pickers and Discovery.

---

The Publish Version Modal

The Publish Version modal is the same modal across every content type. It opens when you click Publish from a content's editor — whether that's the full editor page, the in-chat character panel, the preset viewer, or the lorebook editor. The fields below are universal; type-specific gotchas live in the per-type sections later.

Header

Element	What it says
Title	"Publish New Version"
Content name and version transition	Shows the content's name and the version step, e.g. "Coriolanus Vance · v3 → v4". For the very first publish it reads "First version" instead.
Accent rail	The thin top-line stripe and accent color come from the content's signature color, so the modal feels like part of the same item.
Close button	Closes without publishing. No data is sent.

Version Title (Optional)

A short freeform label for this version. Used as the badge in version history lists — "Performance Tuning," "Fixed Greeting Bug," "Big Personality Overhaul." If you skip it, the version is just shown by its number.

The Changelog — Per-Field Change Reasons

The modal computes the changelog automatically by comparing your current state against the last published snapshot. Each detected change becomes a row showing:

• An icon and color matched to the change type
• A plain-language description of what changed (e.g. "Description was modified," "Added 3 lorebook entries," "Temperature changed from 0.7 to 0.85")
• A chevron that expands the row to reveal a "Why this change?" input — your per-field change reason, shown to fans alongside the changelog row

Change types are tagged so version history reads at a glance:

Type	Icon	Used For
Modified	Pencil	A prose or scalar field was edited
Added	Plus	A new item was inserted (lorebook entry, prompt, alt art)
Removed	Minus	An item was deleted
Setting	Sliders	A toggle, sampler, or numeric setting was changed
Reordered	Arrows	Items were moved around (prompt order, lorebook entry sort)
Renamed	Edit	A name or identifier was changed

If you haven't made any changes since the last publish, the modal shows a "No changes detected" notice and disables the publish button. For a first version, it shows a sparkles icon and an "Initial version" notice — there's no diff to compute because there's nothing to diff against.

Release Notes (Optional)

A multi-line textarea that takes Markdown. This is the long-form "what's new" message — bullet points, screenshots-via-link, thanks to playtesters, whatever you want subscribers to read alongside the changelog. The version history modal renders release notes underneath the changelog list, so subscribers see both.

Fan Notification Notice

Below the release notes is a "Your fans will be notified about this update" callout. Anyone with the content in their Repertoire with auto-update on gets an in-app notification when you publish. Anyone with auto-update off sees an "Update Available" badge the next time they open the content. Forks don't get a notification — they only see updates when they actively check for upstream changes (see Forking & Lineage).

Tag Validation (Lorebooks)

When publishing a Lorebook, the modal runs a tag check first. If the lorebook has zero tags or is missing a required category, an amber warning bar appears at the top of the modal and the Publish button is disabled until the missing tags are added. Click into the Tagsheet wizard, fill the gaps, and the warning clears.

Visibility Selector (Footer)

A two-segment toggle at the bottom of the modal:

Option	Effect
Private	Saves the version but doesn't make it public. Useful for landing changes against private content.
Public	Pushes the version live. For free-tier creators, this actually lands the content in Pending Review (see below).

The toggle defaults to the content's current status — Published stays Published, Private stays Private. Choosing Public on a Draft is the most common path: it flips the status to Published and creates the v1 snapshot in one shot.

What Blocks Publishing

The modal will refuse to submit if:

• There are no changes to publish and it isn't a first version
• Lorebook tag validation fails (missing required tags)
• The content can't reach the publish endpoint (you're offline, server error, etc.)

Other checks live on the API side and the modal surfaces their error message inline:

• Missing required fields — Each content type has its own required field list. Characters need a name. Lorebooks need at least one entry. Presets need at least one prompt or sampler setting.
• Content rating mismatch — If a character is rated After Dark but has no trigger warnings set, publish is rejected with a clear "After Dark content requires at least one trigger warning."
• Identity protection — Characters with the mirror_base flag on alt arts that conflict with the base character won't publish until the conflict is resolved.

---

The Publish Modal, Per Content Type

The modal is universal, but each content type has specific quirks at publish time. Here's what to expect.

Characters

Characters have the richest publish flow because they bundle the most fields. When you publish a character, the snapshot includes:

• Every prose field (description, personality, scenario, first message, example dialogue)
• The system prompt and post-history instructions
• The Casting Card (stage name, full name, title, age, pronouns, tagline, signature colors, named-color palette, depth injections)
• Alternate art variants — every variant is captured in the snapshot with its overrides
• Bundled lorebooks (just the link — the lorebook content itself lives in its own snapshot)
• Linked regex scripts (also just links)
• Tag intensities (from the junction table)
• Trigger warnings with their severity levels
• Content rating
• Embedded extensions (V3 fields, Visual Novel data, etc.)

Required to publish:

• A non-empty Stage Name
• The required tag categories filled in via the Tagsheet wizard (character cards need Card Type + Gender + at least one Genre)
• At least one trigger warning if rated After Dark

The bundled lorebook decision. If the character has linked lorebooks marked "Creator Recommends," they ship with the snapshot as recommendation pointers. The actual lorebook content has to be published separately — the character only carries the link. Subscribers who add the character to their Repertoire will see the bundle in their character panel and can opt into each recommended lorebook one by one (see Characters · Linked Lorebooks).

Casting card image requirement. A character without a casting card image will publish, but it's worth setting one — characters without images get a placeholder silhouette on Discovery cards, which earns fewer clicks. The Discovery card uses the casting card image as the background.

Presets

Presets are the second-most-complex publish target. The snapshot includes:

• All sampler settings (temperature, top-p, top-k, min-p, top-a, penalties, max tokens, max context, post-processing)
• The full prompt stack — every prompt with its identifier, role, content, enabled flag, injection position, injection depth, and sort order
• Categories (folder structure) with parent_id and sort order
• Per-character prompt orders (the per-character override list)
• Behavior flags, template formats, API options, media settings, generation settings, raw settings
• Style tags, icon, accent color

Required to publish:

• A non-empty name
• At least one prompt or a sampler-only preset has to opt in to the sampler-only flag

Release notes per-prompt change. When you've moved, renamed, or edited individual prompts, the changelog surfaces each prompt as its own row with the "Why this change?" expander. This means a preset publish can have a dozen per-prompt change reasons, all surfaced in the version history modal so subscribers can read what changed in their stack at the per-prompt level.

Sampler snapshot. Every published version captures the full sampler row, even if you didn't touch any sampler. This is how subscribers see "you changed temperature from 0.7 to 0.85" — both sides of the comparison are in the snapshots.

Lorebooks

Lorebooks fan out the changelog by entry, not by field. The snapshot includes:

• The lorebook's metadata (name, description, type, genre, fandom, scan depth, token budget, recursive scanning flag)
• Every entry with its keys, content, position, depth, role, sticky/cooldown/delay, probability, group, displayIndex, exclusion flags

Required to publish:

• Tag validation must pass (the modal blocks if it doesn't)
• At least one entry in the lorebook

Entry-count surface. Lorebooks with very few entries (under 3) get a soft warning in the editor — not on the publish modal, but in the lorebook's overview header. There's no hard cap, but a one-entry lorebook is rarely useful and surfaces as low-quality on Discovery.

The Recommended-By-Character flag. When a character is published with a bundled lorebook, the lorebook itself doesn't need to be published — but if it isn't, subscribers can't actually load it. So characters with bundled lorebooks get a yellow callout at publish time: "Your linked lorebook 'X' is still a draft. Publish it too, or subscribers won't be able to use the bundle."

Personas

Personas are much lighter than characters but still publishable. The snapshot includes:

• The persona's content (the actual persona text)
• Name, description, image URL
• Tags with intensities
• The display fields (signature color, etc.)

Required to publish:

• A non-empty name
• A non-empty content body

There's no per-field change reasons for personas because a persona only really has one field's worth of body text — the content. The changelog will usually be a single "Modified content" row.

Prompts

A standalone Prompt is the smallest publishable unit — a single prompt snippet (system, user, or assistant role) you want to share or reuse. The snapshot includes:

• Content, role, category
• Identifier (used by other presets that want to reference this prompt by name)
• Display order metadata

Required to publish:

• A non-empty name
• A non-empty content body

Prompts publish cleanly and predictably — the modal usually shows one or two changelog rows, and subscribers see a tight version history.

Guided Responses

Guided Responses (the saved "swipe in this style," "correct in this tone," "spellcheck this output" templates) publish the same way. Snapshot:

• Content, type (guide/correction/spellcheck/prefill/custom), category (situational/thinking/clothes/state/rules/custom)
• Injection role and auto-trigger flag
• Position order and visibility flag

Required to publish:

• A non-empty title
• A non-empty content body

Regex Scripts

Regex scripts publish their entire rule list:

• Script-level metadata (name, description, scope)
• Every individual rule with find pattern, replace pattern, flags, scope flags, sort order

Required to publish:

• A non-empty name
• At least one rule

Regex publishing is unusual because the change preview uses syntax highlighting — when you change a regex rule, the changelog shows the old pattern and the new pattern side by side in monospace so subscribers can see exactly what's been altered.

Series

A Series is a bundle of references to other content (a character + its preset + its lorebook + a persona, for example). When you publish a Series, the snapshot captures:

• The series metadata (name, description, cover image, genre, fandom, recommended play order, compatibility notes)
• The ordered list of item references — each item is {content_type, content_id, position}

Required to publish:

• A non-empty name
• At least one item

The "all items must be published" rule. A Series is a manifest, not a container — it points at other content. If any of the items in your Series are still drafts, the Series will technically publish but subscribers won't be able to load the missing items. The Series editor flags this with a warning chip on each unpublished item: "This item is still a draft."

---

What Changes When You Publish

The moment you click Publish, a few things happen in sequence:

1. A snapshot is taken. Every field that matters to the content is captured into a frozen row in the snapshot table, with an incremented version number.
2. The content's pointer is updated. The content row's current_version_id is set to the new snapshot, and the version_count ticks up.
3. The status is set atomically with the snapshot. If you're publishing a Draft for the first time, the snapshot creation and the status flip happen in the same transaction, so there's no in-between state where the content is "Published with no version yet."
4. Subscribers with auto-update get bumped. Anyone with the content in their Repertoire with auto_update=true has their subscribed snapshot pointer moved to the new version automatically.
5. Subscribers without auto-update get a flag. The new version is marked as latest_snapshot_id on their repertoire row — they see an "Update Available" badge until they bump.
6. Fans get a notification. A row is inserted in the update-notifications table for each fan. You can suppress this from the publish call (Save Override flow), but the default is to notify.
7. Discovery cache is invalidated. The Discovery page caches don't show stale data for more than a few seconds after a publish.

Content Becomes Locked At The Moment Of Publish

Once a version is published, the snapshot is immutable. You can't go back and edit "what v3 of this character looked like." If you want to change something, you publish v4. The old snapshot stays in history forever.

This is why the Save Draft / Save Override / Publish Draft split exists in the in-chat editor:

Save Mode	Visible To	When To Use
Save Draft	Owners — saves to the base character	When you're the creator and want to land changes against the live content. Subscribers will not see these changes until you click Publish Draft to Everyone.
Save Override	Just you, per-chat	When you're a non-owner who wants to tweak the character for your own chats. The original creator's version isn't touched; you have a personal layer on top.
Publish Draft to Everyone	Owners with pending draft changes	When you've made owner-level changes and you're ready to push a new version. This is what opens the Publish Version modal.

In other words: edits between publishes don't ship to subscribers. They sit on the content row, but subscribers continue to see the last-published snapshot. When you finally hit Publish Draft to Everyone, the modal opens, you fill in the changelog reasons, and the new snapshot ships.

Republishing — The Diff Modal

When you re-publish content that's already public, you're creating a new version on top of the existing chain. The Publish Version modal's changelog section is the diff modal in miniature — it shows every field that changed between the current draft and the last-published snapshot.

For a richer side-by-side comparison, the full Diff Modal is reachable from the character panel and the lorebook editor:

• Left column — the last-published snapshot (read-only, dimmed). Changed fields are tinted red and labeled "Changed."
• Right column — your pending draft (editable). Changed fields are tinted green and labeled "Modified."
• The header shows how many fields differ.
• You can edit directly in the right column — your edits auto-save to the draft.

The Diff Modal is most useful for big preset overhauls or lorebook restructures, where you want to see every change at once before committing to the publish.

---

Where Published Content Surfaces

When something goes public, it shows up in five different places. Each surface filters and sorts the catalogue a little differently, but all five draw from the same publish event.

In Discovery

Discovery is the public catalogue — the main "browse anything" surface, available in both RoleCall and PlotLight. A newly published item appears:

• In the type-specific feed — Characters, Presets, Lorebooks, Personas, Prompts, Guides, Regex Scripts, and Series each have their own Discovery view.
• In the Latest carousel — Sorted by published_at descending. Newest items go to the front. Item appears here within a few seconds of publish.
• In Trending — A weighted score combining recency, favorites, ratings, chat counts, and fork counts. Newly published content takes a few hours to climb (or never does, if no one engages).
• In tag-specific pages — If a tag is set on the content, the item appears under /discovery?tags=<slug> immediately.
• In your Profile — Your published portfolio of all public content, visible at your creator profile URL.

In Your Library

Your Library always shows your own content regardless of status — drafts, privates, and publishes all sit side by side. After publish, the item picks up a "Published" badge in the library row and the row's actions change to include Unpublish, View Versions, and View Public Page.

On Your Portfolio (PlotLight)

Your PlotLight Portfolio can showcase published content via several block types — Featured Pin, Featured Character, Curated Carousel, Latest Drops, Content Gallery, Repertoire Showcase. Most of these auto-update when you publish new content (Latest Drops literally ticks within a few seconds; Featured Character with mode "Latest" auto-picks your most recent publish). Owner-managed blocks (Featured Pin, Curated Carousel) require you to manually pin or curate.

On Your Backstage Console (PlotLight)

The Backstage Console is PlotLight's management view — your creator's office. It's where you see:

• Your draft queue (everything still in draft across all content types)
• Your private library (everything in private status)
• Your publish history (a timeline of every snapshot you've shipped)
• Your fans (people who've added your content to Repertoire)
• Your reports inbox (reports filed against your content, with the appeal flow)
• Your moderation actions (when content has been actioned by staff)

Newly published content appears here under Recent Publishes and updates your fan-count metric immediately.

In Stage Whispers (PlotLight)

If you publish whispers from a character — short in-character posts your characters can publish to a public feed — they appear on PlotLight's Stage Whispers timeline. Whispers are a separate publish lifecycle from the eight main content types (they don't versioned, they just exist), but they do follow the same draft/private/published statuses for individual posts.

---

The PlotLight vs RoleCall Publishing Split

RoleCall and PlotLight are two apps that share one database, one auth, one taxonomy, and one publish lifecycle — but they're aimed at different surfaces. Here's how publishing maps across the two.

Content / Surface	Where you build it	Where it's discoverable
Characters	RoleCall (editor + in-chat panel)	Discovery in both RoleCall and PlotLight
Presets	RoleCall (preset editor)	Discovery in both apps
Lorebooks	RoleCall (lorebook editor)	Discovery in both apps
Personas	RoleCall (persona editor)	Discovery in both apps
Prompts	RoleCall (prompt editor)	Discovery in both apps
Guided Responses	RoleCall (in-message menu + library)	Discovery in both apps
Regex Scripts	RoleCall (regex editor)	Discovery in both apps
Series	RoleCall (series builder)	Discovery in both apps
Portfolio	PlotLight (block editor)	PlotLight only (plotlightstudios.com/portfolio/<name>)
Stage Whispers	RoleCall (composed via character actions) or PlotLight (composer)	PlotLight (the Whispers feed)
Model rubric contributions	PlotLight (rubric panel)	PlotLight (the model leaderboard)
Plotpoints	PlotLight (Plotpoints page)	PlotLight

The split is intentional. RoleCall is the creation surface — it's where you build content with full editor chrome, in-chat preview, and version control. PlotLight is the publishing and social surface — it's where work meets an audience: portfolios, whispers, fan activity, model conversations, plotpoints discussion.

The lifecycle itself is shared. If you publish a character on RoleCall, it appears in both apps' Discovery within seconds. If you flip a character to Private on RoleCall, it disappears from both apps' Discovery within seconds. There's no separate "publish to PlotLight" action for the eight core content types — public means public, everywhere.

---

Versioning & Snapshots

Every publish creates a versioned snapshot. The snapshot has:

• A version number (1, 2, 3...) that increments with each publish
• A creation timestamp
• The full content state at that moment (every prose field, every entry, every setting)
• Metadata: your version title, your release notes, your per-field change reasons, your changelog

Once a snapshot is created, it never changes. The content row's pointer can move forward to a newer snapshot (republish) or backward to an older one (revert), but the snapshots themselves are append-only history.

Version History Modal

Every published item has a Version History modal accessible from the editor and from the public detail page. Subscribers see the same modal you do.

Element	Shows
Version list	Every snapshot, newest first, with version number, title, created date
Per-version changelog	The per-field changes recorded at publish time, with reasons
Per-version release notes	The Markdown release notes you wrote
Diff against previous	Click any version to see the diff against the version before it

For your own content, the modal also surfaces a Restore This Version action — see "Reverting" below.

Subscribers See the Latest Version By Default

When someone subscribes to your content via Repertoire, their subscription pointer is set to the latest published snapshot at the moment of subscribe.

• If they leave auto-update on (the default), the pointer auto-advances every time you publish a new version. They always see your latest.
• If they turn auto-update off, the pointer is pinned to whatever version they were on. They see an "Update Available" badge on the content but don't see the new content until they manually bump.

They can also pin to a specific older version via the Repertoire's version history modal — useful when a creator's update changes something a subscriber doesn't want.

Forks Are Independent

A fork (Rewrite) is a deep copy of a snapshot at the moment of fork. After that point, the fork lives its own life — it doesn't auto-update from upstream. The original creator can publish a thousand new versions and the fork keeps its frozen state.

The fork can pull updates from upstream by going to the Character Panel → Compare → check the "Upstream changes available" badge. But it's cherry-picking, not auto-merging — the fork owner chooses which fields to sync.

"Forked From" Lineage Is Permanent

When a fork is created, the new content row records:

• forked_from_id — the direct parent (the snapshot it was forked from)
• original_creator_id — the creator at the very top of the fork chain
• forked_at — timestamp
• An attribution string with the original content name at fork time

This lineage stays attached forever, even if:

• The original creator deletes the parent
• The original creator privates the parent
• The original creator is banned or suspended

Forks survive their upstream. They become orphans (forked_from_id still points at a row that doesn't exist anymore, or to a row the user can't see), but the original_creator attribution stays so credit doesn't evaporate.

Reverting to a Previous Version

For your own content, the Version History modal has a Restore This Version action. Clicking it doesn't rewind the snapshot history — instead, it creates a new version with the old snapshot's data, and adds a metadata flag noting "this is a rollback from version X." Subscribers see the new version appear in their history just like any other publish.

The point of doing it this way is that history is append-only and auditable. You never lose what was published, even when you've decided to undo it.

---

Fork Rules at Publish-Time

Fork rules are the terms a creator can attach to their published content to set expectations for anyone who Rewrites it. Rules live on the content row and surface as a checklist anyone has to acknowledge before forking.

The Four Postures

Fork rules are configured on the creator panel via a Posture chip. Each posture corresponds to a similarity ceiling and per-field caps:

Posture	Overall ceiling	Identity fields	What it means
Loose	85%	65%	"Reuse freely, just don't carbon-copy me." Fork rules barely engaged unless someone copies you literally.
Standard	70%	50%	"Make it your own." Identity fields get tighter caps — your description, personality, scenario can't all be near-identical.
Strict	50%	30%	"Significant departure required." Identity fields are policed hard — forks have to substantively rewrite the core.
Custom	You set	You set	Manual control over both the overall ceiling and per-field caps.

Each posture caps how similar a fork's content can be to the original before the system flags it. The check uses a Jaccard token overlap on each weighted field (description, personality, scenario, first message, example dialogue) and rolls up to an overall percentage. If the fork breaches either the overall ceiling or any per-field cap, the fork modal raises a hard block until the user accepts the creator's rules.

Per-Field Auto-Tightening For Identity-Heavy Fields

Identity fields (description, personality, scenario for characters; settings + source format for presets) get tighter caps than the overall ceiling at every posture. The logic is straightforward: if someone copies your character's description word-for-word but changes the scenario, that's still your character. Identity matters more than setup.

The Ground-Rules Checklist

In addition to the similarity caps, creators can write up to 8 ground rules — short freeform expectations (each capped at 280 characters):

• "Don't change the pronouns."
• "Please credit me in the rewrite's creator notes."
• "No AU forks — keep them in the canon setting."
• "Don't publish forks to After Dark."

These get listed in the fork acceptance modal as a numbered checklist. The fork won't proceed until every checkbox is ticked. The cap on 8 entries is a deliberate UX choice — long lists of ground rules don't get read.

Acknowledgement Flow Blocks Fork Until Accepted

When someone clicks Rewrite on content with fork rules attached:

1. The fork API returns a 409 conflict with the fork rule attached
2. The Rewrite modal opens with the rules visible:
   • The posture chip
   • The per-field caps as a small diagram
   • The freeform ground rules as a checklist
   • The creator's freeform notes (legacy field)
3. The user has to actively click "I accept these rules" and tick every ground rule before the modal will let them proceed
4. Once accepted, the API is called again with acceptForkRules: true and the fork proceeds

The acceptance snapshot — which exact rules the user agreed to, at what time — is recorded on the fork itself. So if a creator changes their rules later, existing forks have proof of the version they accepted.

Tags Are NOT Checked

A deliberate design choice: anyone can use the same tag set as the original. Reusing the same fandom + setting + archetype tags isn't a fork — it's just being in the same niche.

Unlinking a Fork

If a fork's owner wants to drop the lineage entirely — declare the work as fully their own and detach from the upstream — they can use the Unlink Fork action on the fork's editor. This:

• Removes forked_from_id (lineage broken)
• Clears original_creator_id (attribution removed)
• Resets forked_at to null
• Doesn't change the content itself

Unlinked forks behave as independent originals from that point on. The action is permanent — there's no relink — and the audit log records the unlink event in case anyone ever asks where the work originated. Creators who fork-rule-protect their content do so partly to make unlinking feel like a real social commitment, not a stealth move.

---

Unpublishing

You can flip a published item back to Private or Draft at any time. The status change is immediate and applies to Discovery within seconds.

What Happens To Subscribers

When you unpublish:

• Existing snapshots stay. A subscriber who has the content in their Repertoire keeps seeing the version they were subscribed to. The data is in the snapshot, not the live content row, so it doesn't disappear.
• No new versions can be published while private. The Publish Version modal will reject — the content has to be Published (or you have to use targetStatus to flip back to Published as part of the version push).
• Update notifications stop firing. Subscribers no longer get auto-update bumps because there are no new publishes.
• The content vanishes from Discovery and from your public profile within a few seconds.
• The content's URL still resolves for subscribers and fork owners (so their links don't 404), but only the snapshot view, not the live page.

What Happens To Existing Forks

Forks are independent. They survive their upstream unconditionally:

• The fork's content row stays in place
• The fork's lineage attribution stays (forked_from + original_creator) even if the upstream is gone
• The fork can still be edited, published, and rewritten

What Happens To Ratings And Favorites

Ratings, favorites, comments, and reviews on unpublished content stay attached to the content row — they don't disappear. If you re-publish later, all the engagement returns. If you delete the content permanently, the engagement is also deleted via cascade.

The visible rating average / favorite count on Discovery cards is computed live, so unpublished content drops out of Discovery aggregates immediately.

---

Publishing Limits

Publishing limits vary by account — you'll see your current allowance reflected in your Library and on the publish dialog when you hit a cap.

The Pending Review Queue

Some accounts cannot publish directly to Discovery and instead enter a moderation queue. When such an account clicks Publish:

1. The publish API resolves the account's access level via a server-side RPC
2. If direct publishing isn't available, the requested status of "published" is rewritten to "pending_review"
3. A row is inserted into the moderation reports table with queue_type='submission'
4. The publish operation completes normally — version snapshot is created, content row is updated — but the status is pending_review not published
5. Discovery queries filter on status IN ('published', 'unlisted'), so pending_review content is invisible
6. Staff reviews the submission via the PlotLight submission queue page

Path back to Published: Staff either approves (flips the status to "published") or rejects (flips it back to "private" with optional moderator notes). The creator is notified of the outcome via the in-app notification system.

Why this gate exists: The moderation queue keeps Discovery quality high and reduces spam.

---

Pending Review In Detail

The Pending Review state is its own thing, distinct from any other status, and worth understanding.

When Content Lands In Pending Review

• Queued publish. As described above, accounts without direct publish access land here automatically when they publish.
• Content flagged for staff review. If a piece of content is reported and the report is upheld for "needs staff review" (rather than auto-removed), the content moves into pending_review while staff investigates.
• Content rating mismatch. If content is flagged for an incorrect content rating (e.g. published as All Hours but staff sees it should be After Dark), it lands here pending re-tagging.

What You Can And Can't Do

• You can keep editing. Drafts and overrides work normally.
• You can keep using it in your own chats. The content keeps functioning for you.
• You can't publish a new version while in pending_review. The Publish Version modal will reject with "Content is awaiting staff review."
• The content is invisible on Discovery for everyone except you and staff.

Path Back

• Staff approves — Status flips to "published" and the content rejoins Discovery.
• Staff rejects — Status flips back to "private" (or "removed" for severe violations). You get a notification with the reason. For private, you can address the issue and resubmit. For removed, you have an appeal flow.

---

Archived Content

Archived is the soft-delete state. Content can be archived two ways:

Triggered by	When
User	You click Archive in the content's editor or library row
System	Automatic archive after long inactivity (rarely used; reserved for very old content)

Archived content:

• Vanishes from your library views by default (toggle "Show Archived" to surface it)
• Stops appearing in pickers (scene config, casting call, persona switcher)
• Stops appearing in Discovery and on your portfolio
• Stays linked to existing chats, so chats that referenced it still work
• Can be restored to its previous status (Draft or Private) at any time
• Can be hard-deleted later if you want it gone for real

Archiving is the correct answer when you want content "out of your way" without losing the option to bring it back. Hard deletion is destructive and cascades — only do it when you're sure.

---

Reports & Moderation Interaction

Once content is public, anyone can file a report against it via the card context menu or the content detail page. The report goes into the moderation queue and a few things can happen.

Outcome	Effect on you
Dismissed	No action. The report is closed. You're not notified unless you ask.
Soft-warning	Content stays public. You get a notification flagging the issue (e.g. "your tags don't match content").
Move to Pending Review	Content goes invisible while staff investigates. You see the pending_review status on your end.
Forced visibility change	Staff can flip your content from Published to Private. You get a notification with the reason.
Forced re-tagging	Staff can change content rating or trigger warnings without your input — usually for clear mismatches.
Removal	Status set to "removed." Content is gone from your library, Discovery, and others' subscriptions.
Account suspension	If the violation is severe, your account is suspended in addition to the content removal.

Your Appeal Path

For any moderator action against your content, the in-app notification you receive includes an Appeal button. The appeal:

1. Opens a form in the PlotLight Moderation page
2. Lets you write a freeform explanation
3. Routes to staff for a second review
4. Resolves to either upheld (action stays) or overturned (action reversed)

Appeals are tracked in your account history — repeatedly losing appeals is itself a signal staff watches.

Reports Against Your Content On PlotLight

PlotLight is where your moderation surface lives. The Backstage Console exposes:

• My reports — Reports you've filed against other creators
• Reports against me — Reports filed against your content, with the staff outcome
• Appeals — Active appeals you've filed
• Moderation history — Every action ever taken on your account, with timestamps and reasons

The two-app split matters here: the content editor (RoleCall) is where you fix the problem; the moderation surface (PlotLight) is where you read the staff verdict and dispute it.

---

Tag & Trigger Warning Enforcement At Publish

Tags are baked into the publish flow because Discovery depends on them. Trigger warnings are baked in because user safety depends on them.

What's Required At Minimum

• Characters — Card Type tag + at least one Gender tag (with type-specific constraints) + at least one Genre tag.
• Personas — At least one tag (no strict category requirement).
• Lorebooks — At least one tag, plus a Lorebook Type tag if it can't be inferred from the entries.
• Presets — At least one tag (typically Style or Model). Not strictly required, but Discovery surfaces tagged presets much higher.
• Other types — No minimum, but unrated content sinks in Discovery ranking.

Auto-Detection Vs Manual Tagging

The Tagsheet wizard walks you through every relevant tag category for the content type. Most tags are manual choices, but a few are auto-suggested:

• Genre / Mood / Theme suggestions based on description text analysis
• Fandom auto-link if the description references known fandoms
• Content rating hint based on detected NSFW signals in the prose

Auto-suggestions appear as gray chips you click to confirm — never auto-applied, always a manual confirmation. You're the one accountable for the tags on your content.

Trigger Warning Severity Requirement

Trigger warnings have three severity levels that must be set when selecting a warning:

Severity	Meaning
1 — Mild	Mentioned briefly or off-screen
2 — Moderate	Depicted with some intensity, but not a focus
3 — Severe	Central or graphic

The Publish modal blocks publish for After Dark content if no trigger warnings are selected. Trigger warnings can be added to All Hours and Late Night content too — they're just optional below After Dark.

After Dark Gating On The Discovery Side

When someone browses Discovery, their content-rating preference (in Settings) decides whether After Dark content appears at all. The three preferences:

User preference	What they see
All Hours only	Only content rated All Hours. Late Night and After Dark hidden entirely.
All Hours + Late Night	Mature themes visible; explicit hidden.
All content	All ratings visible. Trigger-warning preferences (hide/warn/show) layer on top per-warning.

After Dark content is also age-gated server-side — the API checks both the user's stated preference and their account's birthdate/age-verification status before returning After Dark items.

---

Discovery Surfacing Rules

Once published, where your content appears in Discovery depends on a few signals.

Newest Carousel

The simplest surface: sorted by published_at descending. New items go to the front. No engagement signal involved — pure recency.

Trending Carousel

A weighted score combining:

• Recency — newer items boosted
• Favorites — high weight
• Ratings — high weight, with rating count factored in (low rating count = less trust)
• Chat counts (characters) — medium weight
• Fork counts — medium weight
• Subscriber growth rate — medium weight

Trending takes a few hours for new content to enter — there has to be some engagement signal before the algorithm picks it up.

Per-Creator Carousels

Your portfolio page surfaces your own published content via several block types. The default ordering varies by block:

• Latest Drops — sorted by published_at descending
• Content Gallery — manually orderable
• Featured Pin — you pick one
• Most Played — sorted by chat count or rating

Profile Lookup

plotlightstudios.com/portfolio/<your-username> shows all your published content — characters, presets, lorebooks, personas, prompts, guides, regex scripts, series — grouped by type. Drafts and privates are filtered out except in your own owner view.

Subscriber Notifications

When you publish, the system fires an in-app notification to every subscriber with auto-update on. The notification includes:

• The content name and your creator name
• The version number
• The version title (if you set one) or the first line of release notes
• A link to the version history modal so they can see what changed

---

Editing After Publish

Once content is public, the publish-and-revise loop runs on a clean separation between draft state and published state.

Draft State Lives On The Content Row

When you edit a published character — typing in the panel, dragging prompts around, swapping an alt art — the changes are saved to the live content row. They do not appear in the published snapshot.

This means:

• Subscribers continue to see the last-published snapshot, not your in-progress edits
• The "View Original / View Your Fork" toggle in the character panel lets you see your draft state vs. the last-published state
• You can hammer on a character all month before deciding to publish — subscribers see the same stable thing the whole time

Republish Creates A New Version

When you're ready, clicking Publish opens the Publish Version modal pre-populated with the changelog (computed by diffing live row against last-published snapshot). You write your reasons, click publish, and the new snapshot is created.

Subscribers See The New Version Automatically

If they have auto-update on (default), their pointer moves to the new snapshot and they see your changes the next time they open the content. If auto-update is off, they see an "Update Available" badge.

Forks Don't Get The Update

Forks are independent copies. They keep their frozen state at fork time. They can pull upstream changes via the Compare button in the character panel — but it's a manual cherry-pick, not automatic.

This separation is why "edit after publish" feels clean. Live state stays personal. Published state stays subscriber-facing. Forks stay independent. The publish action is the bridge — and the only bridge — between the three.

---

Mobile Considerations

The publish flow works on mobile but a few things adapt:

• Publish Version modal — Renders as a full-screen sheet on mobile rather than a centered card. The visibility toggle moves above the publish button in the footer. The changelog list is scrollable; each row's expander reveals the per-field "Why this change?" inline.
• Diff modal — On narrow screens, the two-column side-by-side diff stacks into a single column with a "Show Original / Show Changed" toggle. Field changes are clearly marked with their "Changed" / "Modified" pills regardless of layout.
• Tagsheet wizard — Each step renders as a swipeable full-screen card with sticky next/back buttons.
• Character panel publish — The footer publish buttons (Save Draft, Save Override, Publish Draft to Everyone) collapse into an action sheet to fit thumb-reachable space.
• Version History modal — Renders as a full-screen scroll on mobile with each version as a stacked card showing version number, title, date, changelog, and release notes.
• Auto-save indicator — On mobile, the auto-save dot in the editor header is more prominent because the "Save Draft" button isn't always in reach.

---

Tips & Best Practices

Write release notes that read like patch notes. Subscribers are reading the version history modal between writing scenes — give them bullet points, not paragraphs. "Tightened personality prompt to reduce purple prose. Added a new alt art for the snow scene." That's enough.

Use per-field change reasons sparingly. They're great when something subtle changed and subscribers might be confused — "Changed personality to better match the alt art" — and noise when every field gets a reason. The default is no reason, and that's fine.

Publish in batches, not after every edit. Subscribers get a notification for every publish. Spamming three publishes in a day for tiny tweaks is annoying. Hold edits for a session, then publish once with a full changelog.

Get tags right at first publish. Re-tagging after publish is cheap, but it doesn't backfill into Discovery rankings. Get the genre + theme + mood right on v1.

Set trigger warnings honestly. Mislabeled After Dark content gets reported, and reports against your content count toward your reporter trust score. The Tagsheet wizard makes the right warnings easy to find — the cost of overshooting is zero.

Use Private status for "polished but personal." A character you're proud of but don't want public is a perfect Private candidate. Private content still works in your own chats, can be Rewritten into a derived public character, and the snapshot history is still tracked.

Pull your forks' upstream updates manually. Auto-update only applies to Repertoire subscribers. Forks need to actively check via the Compare button in the editor. If you've forked a character you really like, set a reminder to check upstream periodically.

Don't ignore the diff modal. When republishing a big change, opening the Diff Modal first is the cheapest sanity check — it catches accidental deletions, prompt reorderings you didn't mean to keep, and lorebook entries you forgot to remove.

Plan your fork rules at first publish. Setting Strict posture after a thousand people have already rewritten your work doesn't apply retroactively — existing forks are grandfathered. Set the posture you want at v1 if fork policy matters to you.

Treat unpublishing as a soft retreat, not a delete. If you flip back to Private, existing forks survive and existing subscribers keep their snapshot. Hard deletion is much more destructive and rarely the right move.

Watch the Pending Review queue if you're on Audience tier. New publishes take staff time to clear. The notification system tells you when something's approved or bounced, but checking the Submission Queue on PlotLight directly is the fastest way to see what's in flight.