How to Build a Lorebook for a Real Person Persona or Brand Voice

Lorebooks are most commonly discussed in the context of fictional world-building — locations, factions, historical events, magic systems. But the same mechanism works equally well for two very different use cases: characters based on real people, and brand voice characters representing an actual organization.

Both of these use cases have something in common that fictional characters don't: the facts have to be right. A fictional world can be expanded freely. A real person's background or a brand's product details cannot be invented — inaccurate lorebook entries produce inaccurate character responses, and for real-person or brand deployments, inaccuracy has real consequences.

This article covers how to structure lorebooks for both use cases, what belongs in entries, and what to leave out.

Why Real-Person and Brand Lorebooks Are Different

For a fictional character, lorebook entries fill in world-building that the model has no reason to know. You're inventing the content.

For a real person or brand, the content already exists. Your job is to:

1. Select what's factually accurate and relevant
2. Structure it so keyword matching surfaces it at the right moments
3. Exclude anything uncertain, disputed, or outside the character's appropriate scope

The failure mode for fictional lorebooks is usually incompleteness — entries not triggering when they should. The failure mode for real-person and brand lorebooks is inaccuracy — wrong entries triggering and producing factually incorrect responses. Accuracy discipline is the primary skill.

Part 1: Lorebooks for Real Person Personas

What Belongs in a Real Person Lorebook

A real person persona lorebook documents the factual record that the character should know and express consistently. Think of it as a briefing document the model consults when the conversation touches specific topics.

Background and biography entries. Key life events, formative experiences, career timeline — the facts a well-informed person would know about this individual. Keep entries to verifiable, public record facts.

Example entry:

• Title: Early Career
• Keywords: early career, started, first job, before, background, history
• Content: Began as a software engineer at a small startup in 2008, moved into product management after two years when the company pivoted. Founded first company in 2011 focused on enterprise data tools. Company acquired in 2014.

Known positions and views. Public statements, published positions, recorded interviews — what this person has said about topics they're known for. Frame these carefully: the entry should reflect documented views, not inferred ones.

Example entry:

• Title: Views on AI Development
• Keywords: AI, artificial intelligence, technology, future, opinion, think, believe
• Content: Has publicly stated that AI regulation should focus on high-risk applications rather than broad capability restrictions. Wrote in a 2023 essay that "the goal should be accountability for outcomes, not prior restraint on development." Skeptical of AI anthropomorphization in public discourse.

Expertise domains. Areas where this person has demonstrated expertise — where the character should be confident and specific.

Known associations. Companies they founded, organizations they advise, projects they've led — the affiliations that define their professional identity.

What to Leave Out of a Real Person Lorebook

Anything uncertain or disputed. If you're not sure whether a fact is accurate, do not put it in a lorebook entry. An enabled entry with a matching keyword will be injected and the model will express it as fact.

Private information. Real person personas should be grounded in public record. Personal life details, private opinions, unreported events — these don't belong in a lorebook regardless of whether they might be accurate.

Speculative extensions. "Based on their stated views, they probably believe X" — this reasoning belongs in the system prompt's Psychology or Behavior sections, not in a lorebook entry that will be presented as factual knowledge.

Keywords for Real Person Lorebooks

Real person lorebook keywords need to match natural conversational references to that person's topics. Think about how users will actually raise these subjects:

• For biography: career, background, history, started, before, early, young
• For expertise: the domain names themselves (machine learning, venture capital, urban planning)
• For positions and views: think about, opinion, believe, position on, stance on
• For associations: company and organization names they're known for

Avoid using the person's own name as a keyword — most conversations with the persona don't need to say their name to be relevant. The keywords should trigger on topic, not on the name.

Part 2: Lorebooks for Brand Voice Characters

A brand voice character is a different use case. Here the lorebook is not a biographical record — it is a structured knowledge base the character consults to give accurate, brand-aligned answers about products, policies, pricing, and processes.

The Core Structure: Five Entry Types

Product and service entries. One entry per major product or service. Each entry covers what it is, what it does, who it's for, and the key differentiating details. This is where the specific, accurate product knowledge lives.

Example entry:

• Title: Starter Plan
• Keywords: starter, basic plan, entry plan, cheapest, free tier, pricing, how much, cost
• Content: The Starter Plan is free for up to 3 users and includes core features: project management, basic reporting, and 5GB storage. Does not include advanced analytics, API access, or custom integrations. Upgrades to Pro at $29/user/month. Best for small teams or individuals evaluating the platform.

Policy entries. Refund policies, terms of service highlights, data handling policies, eligibility rules — anything a user might ask that requires a precise, policy-accurate answer. These entries are high-priority because a wrong answer about a policy creates real support and liability issues.

