Belief vs fact: modeling what each character knows

Most software treats facts as facts. In a contract, in an email, in a spreadsheet, that works fine — there’s one source of truth, and consistency means the data agrees with itself. (This post is the deep cut on knowledge continuity — one of the seven sub-disciplines covered in our continuity pillar guide.)

Fiction breaks this assumption.

In a story, the most important thing happening in a scene is often what one character believes that another character doesn’t believe yet. Hamlet is a play about a man who’s been told one thing by a ghost and is trying to figure out whether anyone else is going to find out what he’s been told. Pride and Prejudice is largely a series of conversations in which characters draw conclusions from incomplete information. The asymmetry of who-knows-what is the engine of the plot.

If a story tool flattens belief into fact, it’s missing the part that makes fiction fiction.

This post is about a feature in PlotLens that tracks what each character knows — belief-vs-fact modeling — why it exists, and what it lets you catch that a flatter tool wouldn’t.

The bug nobody talks about

Here’s a contradiction that almost no continuity tool will catch:

Chapter four, page 120. Maren tells Aldric that her father is dead.

Chapter eleven, page 280. Aldric, in conversation with someone else, says he’s not sure whether Maren’s father is alive or dead.

Is this a contradiction? It depends.

If the writer’s intent is that Aldric is uncertain, despite Maren telling him directly, that’s a deliberate character choice — maybe Aldric doesn’t trust Maren, or has reason to think she’s lying about her father. The chapter-eleven scene is correct relative to the writer’s intent.

If the writer’s intent is that Aldric believes Maren, then the chapter-eleven scene is a continuity error: Aldric’s been told, and he’s forgotten the writer told him.

A continuity tool that only tracks “facts” sees both scenes and either flags both or flags neither, depending on how it computes contradiction. Either way it’s wrong some of the time, and after enough false flags the writer stops trusting the tool.

The fix isn’t a better algorithm. It’s a different model.

What belief vs fact means

PlotLens tracks two parallel sets of state for every character:

1. Narrative facts (canon rules). What’s actually true in the world of the story. Each rule carries an EpistemicStatus — FACT by default, but also RUMOR, LIE, DREAM, RETCON, RED_HERRING, UNRELIABLE_POV, or SPECULATION when the story treats a claim as something other than ground truth. The narrator (or the manuscript itself, in tighter POV) is the authority for this layer.

2. Character beliefs. What each character has been told, has witnessed, or has reason to know — based on the scenes they’ve been in and the conversations they’ve heard. Each belief carries a BeliefStatus of BELIEVES_TRUE (the character holds the fact as true), BELIEVES_FALSE (they hold the opposite), UNAWARE (they haven’t encountered the fact yet), or SUSPECTS (they’ve got a hunch but no confirmation).

When you write a scene where character A tells character B that her father is dead, two things happen in the model:

• The canon-rule layer records that her father is dead — with status FACT by default, or LIE if the writer or the extractor has tagged A’s statement as a lie.
• B’s belief state for that fact becomes BELIEVES_TRUE — they’ve been told on-page, and the validator now expects them to act on it.

These are different. They might agree. They might not. Plot is what happens at the seams.

The thing this catches

When PlotLens runs a POV-scoped validation on a new chapter, the belief-vs-fact layer surfaces a Knowledge state section with two distinct kinds of finding:

Knowledge violations (KNOWLEDGE_VIOLATION). A character acts on information they haven’t been told — formally, a passage where the character treats an UNAWARE fact as known. The classic example: the protagonist arrives at a meeting with information she could only have learned in a scene she wasn’t in. The validator reads the scenes the character has been in, and if she walks into chapter twelve already knowing something that was only revealed off-screen in chapter ten, the result will tell you the line where she demonstrates that knowledge — and the absence of the transmitting scene that should have introduced it.

Forgotten reveals (FORGOTTEN_REVEAL). The flip side: a character has been told something (their BeliefStatus is BELIEVES_TRUE) and a later scene writes them as if they don’t know it. (See the Aldric example above.)

In both cases, the report is precise. It tells you the scene where the knowledge should have transferred, the scene where the inconsistency surfaced, and the source sentences for both. You can click through to the actual lines and decide for yourself whether the model misread the writer’s intent or whether the writer accidentally introduced a real continuity error.

Why this matters most for thrillers, mysteries, and romances

Every fiction genre uses asymmetry of information, but three genres rely on it:

Mysteries. The detective knows things the reader doesn’t, and the reader is gradually given access to what the detective knows. Continuity errors here aren’t cosmetic — they’re the entire game.

Thrillers. Tension comes from one character knowing what’s coming and another character being unaware. If the writer accidentally lets the unaware character in on the information one chapter early, the climax loses its punch.

Romance. Especially in slow-burn romance, the will-they-or-won’t-they hinges on what each character has and hasn’t said out loud. Writers spend chapters carefully managing these states. Software that flattens them is actively harmful.

Speculative fiction (sci-fi, fantasy) inherits the same problem at series scale: who knows about the magic system, who’s met which faction, who’s discovered the prophecy. PlotLens treats every revelation as an event in a character’s belief layer, and every silence about that event as a constraint on what the character can know in later scenes.

What this looks like in the product

When you open a project in PlotLens and look at a character, you see two tabs: What’s true about them (the narrative facts the character is named in) and What they’ve been told (their belief states). Both are populated automatically from the manuscript. Every entry has provenance — it links to the sentence in the manuscript where the belief was established.

When you run a validation in POV mode (pick a POV character on the validation form), the result includes a Knowledge state section listing any belief-vs-fact tensions the model found. Each finding has the same structure:

• The character it’s scoped to
• A short claim describing the knowledge in question
• The transmitting scene that should have introduced the knowledge (or a note that none was found)
• The violating scene — the passage where the inconsistency surfaces
• Reason-code chips explaining why the validator flagged it (see the reason-code reference)

You decide whether to fix it, ignore it (because it’s intentional — Aldric doesn’t trust Maren), or mark it as deliberate. Marked findings collapse into a “Marked as deliberate” pill on the card and stop appearing on subsequent runs of the same scene against the same character. For the complete reference, see the Belief vs Fact doc.

The principle

Most AI tools applied to writing assume the writer wants help generating words. PlotLens assumes the writer wants help keeping track of what’s true and who’s been told. Belief-vs-fact modeling is the most distinctively-fiction part of that, and the part that no general-purpose knowledge graph will get right out of the box.

Being wrong can be a plot point. Being wrong by accident isn’t.

If you want to see belief-vs-fact running on a real manuscript:

Try a validation on your work-in-progress →

---

Last updated 2026-05-15. For the canonical reference, see Belief vs Fact.