Skip to content

ProseGuard

There’s a specific kind of problem in fiction writing that models are bad at catching and that humans are inconsistent at catching. A character whose pronouns drifted between two scenes because a late draft change didn’t propagate cleanly. A subplot villain whose name you retconned from “Kael” to “Ira” eight chapters ago, except chapter eleven still says “Kael” once. The em-dash you use seventeen times in one paragraph because you were on a roll. The word “delve” that you typed without noticing, because every writing assistant in the world trained the word into you as a synonym for “explore.” These are the kinds of problems where the fix is obvious the moment you see them, but seeing them in a 90,000-word manuscript is exactly the thing that tired authors fail at. ProseGuard is the tool for that problem. It’s a rule-based linter with no model involvement, completely deterministic, and the rules are the ones you define. Same input always produces the same output, every time, forever. When ProseGuard flags something, it’s flagging it because a specific rule said so, and you can read the rule. No opinions, no hallucinations, no “the model thinks this might be an issue.” Just pattern matching against rules you set yourself.

Six rule categories, a four-level scope hierarchy for cascading overrides, and enough configurability that you can shape the linter to your project’s exact style without fighting generic defaults. This page walks through all of it.

Document-level formatting rules. These catch the kind of thing that’s hard to eyeball but easy to measure:

  • Max sentence length — flags sentences longer than your word limit. Useful when you’re trying to keep a tight voice and a 60-word sentence sneaks in.
  • Max paragraph length — flags paragraphs that cross your word limit. Useful for pacing — dense paragraphs slow the reader.
  • Max em-dashes per paragraph — the single most useful rule the models won’t catch themselves. Model-generated writing tends to pile on em-dashes, and a “three per paragraph max” rule catches drift toward that cadence.
  • Max ellipses per paragraph — same idea, different punctuation.

Word and phrase-level rules:

  • Banned phrases — multi-word phrases that must not appear. Typical additions: “a tapestry of,” “the weight of,” “navigating the complexities of,” and the rest of the Machine Tells vocabulary.
  • Banned words — individual words. “Delve” lives here. So does “whilst” if your voice is American. So does any word you’ve decided to stop using for craft reasons.
  • Max word repetition per paragraph — flags any word that appears too many times in a single paragraph. Catches the specific drift where a word you like gets used three times in eighty words and makes a paragraph feel amateur.

Narrative perspective and character voice rules:

  • POV mode — enforces a point of view at the document level (first person, third limited, third omniscient, second person). ProseGuard detects pronouns that violate your chosen POV. Useful when a slip into third-omniscient sneaks into what’s supposed to be a tight third-limited chapter.
  • Forbidden POV — explicitly forbid POV types. Forbid second person in a third-person novel and any stray “you” reference gets flagged.
  • Character pronouns — map each character to their pronoun set (he/him, she/her, they/them, custom). ProseGuard flags text that uses incorrect pronouns for a named character.

The character pronoun rule is the one that catches late-draft inconsistencies nothing else catches. Change a character’s pronouns in revision, miss a spot in chapter eight, and ProseGuard will tell you exactly which paragraph is wrong.

Term consistency across the project:

  • Forbidden terms — terms that must never appear. The retconned character name, the cut faction, the deleted magic word that you accidentally left in one paragraph. Add it to the forbidden list and ProseGuard finds every stray occurrence.
  • Allowed terms — override the forbidden list for specific contexts. Used when a scene-level or character-level rule needs to permit a term the project forbids — say, a flashback chapter where the old character name is appropriate.
  • Required name forms — enforce specific spellings for character and place names. “Kent Musa” is canonical; “Kent Moosah” is a typo from draft two. The required name form catches alternate spellings automatically.

This is the category that matters most for authors who use model assistance at all. It catches the specific patterns that indicate model-generated or model-influenced prose:

  • Flagged words — “delve,” “tapestry,” “myriad,” “weave,” “navigate,” “harness,” “realm,” and the rest of the standard machine vocabulary.
  • Flagged phrases — “a testament to,” “the weight of,” “in the realm of,” “at its core,” “in today’s landscape,” and dozens of other phrases that sound literary but read as machine output.
  • Flagged dialogue tags — tags the models tend to overuse. “Breathed,” “murmured,” “hissed” used as dialogue tags are almost always a sign of machine influence.
  • Flagged character names — “Elara,” “Kael,” “Lyra,” “Zephyr,” and the rest of the default fantasy name set the models reach for. If your world has one of these as a character name because you actually chose it, flag it as allowed.
  • Filter words — “simply,” “merely,” “quite,” “rather,” “actually,” “basically.” Model writing uses filter words constantly because they sound measured. Fiction doesn’t need them.

