Character Knowledge

Here’s the specific class of continuity error that ruins an otherwise tight draft. Your protagonist learns a dark family secret in chapter twelve. Three chapters earlier, in chapter nine, you wrote a scene where the protagonist references the same secret in their internal monologue — because by the time you drafted chapter nine, you’d already mapped out the reveal in your head and your own knowledge of the story bled into the character’s. The protagonist knows something the protagonist shouldn’t know yet. Your prose is internally inconsistent in a way that’s hard to catch on a re-read because you, the author, do know the secret by chapter nine, and your brain fills in the reader’s experience based on your own knowledge. A careful beta reader catches it eventually. A less-careful beta reader catches it in a review.

Character Knowledge Tracking is the feature that prevents this. You declare what each character knows and when they learn it. The system walks your outline in narrative order, computes which facts each character has access to at each scene, and scans your prose for violations — places where a character references knowledge they haven’t learned yet. Two kinds of scanning: a fast keyword-based check and a deeper semantic check that calls a model. Violations get surfaced with specific evidence so you can fix them.

This is probably the single most-useful feature in Ishvana for continuity-heavy fiction, and most authors discover it months after they’ve been bitten by the exact problem it solves.

Knowledge facts

A knowledge fact is a declaration that a character knows (or will learn) a specific piece of information. Facts come in three types:

Lore Entry — the character knows the contents of an entire lore entry. “Kent knows The Founding of House Solaris.”
Lore Section — the character knows a specific section within a lore entry. “Kent knows the Origins section of The Betrayal but not the Aftermath section.”
Custom Fact — freeform text for knowledge that doesn’t have a lore entry yet. “Kent doesn’t know his mother is alive.”

Each fact has a learn point:

Known from start — the character has always known this. Use for backstory facts the character brings into the book.
Learned at scene — the character learns this at a specific scene in the outline. Use for facts revealed during the story.

The learn point is what makes the timing work. A fact learned at scene 47 means the character knows it from scene 47 onward but not in scenes 1-46.

Knowledge state

For any character at any scene, the system computes what they know and don’t know yet. It walks the outline in narrative order and partitions the character’s facts into two lists:

Known facts — facts the character has already learned by this point (either “known from start” or “learned at a previous scene”).
Unknown facts — facts the character hasn’t reached yet in the timeline.

This state shows up in the Outline Detail Panel as two lists: “Knows at this point” and “Doesn’t know yet.” Switch between characters to see each one’s knowledge state at the current scene.

Violation detection

Two kinds of scanning run against your prose — one fast and mechanical, one slower and smarter. Both surface violations as actionable items you can review and fix.

Keyword scanning

A deterministic scanner that checks each scene’s prose for knowledge leaks. The algorithm:

Extract text from the scene’s linked document.
For each character present in the scene, collect their “doesn’t know yet” facts.
Extract keywords from each unknown fact.
Check for keyword overlap between the scene text and the unknown fact.
If the overlap exceeds a configurable threshold, flag a violation.

Keyword scanning runs in milliseconds. It’s fast enough to run on every save if you want. It’s also mechanical — it catches obvious leaks where the character mentions a specific name or term from a fact they shouldn’t know, but it misses subtler issues like a character reacting emotionally to something they shouldn’t be aware of.

The scanner replaces stale results on each run but preserves resolved violations, so triaging false positives is a one-time action that sticks.

Semantic analysis

Uses your configured model provider (via Etherforce) for deeper semantic understanding of potential violations. The semantic pass looks for:

Direct references to unknown facts, even when the exact words differ from the fact text.
Decisions that only make sense if the character knows the fact. “She turned left at the junction” when the character doesn’t know which direction the safe house is.
Emotional reactions that presuppose knowledge. Grieving over a death the character doesn’t know happened.
Dialogue that hints at forbidden knowledge without explicitly stating it.

Each semantic violation includes quoted evidence from the scene text and an explanation of why it was flagged. This is the check you run on chapters that have already passed keyword scanning — it catches the subtler issues keyword matching can’t find.

