manuscript_continuity_audit v1.0.0

name: manuscript_continuity_audit description: >- Audit a fiction manuscript for continuity errors only: build a fact ledger (characters, timeline, places, world rules, objects, who knows what) from the draft itself, extract claims from later chapters, run a checker that flags contradictions with chapter and line references, and fix each one with the smallest edit that keeps the story intact. Use when a novel, novella, serial, or script draft needs a continuity pass, a story bible built from an existing draft, or a check that a revision did not break facts established earlier. metadata: category: writing

Manuscript Continuity Audit

Purpose

Catch the errors readers catch: an eye colour that changes, a weekday that goes backwards, a key that changes hands off the page, a character who knows a secret nobody told them. The method treats the draft as its own source of truth. Facts come out of the text, go into a ledger as data, and every later chapter gets checked against that ledger. Memory does not do this job well across a long manuscript, and a single prompt asking for plot holes from memory produces confident, unverifiable claims. A ledger produces findings an author can point at, line by line.

Scope is continuity only. Plot causality, pacing, character appeal, and prose quality belong to other passes. A report that drifts into general criticism fails this skill even when the criticism is right.

Workflow

1. Fix the audit ground

• Get the manuscript as one file per book, or a folder of chapter files, and freeze the version being audited. Record the file name and date in the report header. Line numbers only mean something against a frozen text.

• Agree the chapter range. A full audit builds the ledger from chapter 1. A partial audit, for example a revised ending, builds the ledger from every chapter before the revised range and audits only the range.

• Ask what is already canon the author will not change: published earlier books, a printed map, a stated age in chapter 1 of a series. Enter those as ledger facts with their source named in the establishment quote.

2. Build the ledger from the draft

• Read in order and catalogue only. Do not revise, do not fix, do not take prose notes during this pass. Write down every concrete detail the draft settles, in short declarative rows, each with chapter, line, and a short quote from the passage that settles it.

• Cover six groups: characters (name spelling, age, physical traits, relations, job, home), places (distances, travel times, layout), timeline (weekday, date, story day, season, durations), world rules (what magic, tech, law, or money can and cannot do, as stated on the page), objects (description, owner, current holder), and knowledge (each secret, who holds it, where they learned it).

• Mark each fact fixed or can_change as defined in references/ledger-schema.md. Leave undecided things out. A fact the draft has not settled yet is a hole in the ledger by design, and putting a guess in turns later inventions into false contradictions.

• Write the ledger as ledger.json in the exact schema in references/ledger-schema.md. Prose bibles are fine for the author to read. The audit runs on the JSON.

3. Extract observations from the chapters under audit

• Read the audited chapters one thread at a time: all of one character, then the whole timeline, then objects, then knowledge. Single thread passes surface drift that a straight read hides, because the same fact sits on the page twice within minutes instead of weeks apart.

• Record every claim as an observation with chapter, line, and quote, using the four kinds in the schema: fact, knowledge use, timeline placement, object state. Convert relative time markers into story day numbers as you go.

• Extract what the passage claims, not what it means. Lies, rumours, and deliberate mysteries get extracted too, marked in the quote with their speaker. Disposition sorts them later. Skipping them at extraction is how planted clues get reported as errors and real errors get excused as clues.

4. Run the checker

• Run python3 scripts/continuity_check.py ledger.json observations.json. Add --json when the report needs machine readable findings. Read the exit code: 1 means errors exist, 0 means the audited claims match the ledger, 2 means the input files are broken and no audit happened.

• Read every error finding against both passages, the establishment quote and the flagged quote, before it goes in the report. The checker compares extracted data. A bad extraction makes a false flag, and false flags are the fastest way to lose an author's trust in the whole report.

5. Dispose of every finding

Give each finding exactly one disposition:

• Real error: it goes in the report with a proposed fix from references/fix-playbook.md.
• Intentional: a plant, a lie, a disguise, a mystery. No prose change. The ledger gains an open thread entry naming what is being hidden, who in the story could notice, and the chapter by which it must pay off.
• Extraction mistake: the observation was wrong. Fix the observation, note the correction in the working files, re-run. Never carry a known false flag into the report to pad it.
• Undecided: the author has to pick canon. List both values with both references and the dependents of each. Stop there.

6. Fix, update, re-run

• Apply approved fixes at the smallest size that restores one value: one word first, one added beat second, one edited establishment last, per the playbook. Never delete a detail everywhere to make a contradiction go away.

• Update the ledger in the same sitting as any fix: new value, new reference, change event recorded.

• Re-run the checker on the full observation set after fixes, not only on the fixed chapters. Report the second run's counts in the report.

Output Contract

Deliver, in this order:

1. A one paragraph header: manuscript and version, chapters audited, ledger size (facts, timeline entries, knowledge entries, objects), and the finding counts by severity from the final checker run.
2. The findings table content, one item per finding: severity, kind, subject, ledger value with chapter and line, draft value with chapter and line, both quotes, disposition, and the proposed or applied fix.
3. A checked and clear list: the threads that were audited and produced no findings (for example, the sigil rule across all chapters, all name spellings in chapters 5 to 8). Silence about coverage reads as a gap.
4. The updated ledger.json, the observations.json used, and the open threads list with payoff deadlines.
5. A worked miniature of this exact output ships in references/worked-audit.md, built from the sample in assets/.

Operating Rules

• Every factual claim in a report cites a chapter and line in the audited text. A claim you cannot point at does not go in the report.
• Never invent a fact to fill a ledger gap, and never resolve a contradiction by choosing canon without the author's word when both values have dependents.
• Judge the draft against itself, not against real world facts. A capital city three days from the coast in the book stays three days even if the real analogue differs. Real calendar checks apply only when the draft itself uses real dates and weekdays.
• Keep the ledger beside the manuscript and hand it back updated. The next book, the next revision, and the next auditor all start from it.
• Report counts from the checker output, not from memory of the run. Paste the summary line into the working notes before writing the report.
• If the manuscript is too long to extract in one pass, audit in chapter blocks, carry the ledger forward block to block, and say plainly in the header which chapters the ledger covers and which it does not yet.