The Machine Tells category is the one most authors spend the most time configuring, because the default set is aggressive by design. Turn off what doesn’t match your voice; leave on what does.

Timeline and chronology consistency, integrated with the Timelines module:

  • Date format consistency — checks that dates follow a consistent format within and across documents.
  • Anachronism detection — flags events or references that conflict with your timeline. If a character in chapter four references an event that, per your timeline, hasn’t happened yet, ProseGuard catches it.
  • Location conflict — detects characters or events appearing in multiple locations simultaneously.

Temporal rules only fire if you have a timeline set up in the Timelines module. Without that data, there’s nothing to validate against.

Rules live at four levels, with narrower scopes overriding broader ones:

  1. Project — the baseline for your entire project. Most rules live here.
  2. Document — rules that apply only to a specific document. Useful for chapters with unique needs.
  3. Scene — rules that apply only to a specific scene within a document.
  4. Character — rules that apply to a character’s sections. Different banned words for a character who speaks in dialect, for example.

Each category can be independently enabled or disabled at any level. A character-level override beats a scene-level override beats a document-level override beats a project-level default.

ProseGuard rules can be configured directly from lore entry detail panels in the Legendry. Open a character entry, expand the ProseGuard section, set:

  • Character pronouns — he/him, she/her, they/them, custom.
  • Required name forms — the canonical spelling for this character.
  • Forbidden or allowed terms — scoped to the character’s sections.

Changes save immediately and apply the next time you lint. This is the easiest way to configure character-level rules without opening the full rule editor — you’re already in the character’s entry, you just add the rules there.

Every violation gets classified as one of three levels:

  • Error — must fix. Prevents the document from being considered clean.
  • Warning — should fix. Potential problems that might be intentional.
  • Info — advisory. Informational flags for awareness.

Severity is set per-rule when the rule is defined. A character pronoun violation might be Error; a filter word might be Warning; a sentence length violation might be Info.

Open a document in the editor, open the ProseGuard panel from the sidebar, click Lint Document. The check runs against the resolved ruleset (project + document + scene + character cascade applied) and returns:

  • Total violation count.
  • Counts per category.
  • Counts per severity.
  • The full list of violations sorted by location.

Each violation shows its rule, description, severity, and exact location. Right-click for:

  • Go to issue — scroll the editor to the violation.
  • Ignore this instance — suppress this specific violation.
  • Ignore this rule — suppress all violations from this rule for the session.
  • Open settings — jump to the rule editor for this rule.
  • Copy details — copy the violation details to clipboard.

ProseGuard detects when your content or rules have changed since the last lint run. If the results are stale, the panel shows a “re-check recommended” indicator so you don’t mistake outdated results for current ones.

Three levels of suppression, from most specific to least specific:

  • Ignore this instance — dismisses a specific violation at a specific location. The rule still runs, but this one flag won’t appear in future checks.
  • Ignore this rule — suppresses all violations from a specific rule for the current session. Useful for working through a specific category without being distracted by another.
  • Clear suppressions — resets all ignores. Use when you want a fresh check with nothing hidden.

Suppressions are session-scoped by default. Restart Ishvana and suppressions clear unless you explicitly persist them.

A built-in UI for editing rules. Open it from the gear icon in the ProseGuard panel, from a violation’s context menu (“Open Settings”), or from the main settings modal.

The editor lets you:

  • Switch between scopes (project, document, scene, character) via a dropdown.
  • Edit individual fields within each rule category — add to banned word lists, change max sentence length, toggle categories on and off.
  • Save rules and re-lint to see the effect immediately.

Changes are race-guarded. If the scope changes while rules are loading, stale responses get discarded.

ProseGuard supports exporting all rules for a project as a YAML document and importing from YAML. Useful for:

  • Sharing style guides between projects. Set up rules once, export, import in future projects.
  • Backing up your configuration. Rules are data, and losing them because of a database issue would be annoying.
  • Collaborating with co-authors. Send your ProseGuard YAML to a co-author and they can import it as the canonical project style guide.

Import supports a dry-run mode that validates the YAML without saving — useful for catching schema errors before you commit to a bulk import.

When Hawken is about to generate prose, ProseGuard can inject lightweight hints into the prompt before generation runs:

  • The active POV mode for the document.
  • Character pronoun requirements for any character referenced.
  • The top forbidden terms to avoid.

These hints are advisory. They help Hawken avoid generating prose that would immediately fail the post-generation lint, which reduces the amount of Accept/Reject back-and-forth you have to do on each suggestion. But they’re not authoritative — the real enforcement is the lint pass after generation, not the prompt hint before it.