# Series Bible & Cross-Repository Continuity Record

**Release:** v1.0 demonstration baseline  
**Status:** public-safe educational / legal-review demonstration  
**Source of truth:** this document defines cross-repository continuity; operative contracts and signed rights documents control any real transaction.

## 1. Purpose

This record connects the narrative world, music-development record, and social-network DJ workstation into one auditable demonstration.

It is designed so a reviewer can trace a fictional or proposed creative event from **story signal → character observation → PIXIE session → creative asset → contributor evidence → rights decision → hypothetical deal → release gate** without treating association, software state, or public availability as permission.

This is an educational project-control artifact, not a contract and not legal advice.

## 2. Repository roles

| Repository | Canonical function | What it does not establish |
| --- | --- | --- |
| `ibloud/50-ways-to-leave-another` | Series/music production record, rights controls, delivery and deal-study architecture | A commission, endorsement, clearance, or executed agreement |
| `ibloud/ibloud-ivxx-story-lab` | Narrative/social-network world, source classification, character logic, research methodology | Private facts, privileged knowledge, real-person participation, or authorization |
| `ibloud/pixie-creator-os` | Operational workstation used by the **fictional social-network DJ character** to prepare sets, manage a crate, create sessions, and record creator-workflow state | Ownership of the material observed or created; permission to publish; hardware/service access not actually implemented |

### Canonical relationship

**THE WORLD → SOCIAL SIGNAL → DJ OBSERVES → PIXIE SESSION/OBJECT → CREATIVE ACTION → CONTRIBUTOR RECORD → RIGHTS/CLEARANCE → RELEASE EVIDENCE**

PIXIE is the character's tool. It is not the character and it does not convert an observation into an ownership claim.

## 3. Truth-status vocabulary

Every material assertion should be classed as one of:

- **Documented** — directly supported by a project record or primary source.
- **Attributed** — a claim or interpretation explicitly attributed to a named source.
- **Interpretive** — project analysis derived from documented material.
- **Fictionalized** — invented for the narrative or demonstration.
- **Unresolved** — intentionally not determined; requires evidence or counsel.

**Rule:** Association is allowed as form. Assertion requires evidence.

## 4. Five-part narrative continuity

| Part | Narrative function | Music / production function | Evidence rule |
| --- | --- | --- | --- |
| 1 | Signal / irreversible decision | Working version of title track | Mark source status; do not infer private facts |
| 2 | Grief / inventory | Track 2 development | Distinguish observed signal from character interpretation |
| 3 | Dysregulation / fractured competence | Track 3 development | Preserve ambiguity and revision history |
| 4 | Being witnessed, not explained | Track 4 development | Any real collaborator participation is contingent on written agreement |
| 5 | Return / presence without false resolution | Finished title-track version | Final rights, credits, metadata, and release gates required |

The same title-track lyric can function as an intentionally repeated narrative object: Track 1 is an early state; Track 5 is a later production/performance state. The words alone do not establish a real-world event or relationship.

## 5. Social-network DJ continuity

The DJ is a **fictional/in-world role** within the demonstration. Her job is to monitor public network signals, prepare music and sets, and use PIXIE as her operational workspace.

A typical trace is:

1. A public signal appears in the story world.
2. The DJ observes it through ordinary public channels.
3. She records a session/object in PIXIE with an ID and provenance note.
4. She makes a creative decision: playlist, cue, edit, composition prompt, note, or programming choice.
5. Any new creative asset receives a contribution/provenance record.
6. Rights are evaluated separately from creative provenance.
7. A release or deal is blocked unless required rights evidence exists.

**Continuity invariant:** what the DJ sees, creates, saves, publishes, or receives through PIXIE is not automatically what she owns, what the story asserts as fact, or what another party authorized.

## 6. Legal-review demonstration trace

| Stage | Demonstration question | Required record | Gate |
| --- | --- | --- | --- |
| Signal | What was actually observed? | Dated source + truth status | Evidence exists |
| Observation | Who is the fictional witness/DJ? | Character record | Fictional role clearly labeled |
| PIXIE | What did the workstation record? | `pixie_id`, session/object metadata | Object is traceable |
| Creative action | What changed? | Contribution record / version | Human decision identified |
| Contributor | Who supplied the work? | Agreement, split sheet, permissions | Parties and scope identified |
| Rights | What can be exploited? | Rights envelope + licenses | Media/territory/term aligned |
| Deal | What is proposed? | Term sheet / agreement | Offer distinguished from acceptance |
| Delivery | What is released? | Final delivery checklist | Clearance gate passed |
| Case study | What may be discussed publicly? | Separate publicity/case-study consent | Named use authorized |

## 7. Charlie J boundary

Any reference to Charlie J in this demonstration remains a **proposal/contingency**, not a statement of attachment. A public service listing can establish that a service was publicly offered; it does not establish permission to use a person's name, voice, likeness, work, biography, endorsement, or professional participation outside the applicable permission or executed agreement.

Any real-world participation, public identification, case-study use, or rights grant must be separately documented.

## 8. Deal-study boundary

The demonstration can model the components an actual agreement would need to address, including:

- parties and authority;
- scope and deliverables;
- consideration, payment timing, and approved expenses;
- acceptance and revisions;
- authorship, ownership, and licenses;
- master and composition rights;
- performer, voice, likeness, publicity, and credit permissions;
- third-party samples, beats, interpolations, and AI-generated/AI-transformed material;
- representations, warranties, and indemnity as appropriate to counsel's drafting;
- confidentiality where applicable;
- termination, breach, cure, and post-termination treatment;
- dispute resolution, governing law, venue/jurisdiction, and remedies;
- signatures and exhibits.

A demonstration of these fields does **not** make the repository enforceable. Enforceability depends on the actual agreement, applicable law, authority, consideration, assent, and other facts reviewed by qualified counsel.

## 9. Source-of-truth hierarchy

1. **Executed agreement / signed rights document** — operative legal terms.
2. **Approved project evidence archive** — provenance, payment, delivery, permissions, and source records.
3. **Canonical GitHub documentation** — public-safe explanation of decisions and version history.
4. **Interactive demonstration** — navigation and education only; never authoritative over the records above.

If sources conflict, stop the workflow and resolve the discrepancy rather than silently reconciling it.

## 10. Release gate

A track or story asset remains **BLOCKED** when required evidence is missing, disputed, or narrower than the intended use. For music, composition/sync and master-use permissions must independently cover the intended media, territory, and term. Promotional uses may require separate permission.

No software UI, public URL, social post, marketplace listing, or repository reference substitutes for a required right.

## 11. Reviewer questions

A legal reviewer should be able to answer from this package:

1. Who owns or controls each relevant asset?
2. Who authorized each proposed use?
3. What exactly was granted, for which media, territory, and term?
4. What remains pre-existing versus newly created?
5. Which statements are documented, attributed, interpretive, fictionalized, or unresolved?
6. Are any real-person references being mistaken for participation or endorsement?
7. Are publicity/case-study permissions separate from creative-work permissions?
8. What evidence would be required before release?
9. What happens when a right cannot be documented?
10. Which terms must be moved from demonstration to a signed operative agreement?

## 12. Stability rule

The interactive demo is a **view into this model**, not a second source of truth. It should use stable, dependency-free HTML and point back to versioned repository documents. A reviewer can therefore evaluate the architecture even if JavaScript, external services, authentication, audio integrations, or hosting are unavailable.