Building and Maintaining Character Databases

Why a Character Database Is Not Optional

Two characters share one relationship line. Three characters produce three lines. Four produce six. Ten characters -- forty-five. This is not addition. It is combinatorial explosion, and it is the reason that novels above a certain length start developing cracks their authors never intended.

George R.R. Martin knows this better than anyone alive. A Song of Ice and Fire contains over two thousand named characters. He hired two full-time assistants to maintain a "series bible" -- every character's birth date, physical features, family connections, all recorded and cross-referenced. Two dedicated people watching every detail. And still, Jeyne Westerling was described as having "narrow hips" in A Storm of Swords and "good hips" two books later in A Feast for Crows. Readers caught it. Martin had to publicly acknowledge the mistake.

A world-class author with a professional tracking team, and the inconsistency slipped through anyway.

The damage these errors inflict on readers is badly underestimated. Nobody consciously thinks "this character is contradictory." What happens instead is subtler -- a vague sense that something is off. That feeling stacks, layer by layer, until the reader closes the book thinking "not quite well-written" without being able to say why.

Hemingway's iceberg theory carries a second meaning here. Readers see one-eighth above water. The seven-eighths below holds the whole thing up. Fail to document those seven-eighths and the visible portion wobbles. Characters turn "thin" -- because even their creator doesn't know who they are outside the story's frame.

Then there is memory. The most dangerous thought a writer can have: "I'll remember."

The protagonist's name? Obviously. Eye color? Probably. Mother's maiden name? Needs checking. Age during the first heartbreak -- wait. Was that ever decided?

A hundred thousand words. Twenty-plus characters. Six months or more of writing. When all three conditions align, memory starts to betray. Not the big things. The small ones. And small things bite at the worst moments -- Chapter 28, the character reminisces about childhood, suddenly the name of the first pet matters. Searching through every draft: Chapter 7 says dog, Chapter 15 says cat.

Building a Character Database in Slima

The previous article established a file structure that includes a characters folder. Time to turn that folder into something that actually works.

In Slima's File Tree, the character folder might look like this:

characters/
├── protagonists/
│   ├── john-protagonist.md
│   └── sarah-heroine.md
├── supporting/
│   ├── professor-chen-mentor.md
│   └── old-zhang-informant.md
├── antagonists/
│   └── victor-main-villain.md
└── _character-template.md

That _character-template.md at the bottom is the linchpin. The underscore prefix pins it to the top of the folder -- every new character starts as a copy of this file.

A complete character file covers six sections. Not because it looks professional, but because each section solves a specific writing problem.

Basic Info sets the character's coordinates. Birth era, hometown, current occupation -- these aren't form fields. They define worldview. Someone who grew up on a farm and someone who grew up in a downtown apartment stand in the same wheat field and think entirely different things. One remembers childhood. The other thinks about mosquitoes.

Physical Appearance doesn't need an ID card. Readers won't retain exact height and weight. What sticks is "a scar across the left eyebrow" or "always wearing that pilling red scarf." Identifying features -- the details that turn a character from a bundle of adjectives into a concrete person in the reader's mind.

Personality Traits need layers. The surface layer is the first impression others get: cold, chatty, jittery. The core layer runs deeper: fiercely loyal, insecure, desperate for validation. The most compelling characters carry tension between surface and core. Someone who appears to care about nothing but actually cares more than anyone -- that contradiction is not a bug. It is a feature. It makes the character real.

Background Story answers "why." He trusts no one -- why? His father died when he was fifteen, and he believes it was his fault. This trauma may never be fully revealed in the book, but it shapes every decision the character makes. The seven-eighths under the water lives here.

Motivation and Goals run on two tracks. External goals are what the character says they want: find the killer, win the competition, escape the predicament. Internal needs are what they truly need: learn to trust, accept themselves, let go of the past. Good story structure usually works like this -- the character chases the external goal, collides with the internal need halfway through, and is forced to face it.

Speech Style is the most overlooked element, and the one that brings characters to life fastest. Long sentences or short? Profanity or none? Nervous tics in speech? If every character name in a dialogue were blacked out, could a reader identify the speaker by voice alone? If yes -- that is a character. If no -- that is a talking prop.

Using AI to Maintain Consistency

Checking character consistency across a hundred thousand words by hand is, frankly, impractical.

Press Cmd+Shift+A (Mac) or Ctrl+Shift+A (Windows) to open Slima's AI Chat Panel. The AI Assistant reads the entire project structure, so cross-file checks are a baseline operation.

Consistency check -- physical descriptions:

Please check whether "John" is described consistently across all draft files.

Focus on:

