What does it mean for software to “understand” a story?

Not summarize it. Not generate more of it. Actually understand it — the way a showrunner’s assistant understands the bible for a long-running series, holding every character relationship, timeline constraint, and world rule in their head, and flagging when something doesn’t add up.

That’s the problem we set out to solve with PlotLens. And the answer turns out to be less about large language models and more about data modeling. The interesting work isn’t in asking an LLM “does this contradict anything?” — it’s in building the structured representation that makes the question answerable in the first place.

This post walks through the four systems that power PlotLens’s narrative intelligence. If you manage a large story world — a game with hundreds of NPCs, a TV series with a rotating writers’ room, an epic fantasy spanning a dozen books — this is how we keep track of it all.

Entity extraction and coreference: one character, many names

The foundational problem in fiction NLP is deceptively simple: figure out who’s who.

In Chapter 3, your manuscript refers to “Detective Reyes.” In Chapter 7, another character calls her “Sarah.” In Chapter 12, her daughter says “Mom.” A reader builds these connections naturally. Software has to be taught.

This is coreference resolution, and it’s been an active research area in computational linguistics for decades. Projects like BookNLP — a pipeline developed at Stanford for analyzing book-length texts — demonstrated that literary coreference requires specialized models. Generic NLP systems trained on news articles choke on the conventions of fiction: omniscient narration, dialogue attribution, nicknames that only appear in certain relationships. BookNLP showed that training on actual novels improved entity recognition F-scores from 45.7 to 68.3. Fiction is its own domain.

PlotLens builds on these foundations. When you upload a manuscript, the extraction pipeline identifies every entity — characters, locations, objects, events, concepts — and then resolves coreference chains across the full document. “Detective Reyes,” “Sarah,” and “Mom” get linked into a single canonical entity with multiple surface forms, each tagged with the context where it appears.

But we go further than name clustering. PlotLens also detects implicit entities — the ones never named directly. A passage that reads “the city had been rebuilt after the war” implies both a city and a war that may or may not have been introduced elsewhere. These get flagged as implicit entities with bridging links to any explicit mentions that might be the same referent. For a game narrative team managing 400 NPCs across branching questlines, this is the difference between catching a duplicate early and discovering it after voice recording.

Provenance: every fact has a receipt

Here’s something that bothered us about existing tools: they’d tell you a character’s eye color is blue, but not where in the manuscript that fact was established.

PlotLens’s provenance system is inspired by the W3C PROV data model — a standard originally designed for tracking the lineage of scientific data. The core idea maps surprisingly well to fiction: every assertion about your story world should be traceable to its origin.

In practice, this means every extracted fact carries an attestation chain. When PlotLens says “Reyes has brown eyes,” it links that fact to the specific sentence in Chapter 2 where the description appears: “She caught her reflection in the window — dark eyes, darker circles beneath them.” If a second document later says “green eyes,” both attestations are preserved, and the conflict is surfaced with full citations.

This matters most at scale. When fifteen writers are contributing to a shared story world, and someone introduces a contradiction, the question isn’t just “is this wrong?” — it’s “which source established the original fact, and does the new writer even know about it?” Provenance turns a vague inconsistency flag into an actionable conversation between two specific documents.

Temporal intelligence: when did it happen, and when did you write it?

Stories have timelines. So does the writing process. These two timelines are different, and conflating them causes real problems.

Consider a mystery novel. In-story, the murder happens in January. The detective discovers a clue in March. The reader learns the truth in the final chapter. But the author wrote the final chapter first — they plotted backward from the reveal. When they later draft the January scenes, they need to ensure those early chapters don’t accidentally contain knowledge the characters shouldn’t have yet.

PlotLens uses a bitemporal model to handle this. Every fact is indexed along two time dimensions: story time (when something happens within the narrative) and ingestion time (when the document containing that fact was uploaded to PlotLens). This lets you ask questions that neither dimension alone can answer:

“What did PlotLens know about this character as of Chapter 5?” — story time scoping
“What changed in the canon since I uploaded my last batch of documents?” — ingestion time scoping
“Show me facts that were established in the first draft but contradicted by the revision uploaded yesterday” — both dimensions combined

If you’ve worked with bitemporal databases in financial systems or audit logging, the concept is the same. We adapted it because narrative worlds have the same fundamental property: facts change over time, and you need to reason about the state of the world at any given point.

Two-layer canon: truth vs. belief

This is the one that gets the most interesting reactions from writers.

Most continuity tools treat canon as a flat set of facts. The sky is blue. The magic system requires three components. The king died in the rebellion. Either something is true or it isn’t.

But fiction is more nuanced. An unreliable narrator might assert something false. A character might believe something that contradicts established fact. A questline might present information that the player character doesn’t yet know is a lie.

PlotLens models this with two layers. The objective layer captures ground truth — what’s actually true in the story world, as established by authoritative narration or confirmed across multiple sources. The belief layer captures what individual characters or POV narrators assert, tagged with an epistemic status: stated, believed, suspected, denied, unknown.

Back to our mystery. The killer tells the detective in Chapter 8 that he was home all evening. That’s a fact in the belief layer — it’s what the character claims. The objective layer, informed by the Chapter 1 narration, records that the killer left his apartment at 11 PM. PlotLens doesn’t flag the Chapter 8 dialogue as an error. It flags it as a character assertion that contradicts established fact, which might be exactly what the author intends.

For game narratives, this is essential. An NPC quest-giver who lies to the player isn’t a bug — but an NPC who accidentally contradicts the world bible because a writer didn’t check the lore document is. The two-layer model distinguishes between these cases.

What this means at scale

Each of these systems is useful on its own. Together, they compose into something more powerful.

When a narrative team of fifteen writers uploads a new batch of quest scripts, PlotLens extracts entities with full coreference resolution, attaches provenance to every fact, indexes each fact along both temporal dimensions, and evaluates it against both the objective canon and existing character belief states. Validation results come back with specific citations: “This script has NPC Kael refer to the Sundering as happening ‘a hundred years ago,’ but Document 47 (World History Bible, uploaded January 3) establishes the Sundering at 300 years before the current era. First attested in paragraph 14.”

That’s not a vague “possible inconsistency.” It’s a specific, actionable finding with a paper trail.

We built PlotLens because we believe narrative teams deserve the same rigor that engineering teams take for granted — version control, traceability, automated consistency checks. The stories are complex enough. The tooling shouldn’t make it harder.