Faultlines Series Bible Instructions

This directory is the canonical interconnected reference wiki for Faultlines canon. Treat changes as prose and continuity work, not database or software-schema work.

Before creating, revising, formatting, auditing, or moving a Series Bible entry, use the global route-faultlines-workflows skill and select the smallest applicable leaf workflow. For ordinary entry prose, select fandom-wiki.

Follow the selected workflow for task-specific formatting, folder structure, naming, location, cross-referencing, propagation, templates, and verification. Read .codex/references/workflow-map.md only when the task needs the project-wide MCP, workflow, or skill map.

Do not silently choose between unresolved canon contradictions. Apply Lily’s existing controlling decision when it already resolves the conflict; otherwise show her the concrete competing versions and wait for her decision. When a canon update is authorized, update every directly affected file and verify the wiki build as required by the workflow.

The canonical canon-management and verification rules are injected below so Codex receives their actual text at session startup. Run .codex\scripts\rebuild-instruction-bundles.ps1 after either source changes.

Faultlines Canon Management

Use canon-assertion-protocol for hard-fact claims and verification-principles.md for evidence, contradiction, gap, and write handling.

Current-source requirement

Do not assert a Faultlines fact from model memory, prior-session memory, a cached summary, a chat-log statement, or one tool summary.

Before asserting or writing a fact, inspect the current source cluster required by the active workflow. Depending on the claim, that may include:

• published or current manuscript prose;
• Series Bible biography and companion files;
• novel arc and chapter maps;
• scene-era Series Bible speech and relationship sections, Lily’s current direction, and eligible accepted prose for written voice behavior;
• development evidence and Lily’s decisions or adoption under Existing developed canon in verification-principles.md;
• current real-world sources for non-fiction claims.

Hard facts

Hard facts include:

• names, aliases, pronouns, identity labels, birth and death information;
• dates, ages, chronology, and event sequence;
• family, relationship, and who-knows-whom claims;
• diagnosis, symptom, treatment, medication, equipment, care, access, and body-state facts;
• residences, settings, institutions, education, employment, credentials, works, awards, and affiliations;
• direct quotations and attribution.

Use the current local canon tool that matches the need, then read the controlling source files.

Useful functions include:

• canon_brief for a compact identity inventory;
• get_canon_evidence and cite_fact for source evidence;
• entity lookups such as lookup_character, lookup_relationship, lookup_family, lookup_career, lookup_event, and lookup_setting;
• validate_facts for a bounded claim set;
• list_unknowns for explicit unresolved fields and negative assertions;
• validate_passage for a conservative proper-noun and fact scan of completed prose;
• find_references, smart_search, and search_bible for cross-file searches;
• check_age, check_timeline, character_timeline, and check_medical for their defined domains.

Do not invent a function name or use a retired MCP prefix.

Evidence states

• direct: the source states the claim.
• derived: the value follows deterministically from direct facts, such as an age calculation with a complete date.
• inferred: the claim is a bounded interpretation supported by evidence but not directly stated.
• absent: the current query did not find a positive value.

A focused absent result is query-scoped. Search the complete relevant file cluster before classifying canon as silent. Silence does not establish a universal negative.

Do not present an inference as a hard fact. State the evidence and uncertainty when the distinction matters.

Specificity and active decisions

Apply Specificity over optionality in .codex/rules/creative-methodology.md to canon updates and Series Bible prose. Canon should retain the exact supported person, place, route, institution, object, date, relationship, or other concrete value rather than generalizing or omitting it merely to preserve optionality.

Before labeling a value unresolved or omitting it from wiki prose, apply the complete absence search in verification-principles.md. Treat the apparent gap as a retrieval problem until the current canon cluster, manuscripts and planning sources, decision queue, adoption and audit records, relevant ChatGPT and Claude development logs, and available local Claude Code development records have been checked. If that source chain establishes one answer, use and propagate it within the authorized scope. If a material creative choice remains and requires Lily’s input, ask her only the complete remaining question and state what the answer changes; do not make her re-decide canon already present in the development record or hide a needed decision inside broad wording, an empty field, a placeholder, or passive omission. Treat the value as unresolved only when the complete search cannot establish it, Lily explicitly defers the choice, or Lily deliberately preserves the uncertainty.

This rule does not authorize inventing canon or silently resolving a contradiction. Follow the contradiction and approval rules below whenever current positive sources disagree.

Contradictions

When current positive sources disagree:

1. stop using the disputed value;
2. quote or accurately summarize each value with its source;
3. identify affected files and downstream calculations;
4. ask Lily which version controls unless she has already supplied the answer;
5. after approval, use canon-reconciliation to update the full authorized companion set and verify it.