Semantic scanning is slower (LLM calls, per-scene) and more expensive (tokens). Run it deliberately, not continuously. The typical workflow is keyword scanning on every save and semantic scanning before a pre-submission pass.

Violation management

Every violation has a status. You can mark it resolved (dismissed as a false positive or intentionally allowed) or leave it unresolved (flagged for correction). Filter the violation list by type (keyword vs. semantic), status, and affected character.

False positives are real — both scanners err toward surfacing too many issues. Mark them resolved and they stay resolved across future scans.

Where knowledge tracking appears

Several surfaces across Ishvana integrate with the knowledge system:

Outline Detail Panel

In the detail panel for scene-level outline nodes:

Character selector — a dropdown populated from the scene’s POV character and entity references.
“Knows at this point” and “Doesn’t know yet” lists with fact titles and learn points.
Add Knowledge Fact — an inline form with type selector, searchable lore entry picker, and “Known from start” checkbox.
Violations section — unresolved violations for the current node and character, with resolve buttons.
Scan buttons — “Scan Scene” for keyword scanning, “Deep Check” for semantic analysis.

Lore Detail Panel — “Who Knows This?”

A collapsible section on each lore entry showing every character that has a knowledge declaration for the entry. Each card shows character name, timing badge (Known from start / Learned at scene X), and the section or custom fact details. Undeclared characters appear with a quick “Declare” button so you can add knowledge facts without leaving the lore entry.

This view answers the inverse question: instead of “what does this character know,” it’s “who knows about this thing?”

Lore Intelligence — Knowledge Violations Panel

A dedicated view in the Lore ML section of the Analysis workspace:

Filter bar — type (All / Scan / Semantic), status (All / Unresolved / Resolved), character.
Summary badges — total, unresolved, and filtered counts.
Violation cards — color-coded severity, character name, scene title, description, suggested fix, and context snippet.
“Go to scene” action — navigates directly to the violating outline node.
Action buttons — “Run Full Scan” and “Deep Check All Scenes” for project-wide passes.

This is where you go for triage mode — not per-scene checking but a full view of every open knowledge violation across the project.

Matrix View — Knowledge Layer

A layer toggle in the Matrix View adds a Knowledge option:

Green dots — character is present with no unresolved violations in this scene.
Amber dots — character is present and has unresolved violations.
No dot — character isn’t in the scene.

For an at-a-glance view of information flow through your whole manuscript, this is the most powerful single view in the Character Knowledge system.

Settings

Three configurable knobs for the scanner:

Keyword minimum length. Slider, 3 to 10, default 5. Words shorter than this get ignored during scanning. Higher values mean fewer false positives but may miss short keyword matches.
Keyword overlap threshold. Slider, 1 to 10, default 3. Minimum number of overlapping keywords required to flag a violation. Higher values reduce false positives at the cost of missing some real violations.
Scan scope. Either “POV Only” or “All Characters.” Controls whether scanning checks only the scene’s POV character or every character present.

Most authors leave these at defaults. Adjust if you’re getting too many false positives or too few catches.

How to actually use it

A typical workflow:

Declare knowledge facts as you write. When you add a scene where a character learns something important, open the Outline Detail Panel for that scene, pick the character, and add a knowledge fact. Takes twenty seconds per fact.
Review knowledge state when drafting. Before writing a scene, open the knowledge panel for the POV character and scan the “knows at this point” list. You’ll remember what they know — and more importantly, what they don’t.
Run keyword scans regularly. Click “Scan Scene” whenever you finish a draft of a scene. Fast and free. Catches obvious leaks.
Run semantic scans before pre-submission passes. Use “Run Full Scan + Deep Check All Scenes” once per major draft milestone. Slower and more expensive but catches the subtler issues.
Triage violations. Review flagged issues, resolve false positives, fix real problems, re-scan.
Monitor at scale via Matrix View. Green and amber dots across the whole manuscript tell you at a glance where your knowledge consistency is holding and where it’s slipping.

What’s next

Legendry The worldbuilding database where knowledge facts originate.

Lorekeeper Agent-driven consistency checking that complements knowledge tracking.

Outline & Structure The outline system whose narrative order drives the knowledge timeline.