Example entry:

• Title: Refund Policy
• Keywords: refund, money back, cancel, return, unhappy, charge, billing mistake
• Content: Refunds are available within 30 days of initial purchase for annual plans. Monthly plans can be cancelled at any time but are non-refundable for the current billing period. Exceptions for billing errors: contact support within 60 days. Pro-rated refunds are not available for unused portions of annual subscriptions.

FAQ entries. The questions that actually come up in conversations — not hypothetical FAQs, but the real ones your support team receives most often. Each FAQ entry gets its own title, its own keywords, and a complete, accurate answer.

Process and how-to entries. Step-by-step processes the character will walk users through — account setup, feature activation, integration steps. These prevent the model from inventing plausible-sounding but wrong instructions.

Example entry:

• Title: Two-Factor Authentication Setup
• Keywords: two-factor, 2FA, two factor, authentication, secure account, security, enable security
• Content: Enable 2FA from Account Settings > Security > Two-Factor Authentication. Supports authenticator apps (Google Authenticator, Authy) and SMS. After enabling, backup codes are generated — store these offline. 2FA applies to all login attempts including SSO-federated accounts. Contact support if locked out and backup codes are unavailable.

Competitor and comparison entries. If users ask about competitors, the character needs a prepared, brand-appropriate response. These entries should acknowledge the question without disparaging the competitor and redirect to the brand's relevant strengths.

Example entry:

• Title: Competitor Comparison
• Keywords: competitor name, versus, vs, compared to, difference, switch from, better than, alternative
• Content: Compared to [Competitor], this platform focuses specifically on [key differentiator]. Users who've migrated typically cite [specific feature] and [specific feature] as the primary reasons. A detailed comparison is available at [comparison page URL]. Happy to explain any specific capability in more depth.

Priority Structure for Brand Lorebooks

Brand lorebooks often have many entries, and budget pressure matters more here than in fictional lorebooks because users frequently ask multi-topic questions in a single message.

Recommended priority tiering:

Set the Context Budget to 30–35% for brand characters. Brand knowledge entries tend to be longer than fictional lore entries — policies and processes require complete, accurate details. The higher budget ensures that when multiple entries trigger (user asking about pricing and policy in one message), both can be injected.

The Auto-Generate Button: Useful Starting Point, Not Final Product

The Generate Lorebook from Background button in the World Lore section of the Blueprint Editor reads the character's background fields and generates entries automatically. For a brand character, this produces a starting structure — but requires heavy editing before deployment.

What the generator gets right: entry structure, keyword selection logic, the categories it extracts.

What the generator gets wrong: specific factual details. The generator produces entries based on the character's background text. If that background text doesn't contain precise product details, pricing, and policy language, the generated entries will be approximate — and approximate is not acceptable for a brand character.

Recommended workflow:

1. Run the generator to create the entry structure and title/keyword scaffolding
2. Replace every piece of generated content with verified, accurate brand copy
3. Add policy entries manually — the generator rarely produces these
4. Verify every keyword set against how your actual users phrase these questions
5. Set priority tiers manually — the generator assigns default priority 10 to everything

The generator saves you time on structure. Accuracy is your job.

Testing a Real Person or Brand Lorebook

Before deployment, test specifically for the failure modes that matter for these use cases:

Accuracy test: Ask about every major topic covered in the lorebook. Does the character give the accurate information from the entry, or does it supplement with model-generated content that might be wrong? If it supplements, the entry content is not complete enough — expand it so the model has everything it needs within the entry.

Keyword coverage test: Ask about each topic using the phrasing real users actually use — not the phrasing you wrote keywords for. If a question about "how much does the basic plan cost" doesn't trigger the pricing entry, the keywords need to expand.

Out-of-scope test: Ask about topics not covered by the lorebook. Does the character handle these gracefully — acknowledging the gap or redirecting — or does it hallucinate plausible-sounding content? This is controlled in the Behavior section (Never Do list, Reaction Rules), not the lorebook, but the lorebook's coverage gaps create the conditions for it.

Contradiction test: Ask questions where a user might get inconsistent answers across different entry combinations. If the character says different things about the same topic depending on which entries are triggered, the entries need to be reconciled.

A brand character that gives accurate information consistently is worth more than one that sounds better but gets facts wrong. The lorebook is what makes accuracy consistent.

Open the Blueprint Editor and build your lorebook →

Stay Connected

💻 Website: Meganova Studio

🎮 Discord: Join our Discord

👽 Reddit: r/MegaNovaAI

🐦 Twitter: @meganovaai