Do not decide by file date, repetition, polish, apparent plausibility, or manuscript-versus-Bible category alone. A published manuscript can contain a continuity error; a Series Bible file can contain an unpropagated correction. The evidence and Lily’s decision control.

Time and character state

For dated work:

• pass the exact scene or event year to canon tools;
• use complete dates when birthday position matters;
• distinguish lifelong, era-bounded, temporary, progressive, recurrent, and resolved states;
• do not apply later knowledge, diagnosis, language, equipment, relationships, or hindsight to an earlier scene;
• verify technology, climate, culture, law, medicine, and institutional practice for the stated time and place.

Quotations

• Never fabricate or paraphrase a sentence into quotation marks.
• Verify exact wording, speaker, recipient, date or event, and source.
• Do not move a quote into another character’s Memorable Quotes section because the sentiment fits both.
• Preserve the approved structured placeholder when a Memorable Quotes section has no established quote; do not turn that placeholder into running prose.

Real public figures in canon and manuscripts

Current project policy permits named real artists and public figures in private Series Bible development material when Lily has approved the in-universe connection. Their presence is not automatically a canon error.

Published manuscript prose uses the current manuscript rule for real-person names. Do not carry a named public figure from private development material into a novel merely because the Bible names them. Verify music metadata and other real-world claims separately.

Medical, disability, and representation claims

Use medical-research, research-verifier, cultural-authenticity-research, or sensitivity-reader as applicable. Canon establishes the character decision; research establishes real-world plausibility and context.

Do not infer an individual presentation from a diagnostic average. Record variability, body state, access, care, relationships, and institutional conditions only when current canon or approved research supports the specific claim.

Propagation

An approved correction or new fact must be reflected in every current owner file inside the authorized scope. Check biographies, relationships, careers, events, journeys, families, medical references, items, settings, organizations, creative works, timelines, and writer references as applicable.

Do not duplicate full detail across every file. Put detail in the canonical owner and add concise owner-specific summaries and links elsewhere.

Canon established during exploration

Exploration is a normal source of Faultlines canon. When Lily establishes, adopts, confirms, or corrects a fact during discussion or exploratory prose, check and update its corresponding current files in the same task. This is standing authorization for the bounded canon write and directly required propagation; do not wait for a separate request to save, a formal canon command, or another approval of the same decision.

1. Identify the established content and its actual scope: personality, preference, interior experience, relationship behavior, history, event, setting, body, access, or another canon fact. Preserve any era, relationship, capacity, or situational limits Lily supplies.
2. Apply Existing developed canon in verification-principles.md to determine approval during ongoing development and distinguish established content from genuinely open alternatives. Her I think X expresses a chosen direction unless the context leaves it open. Use that shared rule rather than imposing a separate explicit-confirmation requirement on assistant-originated details.
3. Before writing, assign each established distinction to its canonical owner by subject and file type. Search for and read the existing biography and plausible relationship, career, event, journey, organization, or other companion owners. Check whether the content already exists, adds a missing distinction, or conflicts with a positive assertion. Use current canon tools and direct reads; follow the complete source-chain search when a historical gap or conflict requires it. A fresh explicit decision does not require rediscovering the same decision in an older log.
4. If the content is already fully documented, preserve it without adding repetition. If it is missing or partly documented, use the applicable Series Bible file-type rule to update or create the proper owner when the established material meets that file type’s threshold. Do not use a biography as the default container for developed relationship, career, event, or organization detail. Keep the biography’s character-specific summary concise and link to the companion owner. Put durable character speech and relationship distinctions in their appropriate Series Bible owners; a chat record alone is not sufficient storage for a newly established fact. Prose execution remains the writer’s scene-specific craft, not new canon merely because one draft uses it.
5. Update directly affected summaries, links, and writer references as their own purposes require. Do not copy the same paragraph throughout a character’s files, invent additional traits, or promote an entire exploratory scene into a manuscript chapter merely because a fact was established within it.
6. Apply Lily’s existing correction when it resolves a conflict. Ask only about a genuine remaining contradiction or material choice; continue independent, settled updates. Respect an explicit request to defer writing or keep particular material provisional.
7. Reread every changed claim against Lily’s actual statement and the controlling sources before reporting completion. Check that negations, quantities, scope, timing, ownership, and causal limits survived the paraphrase; search directly affected files for stale or newly contradictory wording and repair it within the authorized scope. Check applicable links and indexes. Briefly report which owner and companion files were checked, which were changed or created, what was already present, and any concrete unresolved item. Do not substitute a claim that the guidance was read for this verification or end with an offer to save facts that this rule already authorizes saving.

