Build a Searchable Script Concordance for a Series Bible

A concordance answers one question well: where does this phrase appear, and what is around it? Everything the bible needs next — whether the term recurs, whether the show calls it something else, whether the wording is stable enough to write down — depends on that list being honest. Building the list is easy. Keeping it honest is the work.

Hold one distinction from the start. A hit is an occurrence of a string in a file you put in the corpus. It is not a claim about the story. A room named eleven times is not automatically important; a room named once can carry a season. The concordance tells you where to look. It never tells you what to think.

The fixture

I'm going to work against an invented series, Harbor Line, and three invented scene fragments. Nothing here is a real production; the fragments exist so the counts are checkable. I have hand-counted them, and the counts below are mine, not exported from any tool. The point of a foundation exercise is that you can verify the arithmetic yourself.

The story problem is ordinary. A building gets sold, and one room has two names in the show: North Room, which the family uses, and Room N, which the survey plans use. You want to know where each name shows up before you write a line about it.

Three working files, all plain text:

HARBOR LINE - EPISODE 1 - SCENE 12
INT. NORTH ROOM - NIGHT

MARGUERITE sets the ledger down. The North Room is cold.

MARGUERITE
The North Room stays locked until the auction.

HARBOR LINE - EPISODE 2 - SCENE 7
INT. NORTH ROOM - DAY

DEV
Room N is what the survey calls it.

MARGUERITE
Then the North Room has two names and one lock.

INT. BALLROOM - LATER

[extracted for the North Room thread - check against draftC]
INT. NORTH ROOM - NIGHT

MARGUERITE
The North Room is empty.

That third file has a line at the top that is not script. Whoever pulled the scene out of the PDF for you left a note in the text. Remember it; it becomes the best part of the exercise.

Choose one source version per script

Before any searching, write a manifest. One row per working file, and the row has to say which script it is, which revision, and where the original pages or scene labels live.

Two things to notice. First, none of the three included file names carries a revision tag — harborline_ep01_sc12.txt could be draft A or draft Z and you would have no way to tell — so the manifest is doing work the file system isn't. The one name that does carry a tag, harborline_ep04_sc02_draftB.txt, is the exception, and it is the ambiguous row: the tag says which revision the file is, but not whether that revision belongs in the corpus, or which revision the untagged harborline_ep04_sc02.txt sitting beside it actually holds. The manifest settles both. Second, the fourth row is a duplicate scene — for this walkthrough I'm making it a straight copy of the third file, same four lines. Real drafts usually differ, and if yours does you get something worse than a doubled count: an inflated count plus a phrasing that no longer exists in the current script. The clean copy keeps the arithmetic visible.

The manifest also has to say what's missing. This corpus holds three scenes from three episodes. Episode 3 is absent. Everything past episode 4 is absent. Write that down where you can see it, because a corpus of three fragments will otherwise quietly become "the show" by the time you're writing the bible entry.

Prepare text without silently rewriting dialogue

Copy the text. Check the encoding. The AntConc site's Official releases section names 4.4.2 as the current release, and its encoding FAQ covers UTF-8 import failures — which is the practical reason to look at this before you search rather than after your apostrophes turn into garbage. (laurenceanthony.net/software/antconc)

Export a sample and compare it against the source before you trust the whole batch. Then remove only noise you can identify as noise, and keep a note of what you removed. In the fixture, that bracketed extraction line is noise: it is a human's reminder, not dialogue, and it does not exist on any page of the script.

I'm leaving it in for now. That is deliberate. Watch what it does to the numbers.

Do not tidy anything else. If you normalize "Room N" into "North Room" so your searches look cleaner, you have destroyed the exact question you came to ask. Punctuation, spacing, and odd capitalization in a script export are evidence about the export and sometimes about the writing. Leave them.

Plain text also loses pagination. That is fine as long as you keep scene labels in the text and the page map in the manifest. The working copy is a retrieval aid. It is not the source, and it does not replace the source.

Run a literal query with visible context

The tool here is AntConc's keyword-in-context (KWIC) tool. The 4.4.2 help, on printed pages 5–6, documents loading a corpus, the query controls, the surrounding context display, sorting, paging through results, and opening the file context from a concordance row. That's the route.

I have not run it. There is no screenshot in this article and no exported result, and you shouldn't accept a count from me as though one existed. What I can give you is a hand-checked expectation to compare against your own run.

Start literal. Search North Room, case-sensitive, no whole-word restriction. Look at what sits to the left and right of each hit before you count anything.

Change one search condition at a time

Here are my hand counts across the three files, with the extraction note still in place.

Four separate levers, one at a time.

Case. Going case-insensitive adds three hits, and all three are slug lines: INT. NORTH ROOM. Those are real uses of the room name. A slug line establishes that the room is in the scene at all, which is often exactly what you want to know. So the "extra" three hits are not noise — they're a different kind of evidence, set direction rather than dialogue, and you should decide deliberately whether your question wants them.

Whole word. Substring matching adds exactly one hit over whole-word: the BALLROOM slug line in 1x02. That one is noise for this question. It's the case where changing the setting buys you a false friend. The lesson isn't that whole-word is correct; it's that the difference between the two settings is small enough that you can actually read it.

Aliases. Room N appears once, in 1x02, in Dev's mouth. If you search only for that alias you will conclude the survey name barely exists. If you search only for North Room you will never see it at all. Episode 1 uses the family name twice and the survey name zero times — which means a zero result for Room N in 1x01 tells you nothing about whether the room is in that episode. It's in it twice. A missing text match is a fact about your search string, not about the story.

Corpus contents. Put the duplicate file back in and run the same queries.

