ROLECALLFeatures

Versioning & Lineage

Deep dives into every tool on stage

Versioning & Lineage

Every piece of content on PlotLight has a history. When a creator publishes a new version of a character, preset, or lorebook, the old version doesn't disappear — it's preserved as a snapshot you can read, compare, and even pin yourself to if you prefer the earlier state. And when you look at any piece of content, you can trace exactly where it came from: the original creator, every fork level in between, and the specific version that was forked at each step.

This page covers what versioning looks like from your side as a visitor, subscriber, or fork owner.

For the creator-facing side — how to publish versions, take snapshots, roll back, and mark a stable version — see Versioning & Rollback on RoleCall.

The Lineage Chain

Every content detail page shows the lineage chain — the full ancestry of that content, from the original creator at the top down to the current version you're looking at.

The chain renders as a breadcrumb near the top of the detail page:

Original by @creator-a → Rewritten by @creator-b → Rewritten by @creator-c (this version)

Each name links to that version's detail page (or to the creator's Portfolio if that version was later deleted or made private). Long chains collapse in the middle and expand on click.

What the Lineage Shows You

  • Who made the original — the creator at the very top of the chain, with a link to their portfolio.
  • Every fork level — every rewrite that happened between the original and this version, in order.
  • Which version was forked at each step — if @creator-b forked @creator-a's v3, and @creator-a is now on v9, the lineage note reflects that. You can click through to see what v3 looked like.

Attribution is permanent. Even if an upstream creator deletes their version or their account, the lineage stays attached to every downstream fork. The original creator's name and the fork date persist regardless.

Version History on Detail Pages

On any published content's detail page, you'll find a version history — the list of every published version, newest first.

The version history shows:

ElementWhat it tells you
Version numberv1, v2, v3...
Version titleA short label the creator gave this version — "Big Personality Overhaul," "Fixed Greeting Bug." Blank if the creator skipped it.
Published dateWhen this version was pushed live.
Stable badgeIf the creator has designated this version as their stable canonical release.
ChangelogThe per-field changes the creator recorded at publish time.
Release notesThe creator's longer "what's new" notes (Markdown, often bullet points).

Clicking any version row expands the full changelog and release notes. You can also open a diff view between any two versions — a side-by-side comparison showing exactly what prose changed, what settings shifted, and what items were added or removed.

Stable Versions

A creator can mark one version as stable — their designated canonical release. On Discovery cards and detail pages, content defaults to displaying the stable version even if the creator has published newer experimental versions since.

The stable badge appears in the version history list and in the version number display on the card. If you're trying to understand what a character "officially" is versus what the creator is actively tinkering with, the stable version is the reference point.

Subscribing to content always gives you the latest version by default. If you prefer the stable version, you can pin to it in your version history panel (see Pinning a Version below).

Update Notifications for Subscribers

If you've added a character, preset, or lorebook to your Library via Add to Library (Repertoire), you'll get notified when the creator publishes a new version.

The notification appears as an "Update available" badge on the content's card in your Library and as an in-app notification. The notification includes:

  • The content name and the creator's name
  • The new version number and title
  • A link to view what changed — opens the diff between your current pinned version and the new one

Auto-Update vs. Manual Bump

When you subscribe, you can choose how updates arrive:

SettingBehavior
Auto-update onYour subscription pointer moves forward automatically every time the creator publishes. You always see their latest version.
Auto-update offYour pointer stays pinned until you manually bump. You see the "Update available" badge until you decide to update or stay.

Auto-update on is the default. You can change this per-subscription from your Library card's context menu.

Pinning to a Specific Version

If a creator's update changes something you don't want — a personality shift that doesn't fit your scene, a setting change that breaks your workflow — you can pin yourself to any specific version in the version history modal. Pinning stays in place until you change it. New publishes from the creator won't move your pointer; you'll see update badges but your experience stays on your pinned version.

Update Notifications for Fork Owners

Fork ownership is different from subscription. When you rewrite (fork) content, your fork is an independent copy — it doesn't auto-update from upstream. But you do get a lightweight notification when the original creator publishes something new.

The notification appears on your Library card for the fork as an "Upstream has new changes" badge, with two options:

  • View diff — see exactly what changed in the upstream version compared to the version you forked from
  • Sync — pull the upstream changes into your fork (see Sync From Upstream below)

You can dismiss the badge without taking action. Your fork keeps running exactly as it was until you explicitly choose to sync.

Sync From Upstream

Syncing is a deliberate, controlled operation — not a silent overwrite. When you sync from upstream:

  1. The system compares three states: the version you originally forked from, your fork's current content, and the upstream's latest version.
  2. Fields where only the upstream creator changed something are offered for auto-merge.
  3. Fields where both of you made changes are surfaced as conflicts — you see both versions side by side and choose which to keep (or manually combine them).
  4. You review and confirm. The result becomes a new draft on your fork.

This means your own edits are always protected. Syncing from upstream can never silently overwrite your changes — every conflict requires your explicit decision.

Tracing Upstream History

Because forks pin to specific versions, the bottom of every content detail page shows exactly which version was forked:

"Forked from @creator-a · Version 3 (v3) · Published March 2026" "Original is now at v9 — view what changed since this fork"

The "view what changed" link opens a diff from the forked version to the current upstream state — useful for understanding how far the original has evolved since you (or the fork chain's creator) copied it.

Multi-level chains show this information at every link. If @creator-c forked @creator-b's v2, and @creator-b's v2 was itself a fork of @creator-a's v5, the full chain is traceable. Each detail page exposes its own "forked from" pointer and you can walk backward all the way to the original.

What Visitors See

If you're just browsing Discovery without subscribing or forking, you can still access the version history on any published content's detail page. You see:

  • The full list of published versions with changelogs and release notes
  • Diffs between any two versions
  • The stable version marker
  • The lineage chain

You can't pin, rollback, or manage anything — those actions require ownership. But as a visitor, the version history gives you a complete picture of how the content evolved and what the creator considers its stable form.

Cross-Reference