1. Whether physical descriptions (height, hairstyle, eye color, distinguishing marks) remain consistent
2. Whether personality expressions match the character profile
3. Whether speech style stays unified

Please cite specific files and passages, and list any contradictions found.

What this prompt does is straightforward: it has the AI sweep every draft and compare descriptions of the same character across different locations. It might report "Chapter 3 has John wearing black-framed glasses; Chapter 15 switches to silver frames" -- the kind of detail that human review almost always misses.

Voice check -- dialogue style:

Here is John's dialogue from different chapters. Based on his character profile (characters/protagonists/john-protagonist.md), analyze whether these lines match his established speech style.

Check:

1. Whether sentence length and structure match the profile
2. Whether word choice habits are consistent
3. Whether emotional expression fits the personality

If you find mismatches, point them out specifically and suggest revisions.

The key to this prompt is feeding the AI two documents simultaneously. In the AI Chat Panel, use @ to reference the character profile, then paste dialogue passages. The AI compares the spec against the actual lines.

Relationship dynamics tracking:

Please analyze the relationship between John and Sarah throughout the book.

For each scene where they interact, note:

1. Chapter and scene location
2. Current relationship status (hostile / neutral / friendly / intimate)
3. How this scene shifts the relationship

Flag any relationship changes that feel too sudden or lack buildup.

This prompt catches fracture points in relationship arcs. Still arguing in Chapter 5, suddenly best friends in Chapter 6 -- the AI flags it directly: "transition missing here." Writers deep in the draft often forget the emotional temperature between characters from earlier chapters. The machine doesn't.

Maintaining While Writing

An outdated character file is more dangerous than no file at all -- it doesn't help, it misleads.

An experiment: starting today, every time a new character detail gets locked down in a draft, update the character file immediately. Not "in a minute." Not "later when I clean up." Immediately. Because "later" is a temporal location that doesn't exist in writing -- by the time "later" arrives, the detail is either forgotten or misremembered.

The split-window feature in Slima's Writing Studio (Cmd+ or Ctrl+) makes this habit cost nothing. Chapter draft on the left, character file on the right. Writing "John unconsciously touched the scar on his left eyebrow" -- glance right. Is the scar recorded? No? Three seconds to add it. Back to the left. Train of thought unbroken.

For undecided details, don't leave blanks. Blanks masquerade as "complete." Use explicit markers:

Later, a global search for "TBD" surfaces every unresolved detail at once. Ten times more efficient than rummaging through memory.

When a major character detail needs changing -- say, shifting the backstory trauma from "father died" to "father disappeared" -- go to Version Control (Cmd+Shift+G) first and create a snapshot. A change like this ripples outward. Death and disappearance produce different psychological effects on a character, altering dialogue tone, behavioral patterns, interaction dynamics with other characters. The snapshot guarantees a way back if the ripples spread further than expected.

Recording Depth for Different Character Types

The full six-section file suits load-bearing characters. Applying it to everyone would be overkill.

Protagonists and core supporting characters -- complete files, every section filled. These characters carry the story's weight. Any detail might become pivotal at some turning point. Time invested in documenting them pays back continuously across the entire writing process.

General supporting characters get a simplified version. Basic info, function in the story, two or three identifying features. The convenience-store grandmother's childhood trauma? Not needed. But her name, which chapters she appears in, and why she treats the protagonist with particular warmth -- those need recording. Skip them, and the later chapters risk producing "two functionally identical background characters" -- an awkward duplication.

Walk-on characters need one line: "Chapter 3 taxi driver, talkative, provides background information about the city." The point isn't future development. The point is declaring "this seat is taken." Otherwise, a near-identical character may accidentally appear three chapters later.

In the File Tree, folders create the tiers. Protagonists and key supporting characters get full individual files. General supporting characters consolidate into a single "supporting-quick-reference.md." Walk-ons go into "minor-characters.md." The folder stays manageable; the information stays searchable. Both goals met.

Quick Open (Cmd+P) makes navigation instant. Type "John" -- land on the full protagonist profile. Type "supporting" -- reach the quick-reference list. Seconds, not minutes. Checking a character detail should feel like breathing -- something that happens without noticing, not a chore that derails thought.

Martin has two full-time assistants. He still published contradictory hip descriptions.

No assistants is not the problem. The AI Assistant reads every word in the book, Version Control remembers every change, and the search function retrieves any piece of data in seconds. Tools are more reliable than people -- provided they get used.

Character consistency doesn't depend on memory. It depends on systems. Build the system, and details are always findable.

Next: timeline management -- making sure the story never trips over its own temporal logic.