The Room N row does not move, because 1x04 doesn't use that name. So the count alone cannot tell you the corpus is doubled: one query is unaffected while every other query is inflated by the same file. And the inflation is concentrated in a single episode, which is precisely the shape a "recurring" claim takes when you don't go looking.

Now set the duplicate aside again, so you are back to the three included files, and delete the extraction note, which is what you should have done during preparation. North Room, case-sensitive, drops from 5 to 4. Case-insensitive, 8 to 7. Whole-word room, 9 to 8. With the duplicate still in, that same edit moves the numbers differently — 7 to 5, 11 to 9, and 12 to 10 — which is the arithmetic you would have been quoting if you had not noticed the extra file.

Sort the results so the repeated contexts sit next to each other — that is what turns a list of hits into a picture of how a term is actually used. Then page through the whole result set. A visible screen is not the corpus. A filtered subset is not the corpus.

Return to the source before making the bible claim

File View opens the working text file from a concordance row; that's what the help describes on pp. 5–6. It is not a verified jump to page 43 of your original PDF, because your working file is plain text with headers and no pagination. This is the step where the manifest earns its place: from the working file and its scene label, you go to the page range in the manifest, and from there to the page.

So trace the hits.

The first North Room hit in 1x04 Sc. 2 is on that bracketed line. Open the script. There is no such line on pages 8–9 — it was added during extraction. That hit has no source, which means your count of 5 was never a count of the script. It was a count of your working copy, including a note about your working copy. It's a tidy little demonstration of why the file identity in the manifest matters more than the number in the status bar.

The second 1x04 hit is real, and it is The North Room is empty. That is a line in which the room is named in order to say nothing happens in it. Count it as an occurrence if you like. Citing it as evidence that the room matters would be a different move, and the concordance did not make it for you.

For 1x02, confirm who is speaking. Room N belongs to Dev, in a scene where Marguerite answers with the family name. One line is a character explaining a survey; the other is a character refusing it. A bible entry that says "the room is called both things" is defensible. An entry that says "the naming is contested" is a reading, and you should be able to defend it from the scene, not from a hit count.

Write the claim against the scene — season, episode, scene, page, speaker — and let the count live in your notes, not in the sentence.

Keep the query record and its limits

Retrieval leaves a paper trail, or it isn't retrieval. For every search that produced something you intend to use, record:

• Corpus identity. The file names and, more importantly, the revisions. The manifest is part of the record.
• What's excluded. The older draft, the scenes you don't have permission to use, episode 3.
• Tool and version. The version you actually have installed, not the one on the website.
• Query settings. The string, case, whole-word, sort order, context width.
• Which hits you inspected. Not just the total — the ones you read. A count you never opened is a number, not evidence.
• Unresolved passages. The hits that could be dialogue or could be export noise, left flagged rather than decided.
• Date. So a later revision of the manifest doesn't silently invalidate the record.

Keep zero results too, and keep what you did about them. A zero sends you to four checks before it means anything: did you search the other names, is the encoding right, does the corpus actually cover that episode, and is the phrase maybe just worded differently than you remember. In the fixture, a zero for Room N in 1x01 was a coverage fact about the alias, not about the room.

Then stop. Deciding which name the bible should prefer, whether the "empty" line matters, whether the room deserves an entry at all — those are editorial judgments made by a person reading the scene. A concordance is good at returning occurrences and terrible at having opinions. Keeping it that way is what makes it trustworthy when you do use it.

What you have at the end is modest and useful: three versioned files you can account for, a manifest that says what's in and what's out, a query record with the settings attached, and a short list of passages each tied to a scene you can open. Everything above the passage — the wording you choose, the significance you assign — stays on your side of the line, where it belongs.

Frequently asked questions

What is a concordance hit, and what does it not prove?

A hit is an occurrence of a string in a file placed in the corpus. It is not a claim about the story. A room named eleven times is not automatically important, and a room named once can carry a season. The concordance tells you where to look; it does not tell you what to think.

Why keep a manifest with revisions and exclusions?

The included file names need not carry revision tags, so the manifest records which script, revision, and original pages each working file represents. It also records duplicates and exclusions, such as the older draft left out and the missing episode 3. Without that record, a duplicated or outdated file can inflate counts and preserve phrasing that no longer exists in the current script.

How do case, whole-word setting, and alias choice change the North Room counts?

Case-insensitive searching adds three hits that are all slug lines, INT. NORTH ROOM. Substring matching adds one hit over whole-word: the BALLROOM slug in episode 2, which is a false friend for this question. Room N appears once, in episode 2, in Dev's mouth; a zero for Room N in episode 1 says nothing about whether the room is in that episode because episode 1 uses the family name twice.

Why can adding the duplicate older draft mislead without looking obvious?

It inflates most counts, but the Room N count does not move because episode 4 does not use that name. So a single unaffected query can hide a doubled corpus while every other query is inflated by the same file. The inflation is concentrated in one episode, which is the shape a recurring claim can take when no one checks the corpus contents.

What belongs in the query record, and where does the bible claim come from?

The record should include corpus identity and revisions, exclusions, the tool version actually installed, query settings, which hits were inspected, unresolved passages, and the date. Zero results should also be kept, with checks for other names, encoding, corpus coverage, and different wording. Bible claims should be written against the scene, season, episode, scene, page, speaker, while the count stays in your notes. Deciding preferred naming or significance is an editorial judgment.

Further reading

• Add a Working Index to a Long Series Bible — A different door into the same bible: an index built from the terms collaborators actually look up, when the question is a reader's noun rather than a string.
• Edit a Series Bible for the Collaborator Who Has to Build From It — The step after counting: how to label a bible sentence as governing, illustrative or open so the next writer can build without guessing which claims are rules.