Lineage + fork tree

When you fork a persona, you copy it — but you also write an edge into a graph. The result is a lineage tree: every persona is a node, every fork is an edge, and the root is the original generation.

Why a tree

Three product needs drive it:

1. Attribution. When a marketplace listing is forked, the original creator stays credited downstream. Royalty splits, license enforcement, and the visible "forked from" chip all read from this tree.
2. Variant management. A brand persona with formal / casual / EN / DE forks is easier to govern when the relationships are explicit.
3. Audit trail. Compliance teams asking "where did this voice come from?" get a deterministic answer.

Shape

{
  "id": "persona_b...",
  "parentPersonaId": "persona_a...",
  "rootPersonaId": "persona_a...",
  "ancestry": ["persona_a..."],
  "children": ["persona_c...", "persona_d..."],
  "forkAttribution": {
    "sourceCreator": "user_...",
    "sourcePersonaId": "persona_a...",
    "license": "CC-BY-4.0"
  }
}

Operations

• Fork — POST /v1/personas/{id}/fork. Optional refine arg to apply an axis transform during the fork.
• List lineage — GET /v1/personas/{id}/lineage. Full graph for the persona's root, with depth controls.
• Attribute drift — consistency.distinctiveness compares a fork against its parent; too far is warn/block/flag per config.

Tier

Free-and-up for read. Forking is Pro+. Public marketplace forks (third-party listing → workspace) require the source listing's license to permit derivatives.

Honest scope

Lineage tracks persona-to-persona ancestry. It does not track "this chat session derived from this persona" — that's the session metadata, not lineage. Don't conflate the two.