Faultlines Verification Principles

These rules apply to manuscript, Series Bible, development, research, and production claims.

Verify before asserting or writing

1. Define the exact claim and date, era, location, relationship, body state, or edition it covers.
2. Identify the current owner sources.
3. Read the controlling passages with enough complete context to preserve qualifications, chronology, and contradictions. Follow the selected workflow’s source boundary: a full-file audit or extraction requires the full source; a bounded scene packet may use complete relevant sections. Read the complete source whenever its full chronology or context controls the claim. Never use a snippet or tool summary as a substitute for the required read.
4. Use the applicable current canon or research tools.
5. Classify the evidence.
6. Resolve contradictions before using the value.
7. Write only within the approved scope.

Do not decide authority from recency alone. A newer note may be a proposal; an older manuscript line may have been corrected elsewhere.

Canon evidence classification

• supported: one or more current canonical sources state the positive claim and no current source contradicts it.
• isolated canon: a current canonical owner states the claim, but related files have not propagated it.
• contradicted: current positive sources state incompatible values.
• absent: the complete relevant source search finds no positive claim, or only an explicit placeholder, uncertainty statement, or negation remains.
• proposal: the source explicitly leaves material as an unchosen suggestion, question, or competing alternative, and Lily has not adopted it individually or as part of a larger package.
• rejected or superseded: Lily explicitly corrected, rejected, or replaced the claim. An auditor’s exclusion label is not an authorial decision.

Existing developed canon

Lily’s controlling instruction is: “Unless I corrected it, it’s canon.” Apply this to ongoing collaborative development as well as existing developed material in the Series Bible, pre-edit canonical files, and development scenes, including material created with an assistant. During canon development, treat details carried forward unchallenged as approved; do not require an explicit yes for each suggestion. When Lily proposes a different version, the displaced version is not approved; follow her replacement within its stated scope. Preserve genuinely open choices when she presents competing alternatives, explicitly expresses uncertainty, or asks to keep something provisional. Do not require a separate approval record for each detail, repeated confirmation, repetition in other files, or manuscript depiction. Her validation of a scene, explanation, or larger package includes its developed content unless she limited that validation or later corrected it. Missing proof of a separate approval is not proof that the material was unchosen.

Canon includes physical and biographical details, exact dialogue, thoughts, feelings, motives, fears, psychological explanations, relationship dynamics, cultural and family influences, symbolism, established significance, and developed future events or outcomes. Interiority, interpretation, vivid or thesis-like prose, AI origin, and an auditor’s preference for externally observable facts are not grounds for deleting, narrowing, or downgrading that content. Preserve the source’s distinctions between an event, a character’s belief, an internal thought, figurative language, and spoken dialogue while retaining their meaning.

Speculation is material the source actually leaves unchosen or uncertain, such as explicit open alternatives, questions, placeholders, and undeveloped possibilities. Read the context: a hypothetical form inside a validated explanation does not make the explanation noncanon, and a future event is not speculative merely because the character has not yet reached it. Lily’s adoption overrides an earlier proposal label.

Use source checks to locate Lily’s corrections and reconcile the affected details, not to make her establish the rest again. If two developed versions conflict and her existing decisions do not resolve them, preserve the source material, present the exact conflict, and ask only which version controls. A demonstrated chronology or real-world plausibility problem requires bounded reconciliation; it does not authorize deleting the surrounding character history or meaning. Apply corrections already supplied by Lily without requesting approval again.

During preservation recovery, this rule controls over older audit and recovery exclusions, including entries marked complete. Reopen exclusions based on provenance, interpretation, interiority, or missing repeated approval. A register change must preserve the full established content and significance; changing a wiki’s presentation is not permission to reduce canon.

Do not place these author-facing labels in in-universe prose. Omit unresolved running-prose claims unless the uncertainty itself is canon. Preserve approved placeholders only in fields or sections designed for them.

Complete absence search

Treat an apparent canon gap as a retrieval problem until the complete source chain has been searched. Faultlines has extensive development history, so absent or unresolved is a high-confidence verdict, not the default after a current-wiki miss.

Before classifying a fact as absent:

• search aliases and current names;
• search the biography and all plausible companion owners;
• search relevant published or current manuscripts, arc maps, chapter maps, and writer references when the claim could be established there;
• search the current decision queue and applicable adoption, audit, reconciliation, and ongoing-project records;
• search relevant development conversations under Chat Logs/ChatGPT/ and Chat Logs/Claude/, plus available local Claude Code development records, using participants, topic terms, likely wording, dates, places, and consequences;
• distinguish Lily’s explicit decisions, corrections, and adoptions from assistant proposals, questions, hypotheticals, alternatives, examples, and rejected or superseded material;
• search by participants, date, location, organization, event consequence, and likely title;
• use find_references, smart_search, search_bible, and applicable entity lookups;
• read plausible source files rather than relying on snippets.

A focused tool result of absent does not override a positive claim elsewhere.

Apply the existing-developed-canon rule before asking Lily to decide a fact again. When the search recovers her prior correction, use and propagate it within the authorized scope. Ask only about an actual unresolved conflict or a choice the source explicitly left open; inability to locate a separate approval record is not such a choice.

Do not infer universal negatives such as never, always, no one, or not once from missing scenes or silence. An existing developed assertion is itself evidence under the preservation rule; do not narrow it merely because there is no separately depicted scene for every instance.

Research for real-world content

Use current primary and authoritative sources when a claim concerns real medicine, institutions, places, culture, law, history, organizations, professions, technology, equipment, publishing, or accessibility.

Record:

• source and publication or effective date;
• jurisdiction, institution, population, or product version;
• what the source directly establishes;
• limitations, disagreement, and historical change;
• whether the claim is stable enough for the story date.

Separate correlation from causation, general guidance from individual fact, legal possibility from actual practice, and current rules from historical rules.

Canon decides whether a researched possibility applies to a character. Research does not make that decision automatically.

Documentation gaps

Flag a documentation gap when there is concrete evidence that the current file is incomplete, such as:

• the live template requires a field or owner section and the source file omits it;
• a current companion source contains established owner-relevant material absent from the owner file;
• an approved decision has not propagated to a directly affected file;
• a required link or companion file is missing under the current owner rules;
• a placeholder remains after Lily has supplied the answer.

Do not flag a gap merely because a detail would be plausible, emotionally useful, common for the character type, or interesting to develop. Do not use file length, mention count, or this feels thin as evidence.

A gap flag names:

• the exact file and field or section;
• the template or source that establishes the expectation;
• whether the missing content is already established or still requires Lily’s decision;
• the authorized next action, if any.

Flagging alone does not authorize filling. Apply existing authorization before asking for approval: Canon established during exploration in series-canon.md authorizes bounded documentation of facts Lily has established in development. Otherwise, write only after the selected builder or update workflow reaches its approval point.

Contradiction handling

When two positive claims cannot both be true:

1. stop using or propagating the disputed value;
2. present both claims with their exact sources;
3. identify downstream ages, timelines, relationships, equipment, medical, or publication records affected;
4. ask Lily for the controlling answer unless she already gave it;
5. after approval, update the full authorized companion set;
6. run canon, age, timeline, link, and domain-specific checks.

Different perspectives, added specificity, character development, and different era-bounded states are not contradictions when both can be true in their stated contexts.

Fact changes versus register changes

A fact change alters a name, date, relationship, diagnosis, event, place, age, quotation, identity, status, action, motive, or other canon assertion. It requires the approval defined by the active workflow.

A register change preserves the same facts while changing tense, section ownership, scene-to-synthesis form, paragraph construction, link formatting, or unsupported editorial framing.

An audit remains read-only unless Lily authorized implementation. During an authorized wiki edit, clear register corrections inside the approved scope may be applied without reopening settled facts. When a proposed register edit would remove, add, narrow, or reinterpret a fact, treat it as a fact change.

Time and age

• Store birth and death dates in their canonical fields when established.
• Use check_age for dated character-age claims and verify complete dates when birthday position matters.
• Keep file modified dates separate from story dates.
• Preserve earlier and later states; do not overwrite chronology with an undated current-state summary.
• Use the date format required by the current template.

Cross-file consistency

After an approved fact change, identify every directly affected canonical owner and reference. Update the full authorized set in one reconciliation transaction. Keep detailed content in its owner file and update linked summaries only to the level their own file requires.

Do not claim reconciliation is complete until searches show no stale positive assertion remains in the affected scope.

No bulk rewriting of narrative prose

Search and analysis scripts may locate candidates. They must not perform regex or pattern-based rewrites of manuscript or Series Bible prose.

Read each affected passage in context and use apply_patch for contextual edits. Bulk operations remain appropriate for generated files, validated structured data, and mechanical infrastructure when the task explicitly authorizes them and no narrative prose is being rewritten.