Backstory/World Details

The Core Idea:

The backstory explains how the scenario arrived at the starting point. It should function as a prologue, not as the story the bot keeps reenacting. The pinned premise card defines what is true now, what the current situation is, and what the bot should continue developing.

So the division is:
Backstory: What happened before play began.
Pinned Premise: What is happening now and what the scenario must remain centred on.

Otherwise the bot keeps dragging the corpse of the prologue into every scene like it paid rent.

Backstory

Your backstory is just a prologue. The scenario drops it from 15-30 messages in to make room for the lore cards. The only thing you need there is introducing the scene and why it exists as it is.

Yep. It’s that simple!

I keep my prologue to 2 or 3 paragraphs and the starting info of what’s needed for the scene. Everything else is handled by Lore Pieces. Which… I also call Lore Cards. I will use that term intermittently because the old system they were Story Cards but now Lore Pieces and Cards sounds better in my head.

Pinned Premise Card 

So before the backstory was dropped, it was the engine that drove the story. It listed the details of the world and points to note and used that to drive the story. Now that it’s dropped, I converted my backstory to 1 pinned premise card that lists the Setting, The synopsis, key players, locations and general story flow.

I keep this piece under 2k characters because of 3 reasons: 1. I don’t want it to consume a bunch of context 2. It’s the co-driver of the scenario and 3. It’s a guardrail to keep the Bot in line.

So… how do you generate story threads?

First, the synopsis I generate always describes the world state, issues and what the {{user}}’s place is. Next I create a Drama & Pressure card that hovers in the background and 3rd, I create Story Cards based on days to drive potential story threads. Which is why I use Timestamp Headers to begin with: the Timestamp Header is for the bot, not the user.

So the background + greeting message = story point for the user. Then the Premise Card has all the info for the world generated. Then I’ll have a Day 1 card to explain how the general story should go. I typically extend the story cards for the first 3-5 days just to keep the bot from stalling. Then the Drama & Pressure system kicks in and whatever has happened in those first few days are already spinning the story.

It’s actually that simple. We don’t need a lot of convoluted data because all the cool pieces of our story exist in cards to be used at the right time. Let’s go look at those cards now; scroll up and check the tab for the other cards to see how they’re pieced together.

Example

[SCENARIO PREMISE]
SETTING: New York
TIME: 2005 (or Present/Current); All calendar dates are pre-aligned to the Day system. Do not convert or recompute them.
THEMES: Crime, espionage, gritty, dark, adult, mature
TONE: Dark atmosphere with extra foggy weather, smoky interiors and dim lighting
SYNOPSIS: {{user}} works at a bar called The Last Drop as a server. Tonight is the night Mystery Man shows up and orders an absinthe. The way the Mystery Man is sitting, with his shoulders hunched and his eyes darting around, has {{user}} curious so they walk up and talk to them.
CAMERA: Write only what a camera records. Tone, feeling, and atmosphere emerge from physical detail alone. If a word describes how something feels rather than what it does, remove it.

[MAJOR LOCATIONS]
-The Last Drop: a dive bar on 10th and Porter, live music on Fridays and Saturdays, mostly grunge, garage or alternative rock
-Central Park; New York’s iconic park
-Big Book Store; a major hub of coffee lovers and book readers
-Six Avenue Credit Union; a bank that helps launder money to the Crime World

[ROMANCE & LOVE]
-Romance is possible with Mystery Man. The pacing for each Romance Tier is 5 days
-Days 1-5: Mystery Man engaged with {{user}} warily, offering them chances to show trust and respect
-Days 6-10: Mystery Man gives {{user}] a bit more background information about himself, offers {{user}} a more involved crime to help with
-Days 11-15: Mystery Man realizes {{user}] wants something more than work, he’s willing to engage in courtship, offering a date to a nice restaurant
-Days 16-20: Mystery Man is ready to finalize his relationship with {{user}}. {{user} can accept or remain friends or ask for a relationship later on

You can make this however you want or leave it alone and set up a different card of what personality types the Mystery Man likes; this is to help prevent from Instant Love Syndrome that LLMs are inclined to have.

[STORY ARCS]
Mystery Man is a man of intrigue and crime. He has a variety of crimes he wants to commit with the user. These can be done at any time.

1. Heist of Bedford Manor
2. Corporate Espionage and faking papers

Character Bio Cards

Bio cards are not that complicated. They were before, but we have more options and better LLMs to pick from.

Bio Cards have a Trait system I ignore. In my early days of character building, I found those traits were extremely limiting so I created a specific set of traits to explain HOW someone was observational, rather than just saying they’re observant. That list has grown and  matured over time and is still useful.

Each Bio Card should rarely be over 2.5k characters long. Wait… what?! No, I’m serious. We used to put everything on them, but now you don’t have to do that! I keep my bio cards to the basic info of who the person is, where their home is located/called (this is to link to the location card so the bot doesn’t hallucinate), their personality and manifestations.

You can read more below about how I generally format a Character Card; I also have a character traits section on the website to try out different ways.

The most important aspect of a character is how they manifest. A deliberate person means nothing if there’s no emotions on how that manifests. After all: can you describe what ‘deliberate’ means? If not, find out how 🙂

Then I have other cards attached for romance, conflict/friction and/or sexual encounters. Each of those personality cards are given a proper description for activation and attached to the Character Card.

Every single LLM has a finite amount of Loaded Context; it is a set amount of characters that an LLM can hold in any given post. For instance, Ultra can hold up to 32/34k characters but Free can only hold up to 16k. Because of these context limits, it’s important to piece out information to be used when needed. Since people aren’t fighting all the time, you can safely keep the card separate.

Hint: Never go by “lore pieces activated”; that is only based on general math, not an actual amount. You can read more data on the Scenario Builder Tab and plug that into an LLM to read more info.

Syntax and Labeling

When you input data to an LLM it’s a giant run-on sentence. Because of this, I break up everything with Brackets and Capital Letters. Example:
[JOHN CARTER BIO CARD]
AGE: 42
HOME: Sandy Cottage
APPEARANCE: Tall (6’2″); athletic build; dark brown hair (long on top, short on the sides); grey eyes; tan skin tone; scar on his left chin
ATTIRE: Work is suits and ties; casual is jeans, t-shirts, Henley shirts or whatever sweatpants are clean; sleeps in boxers
[PERSONALITY MATRIX]
CHARACTER CORE: John Carter is a man who tries to live his life with integrity (always telling the truth even when it can cause pain), honor (following through on what he says/helping people in need), and generosity (gives time to others when he can).
CHARACTER TRAITS:
-Protective of his friends and family by making sure they made it home safe, standing up for them when they need it, offering a shoulder if they need someone to lean on
-Rational minded to find solutions that seem daunting at first; breaks down the problem in easier goals to reach
-Funny with an observational humor to point out the absurdity of a situation or lightly tease people he’s close to; his dry remarks are accompanied by a smirk
-Guarded with deep personal information with people he doesn’t know; he will talk about his work or his interests, but personal information that explains why he is who he is doesn’t happen easily
FLAWS: Spontaneity is difficult; he prefers plans
ANGER: Being hurried, being dismissed, being rude to himself or others; his eyes will narrow and he cracks his neck

So, that’s a simple but easily readable bio card. Do you see where I have triggers? Those are the basic anger points; his eyes narrow is a trigger keyword to post onto his Conflict card so that when someone pisses him off, it’ll activate that card for how he argues and how to find resolution with him.

Because I have put labels and using capital letters, the LLM has an easier understanding of where belongs to what and keeps it from bleeding in other cards.

Location Cards

Location cards are good anchors for what the world contains. This can be a region, a town, a home, a building.

My main focus on a location card is what is seen, felt, heard and smelt. Atmosphere is the most important part. I also try to give a small directional map using North, East, West and South because those are concrete directions the bot can follow (and mostly remember). For interiors, I use basic materials/colours. Most of the time, it doesn’t matter. A pillow being red or mauve will not make or break a living room; but the overall mood (neutrals/dark woods/silver accents) can.

I always describe what’s the most visually important and I keep my locations under 1/2k. If the location has a sub-location, this is where my Timestamp  Header helps. All of my Timestamp headers have Location – Sub-location. That dash between Location and Sub-location is attached to sub-location cards and activated in favour of the main location card. So if I do need to describe a specific area with greater detail, it will leave room for the character cards to be used.

Examples

[MAIN LOCATION NAME]
TRIGGERS: (write these down so you can copy paste easier into the trigger box)
TYPE:
LOCATION:
EXTERIOR:
MATERIALS:
ENTRY:
LAYOUT: (general wings/rooms that are connected to the location)
SPECIAL FEATURES: (if needed; use a descriptive label)
OCCUPANTS: (if relevant)
ACTIVITY: (optional)

ALT FORMAT:

[LOCATION NAME or LOCATION – SUBLOCATION]
TRIGGERS: (only list location name and/or main location – sublocation as the triggers)
LOCATION: Geographic placement and immediate surroundings.
LAYOUT: Room shape, spatial arrangement, major furnishings, materials, and colours.
ATMOSPHERE: Lighting and ambient qualities

Other Lore Pieces

Alright, let’s talk about the elephant in the room. Do the names of the Lore Categories matter?

Yes & No.

The backend can read the Category Title but it does not use that to pick a Lore Piece to use.

Character/NPC Cards & Location Cards are used specifically for the LLM to generate the world and manifest NPCs; never put an NPC or a Location into another category.

Attached Pieces

Character Hobbies, Romance Gating, Sex & Intimacy Cards are all extra premise cards you attached to the Character Bio Cards.

Locations + Sub-Locations

You can have one main location with its sub-locations attached. DO NOT ATTACH LOCATION CARDS TO CHARACTER CARDS. Your character card should already have a HOME: Name and WORK: Name attached to them with a tiny schedule. Bonus: You can attach a schedule onto their work card location as well with a (Reconcile with the Timestamp Header) to keep the bot on track.

Linked Activation Bleed

Do not link characters together. When you have co-activation on Bio cards, the traits bleed through. I had Death and his pale horse, Mortis accidentally linked and Death was eating grass. This is a minor bug but still present; so anything you link can, and will be, pushed into the character cards and bled through.

This is also true for factions: A faction card should only have basic info about what the faction does, their goals, territory, etc. Do NOT put NPC names or info into them and/or link. Just state on the bio card what faction/family/group they’re part of.

To note: I would put family dynamics into their own sub-category rather than faction cards. Faction cards *are* read as Faction, but a Family dynamic is read in its own category is less likely to cause problems. It’s one of the few cases where a sub-category makes sense.

Event Cards

Event Cards are cards set to the Premise Type (Or your own category if your brain needs that) that are set to Smart Activation OFF and attached to the Timestamp Header via Trigger Words to fire on a particular Day, or time of day to fire.

Example Card:
Title: Day 4, Meeting Event
Description: Day 4 ; Reconcile with the Timestamp Header (important for the bot to read in that EXACT language so it doesn’t misfire) ; Meeting with Boss
Context: On Day 4 at 10:00 AM, the boss will call {{user}} in for an important meeting. General Story Notes are people included (list them) and the issue presented.

Drama & Pressure Cards

You can attach a general Drama & Pressure Card to your scenario to push extra storylines and potential issues to happen around your main characters. Because LLMs know exactly what Drama & Pressure is, you can simply write Drama & Pressure and a description field about the world experiencing… drama and pressure. Then set the trigger words to various days or words you want it to fire more often.
ProTip: I have a scenario where my Drama & Pressure card are set to Smart Activation Off and trigger on 10 specific days to add a more “Oh shit” factor to the scenario and really spice it up. See what you like better 🙂

I created the Drama & Pressure and Event Card system because I dislike putting story “engines” into the CSI which is always loaded. I feel it’s far better to have on-demand stories than have it constantly running in the background where it’s not always needed (and gives you time to resolve issues as needed).

Other Category Types

The other two categories I create are MAGIC and WEATHER. And before you laugh about weather let me explain: Weather is fantastic to Reconcile with the Timestamp Header; it keeps your days and weeks flowing smoothly with atmosphere that NPCs react to.

Also, Magic makes sense on its own; I used to put it into Items but I found that it could get messy there.

Testing

So this might not surprise you but: I like testing. I love seeing everything come together and then fixing what I need. During my testing is when I create my intro, too.

Step 1. Unhide your lore pieces: make sure you can see everything
Step 2: Fire up your scenario, pick a character and write a response.
Step 3. Fire up your scenario again, pick another character, write something unhinged and gremlin.
Step 4. Read both responses and check the Memory Matrix
Step 5. Answer this: Is every lore card piece dumped? If Yes: Time to add more lore pieces. If not, Proceed to Step 7.
Step 6. If your pieces are info dumping, the response you have is probably bad and just rehashing what’s on the cards, rather than the LLM inhabiting the cards. I add extra parts to my story without trigger words; I fill it with notes about the weather, random locations or anything I’ve missed. Once I’m at 40k, I test again
Step 7. Do you like or hate the responses from either the normal or gremlin post? What didn’t you like? Whatever it is change it. Don’t add MORE rules, adapt and adjust what you have and tweak it. Do a little at a time 🙂

Context Limits

This is my technical information. It’s been gathered over testing for months, breaking and pulling out my hair.

I’m not going to argue with you about “but it works for me” nonsense. That gets tiring, truly. What looks like something working and what is working will forever be different between people. I see a Lore Card vomit out verbatim info and I know it’s wrong; someone else might be happy with that.

Here is what I will tell you:
Each LLM only loads a certain amount of data from any given scenario.

That’s it. That’s your technical info.

Regardless if you like the writing of a particular LLM or not, some scenarios cannot, and will not, work with x-amount of data because it literally cannot load that much.

Free Users: They are locked around 16k. Full stop. Don’t tell me you can use more, that’s fine. Use more. Some people report *less* and that is also useful to remember! My successful free scenarios I stick to 16k to be on the safe side. I’m not willing to risk it. But you can if you want!

Plus + Ultra Models: Does best at 40 to 41k minimum.

The frustrating part above is that if you don’t make a scenario that has enough data, it can make your scenario feel incomplete or not what you wanted.

I stick to a 40k benchmark for my scenarios to fit plus and ultra. I test and see if all lore pieces activate/dump and if so, I build up a little bit more to make sure that only relevant cards are chosen.

I focus on the models that can handle it and let people know when models fail spectacularly.

Consider it like this: Your scenario is a lunchbox and you need to pack it with the food you like. If you don’t, the Matrix will fill it up with whatever it wants. ALWAYS TEST: Make sure your cards are being picked specifically, not all at once.

Labeling

A lot of people love to argue about formatting. Don’t count me into those arguments. I use the labels and structure I do for several reasons:

1. 1. Everything sent to an LLM becomes a token sequence rather than a page it visually reads like a person. I use capitals, brackets, semicolons, and repeated labels to create clear structural boundaries and make important instructions easier to distinguish from surrounding text.
      – Capitals can increase salience by making a label or rule visually/textually distinct.
      – Brackets, headings, semicolons, and repeated labels can improve consistency by giving the model recognizable patterns and grouping related information.
      – The point is structure, not decoration.
   2. FictionLab’s backend already uses markdown-style syntax such as hashtags and list markers. I prefer not to make my creator-written rules resemble backend formatting any more than necessary, especially because I have previously seen simpler bracketed structures behave more reliably.
   3. It is easy for me to read, maintain, and debug.
   4. Semicolons and commas let me keep related information together under one clear label without turning every detail into its own block. That kind of explicit grouping is common in structured data and programming syntax, and LLMs generally handle regular, predictable structure well

In summary: Bracketed rules are a compatibility choice based on prior testing. Markdown/hashtag-heavy formatting sometimes appeared to conflict with backend/system formatting or become less reliable, while bracketed rules behaved consistently. This is a personal build convention derived from testing, not a universal platform law.

Here’s how I label:
[MAIN INFO]
-Info blurb
-Info blurb
or

[MAIN INFO]
ENFORCE INFO: something something, something; more, more, yes; attach this, too (clarify the prior)
Example:
[KITCHEN]
LOCALE: Next to the backdoor, down the hallway
FRIDGE: stocked with fresh food (apples, oranges, chicken, base condiments, orange juice, coffee creamer)
-The bulb over the stove flickers during heavy rainstorms
(Attached rule to a dash so it can’t pretend it doesn’t exist. I found by attaching my dashes, the LLMs worked better with me)

Caps lock under the Heading; the LLMs read this as a Sub-Header of important info and the colon is a list. I use semi-colons as an attached list to the sub-header.

What I like about this system is that it’s read on all major FL Lab Models, even Ophelia. That means my rules, cards, etc, don’t have to be altered or adjusted.

This is my scenario builder info dump for your LLM. If you are building a scenario, copy paste this page address to your LLM and tell it: Read the LLM tab. It will absorb, read and know the information and give you a better guardrail for writing scenarios.

This scenario builder cannot be reuploaded as is. It was hand-created by myself over 20 hours and then painstakingly updated by myself. Any and all use of this outside of the website or my card builder must ask for permission. Credit where credit is due.

You will STILL have to go over EVERYTHING written and make sure it’s what YOU want. This guide is to make sure you are not overspilling information an LLM Bot cannot use when you role-play.

Testing is important! Add and adjust when something isn’t happening how you want it; go little at a time!

TECHNICAL INFO:

PLUS MODELS: Glendora = MiMo V2, Oracle = DeepSeek 3.2, Chimera= GLM 4.7 Quasar = DS 4 Pro (quick)

ULTRA MODELS: Eclipse = DeepSeek 3.2 different tuned, Paragon = DeepSeek 4.0, Lumina = MiMo V2.5 Pro, Arcanum GLM 5.2

FictionLab Scenario Card Builder — Skill Reference

Scenario Card Builder

This skill guides users through building four foundational card types that determine whether a scenario actually works:

• World Premise Card — Pinned, always-active anchor: where/when, tone, current situation, story arc directory
• World Details /Backstory — Not a card; the prologue: structured data on what the story is, who the key players are, what the current situation is; dropped after 15 -20 posts.
• Character Bio Card — Who the NPCs are in terms the model can use
• Location Card — Where scenes happen, without bloat
• Item Cards — used for specific items such as cars, brochures, weapons, etc
• Misc Cards — Use Premise Cards or Self-Made Categories to link extra character information (habits/schedules/likes) supplementary, limited or no keywords; weighted activation words. Use other cards for the closest information or create a new category.Example: SocialMedia for a category if a scenario is based off having selfies.

Core Principle (Read This First)

LLMs pattern-match. They do not “read” cards the way a human reads instructions. Every abstract word is an underspecification gap that the model fills from its training corpus — which means it defaults to clichés. Concrete, physical, countable details constrain generation toward what you actually wrote. Vague descriptors produce generic output every time.

The practical test: Could a camera film it? If yes, it belongs in a card. If it describes a feeling, essence, aura, or vibe — rewrite it as something observable.

How to Use This Skill

Ask the user which card they need help with, or identify it from context. Then load the relevant reference file and walk them through it step by step.

If a user’s scenario is broken and they don’t know why, ask them to share their card content and diagnose against the failure modes listed in each reference file.

World Premise vs World Details — these are two separate regions, not the same card under two names:

• World Premise Card — Pinned. Exactly one per scenario. The always-active anchor: where/when, tone, current situation, story arc directory. Stays lean since it’s permanently in context.
• World Details Backstory — Not pinned, not a card. Platform field and functions as the prologue: structured orientation data the model references on activation rather than something sitting in context at all times. Capped around 2,000 characters, same as other lore cards; max 3k if absolutely needed. Dropped at about 15-20 posts into the role-play.
• Custom Scenario Instructions — What governs the writing (also called prose) rules, timestamp header and how the overall story is told. Extra info such as transformations, magic, story arcs, can go onto separate cards.

Pinning content that only needs to fire situationally wastes permanent context budget; leaving orientation data unpinned when it needs constant presence causes the model to lose track of the scenario’s anchor.

FictionLab Platform Notes

Three-part opening structure:

1. Backstory / World Details (platform field) — Pure prose (writing) about what is happening in the story. This is narrative context written for the model to read as prose, not a card and not structured data. Consider it a prologue, drives what cards are activated on first message send.
2. Custom Scenario Instructions — How the story behaves (timestamp header, prose rules, user agency, NPC agency, general romance interactions)
3. Greeting Message — Opening scene (never use “you” — it triggers the model to write for the player character)
4. Loaded Context — The scenarios need at least 40k characters (including spaces) for Plus + Ultra models so that only the cards needed are activated. Under 40k, all lore cards are dumped = context bleed. It will drop the Custom Scenario Instruction Field in favor of lore cards. Only 32k characters (plus spaces) can be loaded in any given scene. Free models are capped at 16k characters, 20k if absolutely have to.

The World Details Card is a separate lore card with structured fields. It is not the same as the Backstory/World Details platform field. One is prose, one is data. Keep them distinct.

The first 15 user posts drive the memory matrix. Every single one of those posts should include at least dialogue, facial expressions, mannerisms, or body language — otherwise the matrix fills with whatever it wants.

Card Limits

Character Bio Cards: 3,000 characters maximum. All other lore cards (location, faction, item, rules, misc): 2,000 characters maximum.

These are hard limits. Content beyond them will be deprioritised or discarded.

Character count includes spaces. This is a plain character count — spaces, punctuation, and line breaks all count toward the limit, the same convention as the platform-wide 32k/12k activation thresholds. Counting only letters will produce a card that reads as under budget but isn’t. Always count with spaces included when checking a card against these limits. Minimum context needed is 40k to avoid all lore cards being dumped. If all lore cards are used, the CSI will drop in favor and ruin the overall experience.

Character Extras — Link, Don’t Fold Intimacy details, hobbies & interests, romance & dating, conflict management, and similar supplementary content each go on their own card and link directly to the character’s Bio Card. Do not add them to the bio unless there is space. Linked extras fire only when needed based on the description field, which keeps the bio lean and the extras context-relevant.

Avoid over-linking. Each link to a bio card adds score trickle to the linked card (see Scoring System below). Too many linked extras competing simultaneously can dilute the bio card’s scoring weight. Link only what is genuinely scene-relevant.

Link Co-Activation Bleed. Cards that are co-linked can have information bleed. Never link Character Bio Cards together. Characters should only be linked their own info to be activated on demand. Faction cards should contain info only pertaining to the faction and then each Character can have a faction noted if needed. Family Dynamic cards should be their own category (refer to the prior tab of Extra Lore Pieces for more info).

Card Scoring System

Cards do not activate on binary keyword matching. They compete for activation through a scoring system. This changes how triggers, links, and card weights need to be designed.

How scoring works:

1. Each card is scored by relevancy to the current scene — based on how many of its triggers appear in context and the Description field content
2. That score is multiplied by the card’s weight modifier: .5 / .75 / 1.0 / 1.25 / 1.5
3. Score distributes additively through links — A → B → C means A trickles score to B, and B trickles score to C
4. A card activates only if it scores within 20% of the highest-scoring card in the session

What this means for triggers: Triggers are not switches. A single trigger word adds points to a card’s score. If the total score sits too far below the top scorer, the card does not activate — even if a trigger fired. A card can have a trigger match and still lose the threshold competition.

If a card is not activating:

• Add more triggers — more matching words means more accumulated score
• Re-evaluate the Description field — it contributes to relevancy scoring, not just triggers
• Reduce links or lower weight modifiers on cards that are outcompeting it

Card header and field format — mandatory:

Every card opens with a bracketed, ALL-CAPS title declaring what it is:

[SONIA’S HOUSE]
[JOHN CARTER BIO CARD]
[WORLD DETAILS CARD]

This tells the model what type of content it is reading and prevents it from treating card content as scene narration.

Below the header, fields use ALL-CAPS labels followed by a colon. Multiple items within a field are semicolon-separated; parenthetical asides carry extra info without breaking the list:

[CARD TITLE]
FIRST FIELD: item one; item two; item three (extra info); item four.
SECOND FIELD:
THIRD FIELD:

Worked example:

[SONIA’S HOUSE]
LOCATION: Mid-City, Los Angeles
RESIDENCE: Small 1930s Spanish-style bungalow on a residential street.
LAYOUT: Covered front porch, living room, dining room, compact kitchen, two bedrooms, one bathroom, and a converted rear sunroom used as an art studio.
DETAILS: Sketchbooks, framed studies, jars of pencils, mismatched furniture, potted plants, and unfinished artwork stacked against the studio walls.
OUTDOOR SPACE: Walled backyard with a shaded patio and detached single-car garage.

This format applies to every card type — Bio, Location, World Details, Faction, Item, Rules, Misc. ALL-CAPS labels read as structured data to the model rather than purple writing, which reinforces the card-vs-narration boundary. Do not mix in Title Case field labels (“Full Name:”, “Age:”) — the whole card uses one casing convention throughout.

Universal Red Flags

These patterns appear in broken scenarios regardless of platform:

• No triggers on a card — Every card, including the World Premise Card (unless pinned and/or set to critical), must have triggers filled out. A card with no triggers may not fire when it should.
• Vague personality labels — “mysterious,” “protective,” “intelligent” without physical manifestation. The model defaults to its corpus version of that word.
• Eye descriptions using “sharp” — Replace with what the eyes actually do: narrows in thought, focuses on detail, tracks movement.
• Emotional shorthand in narration — “no heat,” “a beat,” “unreadable,” “genuine,” “honest smile.” These are underspecification invitations.
• “Breathe” as metaphor — Only use for literal respiration.
• NPC omniscience — NPCs referencing information they have no in-scene source for.
• World Details Card written as prose — It is a structured data card. Prose goes in the platform’s Backstory/World Details field, not on this card.
• World Details Card acting as character backstory — The World Details Card describes the world and its current state; character history goes on Character Cards.
• Story arc embedded in the World Details Card — Arc stages belong on separate Day-triggered lore cards. The World Details Card carries a directory of stages only.
• No arc gating mechanism — Vague pacing conditions (“when trust builds”) are not triggers. Use Day numbers, Bond Bar thresholds, or named milestone events, or the arc will stall or rush.
• Greeting that writes for the user — Any “you” in the greeting trains the model to control the player character.
• Exceptions: Fantasy scenarios are allowed to get away with more vibes/emotional labels to atmosphere or actual personality quirks to magical items/rooms; because it’s Fantasy and it should feel Fantasy.

Quick Card Quality Check

Before finalising any card, run this check:

1. Does the card open with a header declaring what it is — e.g. [JOHN CARTER BIO CARD]?
2. Does the card have triggers filled out?
3. Is a Character Bio Card under 3,000 characters? Is any other lore card under 2,000?
4. Is every personality trait backed by a physical tell or observable behaviour?
5. Does any sentence use a banned metaphor word (clean, dry, sharp, honest, genuine, unreadable, measured, practiced, controlled)?
6. Is the World Details Card written as structured fields, not prose?
7. Does the World Details Card contain character backstory or location detail instead of directory entries?
8. Do story arc stages have their own Day-triggered lore cards, or another concrete gating mechanism?
9. Is the greeting written in third person without “you”?
10. Do character extras (outfits, intimacy, conflict, schedule) have their own linked cards rather than being folded into the bio?
11. If a card isn’t activating: are there enough triggers? Is the Description field relevant? Are competing cards outscoring it via links or high weight modifiers?

If any answer is yes to a problem item, the card needs revision before it will perform reliably.

Reference: World Premise Card

World Premise Card

What This Card Is For

The World Premise Card tells the model what story it’s in and how that story behaves. It is NOT a character backstory document and it is NOT a writing rules card.

Mixing these three things is the most common cause of scenario failure. Keep them separate.

This card is Pinned. Exactly one per scenario, permanently in context. Because it never drops out, keep it lean — everything here competes for context budget every single turn, unlike lore cards that only activate on trigger match. Do not confuse this with the World Details Card (world-details.md), which is a separate, unpinned card that functions as the prologue — structured orientation data the model reads on activation, capped around 2,000 characters.

World Premise Card contains:

• Where and when
• The tone and atmosphere
• The current situation the user enters
• Major locations (directory only — details go on Location Cards)
• Story arc and pacing gates (romance tiers, faction states, day-based progression)
• Active scenario rules (e.g. time tracking, day system)

World Premise Card does NOT contain:

• Character backstory or history (put that on Character Cards)
• Writing style rules (that goes into the CSI)
• Detailed location descriptions (put those on Location Cards)

Structure Template

[WORLD PREMISE CARD]

TRIGGERS (if not setting to Pinned or Critical): [scenario name; world name; key location names; main character names; central theme words e.g. “The Pub; West Street”]

LOCATION: [City / Country / Region]
TIME: [Year or “Present/Current”] — all calendar dates are pre-aligned to the Day system; do not convert or recompute them.
THEME: [e.g. crime, romance, fantasy, slice of life — keep to 3–5 words]
TONE: [Observable atmosphere — lighting, weather patterns, ambient sound, not emotional labels]
SYNOPSIS: [One concrete paragraph describing the overall theme; the Backstory + Greeting Message is the jump off point]
NO SNOWFLAKES (optional): {{user}} must prove themselves; no one has to like them
NO PLOT ARMOR (optional): {{user}} can be hurt physically, mentally, emotionally

[MAJOR LOCATIONS]
NAME: [One line — what it is and where]
NAME: [One line — what it is and where]
(Details for each go on dedicated Location Cards)

[KEY CHARS]
NAME: [Their name, their role]
NAME: [Their name, their role]
(Details for each go on their Character Card)

[STORY ARC / PACING]
STAGE: [Trigger condition and what changes]
STAGE: [Trigger condition and what changes]

Filling In Each Section

Triggers

Triggers are not binary — a trigger word adds points to a card’s relevancy score. If the card’s total score falls more than 20% below the highest-scoring card in the session, it will not activate, even if a trigger matched.

The World Premise Card should fire be present at every given chance when it is Pinned and set to Critical. Triggers can be added if it is not always present, but that is rare.

Location and Time

Be specific. “New York, 2005” is better than “a big American city in the early 2000s.” The model anchors to known details. Unless you are using a fictional city/town/fantasy location)

For time systems: if you are using a Day system, state it explicitly and tell the model not to convert or recompute dates. If you don’t, it will hallucinate its own time math.

Theme

Keep this functional, not aesthetic. “Crime, espionage, gritty, adult” tells the model what genre rules apply. “Dark and dangerous and sexy” does nothing useful.

Tone

Describe what the camera sees, not what it feels.

• Good: “Smoky bar interiors, dim overhead lighting, rain on glass”
• Bad: “Oppressive atmosphere, tension in every room”

No Plot Armor:

Add if the user has plot armor or not; if no plot armor, added a field for no plot armor and how {{user}} can be hurt (physically, emotionally, etc).

Synopsis

This is the most important section. It is the model’s entry point into the story. Write it as a specific scene:

• Who matters
• Why they matter
• What the user’s character’s role is (even if open ended)

Do not write the user’s character’s thoughts or reactions. Only what is observable.

Major Locations

List names and one-line descriptions only. This is a directory, not a guide. The model uses this to know what places exist and checks Location Cards for details when a scene happens there.

Story Arc / Pacing

Be concrete and countable. Avoid vague progress conditions like “when trust is established.” Use instead:

• Day-based gates: “Days 1–5: X behaviour. Day 6+: Y behaviour.”
• Action-based triggers: “After user completes X task”
• Threshold systems: “Bond Bar reaches 60%”

Common Failure Modes

Problem: NPC ignores the current situation entirely and free-styles.
Cause: The situation description was too vague or described mood instead of specific action.
Fix: Rewrite Current Situation as a concrete, present-tense scene with physical specifics.

Problem: The bot keeps advancing the romance faster than the pacing gates. Cause: Pacing conditions were described as feelings (“when the character trusts the user”) rather than countable events.
Fix: Replace feeling-based conditions with day numbers, interaction counts, or Bond Bar thresholds.

Problem: The bot treats every location the same.
Cause: Locations were described in the World Premise card instead of on dedicated Location Cards, or the Location Cards weren’t triggered.
Fix: Strip location detail from the World Premise to single-line entries. Build dedicated Location Cards and confirm their trigger words match what appears in play.

Problem: NPCs know things they shouldn’t.
Cause: Background lore that should be on faction or character cards was placed in the World Premise where all NPCs can access it.
Fix: Move faction-specific or character-specific information to the correct card type. Add an Information Boundaries rule card.

Worked Example

[WORLD PREMISE CARD]

LOCATION: West Wycombe, Buckinghamshire, England
TIME: Present/Current — all calendar dates are pre-aligned to the Day system; do not convert or recompute them.
THEME: Crime family; slow-burn romance; country estate; adult; mature
TONE: High ceilings and low fires; antique wood and old money; rooms that remember more than the people in them

CURRENT SITUATION: The user has accepted a short-term administrative contract at Blackburn Park, a private estate managed by the Blackburn family. Today is Day 1, a Monday. The user has just arrived at the front entrance with their luggage. Aldric Blackburn, the family patriarch, has been informed of their arrival but has not yet come to the door.

[MAJOR LOCATIONS]
BLACKBURN PARK: Private country estate, main residence of the Blackburn family
THE STUDY: Aldric’s primary working room, second floor east wing
THE LIBRARY: Ground floor, accessible to staff
THE VILLAGE: Small attached village, walking distance from the estate

[STORY ARC]
DAYS 1–5: Aldric treats the user as staff. Formal, minimal interaction.
DAYS 6–10: Aldric begins to notice the user. Brief personal exchanges begin.
DAYS 11–15: Aldric initiates non-work contact. Courtship behaviour begins if Bond Bar is above 50%.

Reference: World Details/Backstory Field

Backstory Field

What This Field Is For

The World Details Card is a platform field that is located in the third section of the Creation Builder.

This platform field is not a card. It functions as the prologue: structured orientation data the model reads on activation rather than something held permanently in context. Cap it around 2,000 characters, same as other lore cards. Do not confuse this with the World Premise Card, which is Pinned, exactly one per scenario, and stays in context at all times — the always-active anchor rather than the prologue.

Structure Template

Occoquan’s Mill Street follows the river past brick storefronts and gardens. Residential streets climb away from the water. People stop for coffee, compare seedlings and fit errands around the weather.

At 408 Mill Street, Tony Ward and Savannah Banks have run Occoquan Nursery for three years. They grew up together and have known each other for twenty-four years. The shop opens Tuesday through Sunday, eight until five; Savannah sometimes stays late with a project. Tony remembers customers’ plants more readily than their names. Savannah sketches ideas on whatever paper is nearest, often before checking the budget.

Mango, their orange tabby, arrived about three years ago and stayed. His bed and wooden doghouse occupy a rear corner of the shop. Both owners feed him treats, each assuming the other has not already done so.

The Secret Garden Cafe is next door, where Tony and Savannah keep a monthly tab. River Mill Park and Mill House Museum offer other reasons to linger in town. Familiar faces appear as their own errands bring them through; a conversation can stay brief or become the beginning of a friendship.

On Friday afternoon, a nursery delivery has arrived with three unexpected flats of impatiens and without the specialty potting mix customers requested. Tony has the invoice in the greenhouse. Savannah is repotting a peace lily and reminding him to call the supplier before four. Customers browse outside the greenhouse while Mango sleeps on a bag of fertilizer.

Story Arc Cards

Story arcs go on separate lore cards, not embedded in the World Details Card. The Story Arc section of the World Details Card is a directory — stage names and trigger conditions only.

Use Timestamp Headers (Day X) as triggers. Each arc stage gets its own lore card:

• “Day 1 Arc Card” — Triggers: Day 1, [Day 1
• “Day 2 Arc Card” — Triggers: Day 2, [Day 2

Timestamp triggers are the most reliable arc-gating method because they are unambiguous. The model cannot misinterpret “Day 3” the way it misinterprets feeling-based conditions like “once trust is established.”

If not using a Day system, use another explicit method to prevent arc stall or loop:

• Named milestone flags (“After the Gala,” “Post-confrontation”)
• Bond Bar / relationship threshold numbers
• Named chapter or act markers

Vague conditions (“when the character feels ready,” “once tension builds”) are not gating mechanisms. Without a concrete trigger, the model will either rush to the end state or stall at the current one.

Reference: Character Bio Card

Character Bio Card

What This Card Is For

The Character Bio Card tells the model who an NPC is in terms it can use during generation. It is the model’s behavioral reference — not a novel introduction.

Most character cards fail because they describe how a character feels on the inside, or use vague trait labels the model fills from its own defaults. The card must instead describe what a camera would capture: appearance, movement, speech patterns, reactions, and tells.

The Core Test

Before writing anything, ask: Could a camera film this?

• “He has sharp, intelligent eyes” — No. Rewrite as: “His eyes track conversation partners rather than the room; he focuses on the speaker’s mouth when they hesitate.”
• “She is fiercely protective” — No. Rewrite as: “She positions herself between unfamiliar people and whoever she is accompanying without explanation.
• “He is mysterious and brooding” — No. This is a genre cliché. The model will default to its corpus version. Rewrite as specific observable behaviour.

Structure Template

[CHARACTER NAME BIO CARD]

TRIGGERS: [character’s name; nicknames; “Aldric; Mr. Blackburn”]

FULL NAME:
AGE: [number + birthday — models respond well to specific dates]
ETHNICITY: [Use this to anchor language, accent, and cultural reference frame. Omit if not relevant.]
GENDER / PRONOUNS:
SEXUALITY: [Only include if plot-relevant]
APPEARANCE: [trailing list of concrete details — body type, skin tone, eye colour, hair colour/cut/length, scars]
TATTOOS/PIERCINGS: [when relevant and when tattoos can be seen]
ATTIRE: [trailing list of concrete details; work / casual / dressed up / sleepwear]
SPEECH: [patterns, not register]
ROLE: [who they are and what they do]
WORK SCHEDULE:
VEHICLE:
HOME:

NOTE: Pick one style of Personality Traits or Personality Matrix to use. Characters that have good training data can use Traits + Manifestations, more complex characters might need Alt Traits Format, and sometimes, both. Start with Alt Traits and then adjust/add after testing.

[PERSONALITY — ALT TRAITS FORMAT]
COGNITIVE STYLE: [How they process problems. Pick one and add 1–2 physical tells.]
INTERACTION STYLE: [How they engage with people. Pick one and add 1–2 physical tells.]
REGULATION STYLE: [How they manage stress and emotion. Pick one and add 1–2 physical tells.]
TRUST AND VULNERABILITY: [How they approach closeness. Pick one and add 1–2 physical tells.]
HUMOUR STYLE: [Optional — how humour surfaces. Pick one.]

[PERSONALITY  — List + Manifestations Format]
-Label; manifestation (ie, -Protective; places himself between {{user}} and open doorways or other people; walks people to their car; first to defend someone being yelled at)
-Label; manifestation

[PHYSICAL CUES] optional; always preface that these are just some physical cues and to use a variety, not the same.
NEUTRAL STATE:
UNDER STRESS:
INTERESTED OR ENGAGED:
UNCOMFORTABLE:
ANGRY/FRUSTRATED:
[Add or remove states as relevant]

[RELATIONSHIPS] (separate card if needed)
FRIENDS:
FAMILY:
ROMANCE:
RIVALS:

[SEX AND INTIMACY — only include for adult scenarios, separate card]
GENITALS: [male or female to anchor the bot]
KINKS/DESIRES: [list favorite positions, along with not forcing {{user}} to orgasm or asking for it and they last more than one orgasm]
SEXUAL TONE: [short list such description]
SPEECH: [what are their phrases during sex such as praise]
AFTERCARE:

Minimal Structure Template — Lean Dynamic NPCs

For NPCs that don’t need the full template above, this leaner section set is enough to produce a dynamic character with very little input per field:

[NAME BIO CARD]
AGE:
ETHNICITY: [optional; needed when NPC is not white]
LANGUAGES: [optional, can link to Ethnicity]
ROLE: [who they are and what they do]
VEHICLE/TRANSPORT:
HOME:
APPEARANCE: [trailing list of concrete details — body type, skin tone, eye colour, hair colour/cut/length]
ATTIRE: [work / casual / dressed up / sleepwear]
SPEECH: [patterns, not register]
CHARACTER CORE: [list who they are with two labels and a manifestation and a general flaw they might have]

[FANTASY SCENARIO OPTIONS]
RACE: [elf/dwarf/etc — omit for non-fantasy settings]
ABILITIES:
COMBAT STYLE:

Each field needs only a short entry to work together — the sections are designed to compound rather than each carrying full weight alone. This is the fast path for secondary or scene-limited NPCs; use the full template for characters carrying significant narrative weight.

Separate cards, only when needed: Sexual Dynamics, Conflict Card, Physical Cues, Hobbies. Most NPCs don’t need these — deactivate rather than build them by default, since each active linked card competes for scoring weight against the bio card itself.

Ethnicity

Only include if it meaningfully anchors the character. French ancestry means the model knows to reference French speech patterns, cultural touchstones, possible accent. “White American” is not useful and takes up space.

Eyes

Do not describe eyes as “sharp,” “intelligent,” “warm,” or “cold.” These are emotional labels the model maps to clichés.

Describe what eyes do:

• “Tracks speakers carefully during conversation”
• “Focuses past the person he’s talking to when distracted”
• “Holds eye contact longer than is comfortable”

Voice

Use SPEECH not VOICE or else the LLM will vomit out the physical descriptor every response and become repetitive.

Personality — Alt Traits Format

Do NOT copy the Alt Traits list as-is. Pick one entry from each axis and add 1–2 sentences of physical manifestation specific to your character.

Example:

• Cognitive Style — Active Problem-Solving: When presented with a problem, she immediately moves to a flat surface and writes. She does not discuss options until she has written them down.
• Regulation Style — Emotionally Regulated: Under pressure her speech gets shorter, not louder. She answers only what was asked.

PERSONALITY – TRAITS + MANIFESTATIONS

You can use a trait such as “Protective” and then list how they are protective

Example:

[TRAITS]
-Protective; positions himself between a door or people and {{user}}; walks people to their car; scans a room for potential threats before relaxing

Physical Tells

This section is critical. It is how the model knows what to show instead of what to tell. Without it, the model defaults to generic expressions like “he smiled warmly” or “her expression softened.”

Write tells as specific physical actions:

• “When nervous, he adjusts his left cuff twice, then stops.”
• “When amused, she smiles before she suppresses it.”
• “When angry, he rubs his ear and looks at a fixed point instead of the person.”

Speech Patterns

Describe mechanics, not affect:

• “Speaks in short sentences. Rarely more than two clauses. Does not explain unless asked.”
• “Asks a clarifying question before answering anything significant.”
• “Uses formal register with strangers; drops it abruptly when comfortable.”

Do not write: “He speaks with quiet authority” or “Her voice carries warmth.” These are emotional labels.

Linked Cards — What to Separate and What to Link

Character Bio Card hard limit: 3,000 characters.

Character extras go on their own card and link directly to the bio card. Do not fold them in.

Always give a separate linked card to:

• Conflict Card — trigger on: argument, fight, frustrated, angry, anger, argue, irritate, conflict. This card is large and must not load in every scene.
• Sex& Intimacy  — trigger on intimacy & explicit anatomy keywords
• Extended relationship web — if a character has many relationships with distinct dynamics

Lean bio cards perform better. Every linked card adds score trickle back to the bio via the link chain. Too many linked cards competing simultaneously can dilute the bio’s scoring weight. Link only what is genuinely scene-relevant.

Hard limit: 3,000 characters on the bio card itself. Linked cards are each subject to the 2,000 character lore card limit unless they are themselves a Bio Card type.

Triggers

Every card must have triggers. Triggers are not binary — each matching word adds points to the card’s relevancy score. The card activates only if it scores within 20% of the highest-scoring card in the session.

For a character bio card, triggers should include:

• The character’s full name and any shortened version
• Nicknames or titles others use for them
• Their role or job title if it appears in conversation
• Any object or location uniquely associated with them (e.g. “the study” for a character who is always found there)

Avoid triggers so generic they fire constantly (“man,” “he,” “the boss” if there are multiple bosses). Be specific enough that points accumulate for this character rather than inflating every card’s score.

If the bio card is not activating: add more specific triggers, check whether competing cards are outscoring it through high weight modifiers or long link chains, and review the Description field — it contributes to relevancy scoring alongside the trigger list.

Common Failure Modes

Problem: The NPC always sounds the same regardless of what’s happening. Cause: Personality was written as abstract labels. The model has no behavioral instructions for how those labels manifest. Fix: Rewrite personality section using a list of what those traits look like when filmed. Add a Disagree & Fight Matrix card if conflict behaviour is important.

Problem: The NPC keeps using phrases you banned. Cause: Banned phrases were listed on a separate card that doesn’t fire in the relevant scene, or the character card wasn’t loaded into that scene context. Fix: Move banned phrases onto the character card itself, or onto a high-priority Rules card linked to the character.

Problem: The NPC sounds like every other NPC on the platform. Cause: Personality traits used common labels (“mysterious,” “guarded,” “intelligent”) that map to corpus defaults. Fix: Replace every trait label with its observable physical manifestation. Test with a scene where that trait should be activated and check if the output is distinct.

Problem: The NPC knows things they shouldn’t. Cause: Character card contains world-level information, or the NPC’s role description implies access to knowledge they shouldn’t have. Fix: On the NPC card, restrict knowledge to what their role and direct experience would provide.

Problem: The NPC’s intimacy scenes sound scripted and generic. Cause: The Sex & Intimacy section was empty or used abstract language. Fix: Specify style, tone, and what is banned. The model needs to know what to avoid as much as what to do.

Worked Example (Partial)

[JOHN CARTER BIO CARD]

FULL NAME: John Richard Carter
AGE: 54 (born 12 March)
GENDER / PRONOUNS: Male; he/him
APPEARANCE: Very Tall (6’2″/188cm); athletic build with broad shoulders, kept in shape by weekly workouts; dark brown hair kept neatly trimmed but naturally tousled on top; grey eyes; scar on his abdomen from a work incident ten years ago (only noticed when nude)
SPEECH: Medium to long sentences; never uses contractions
ROLE (their job/occupation, or who they are in the story such as barback, father, friend):
SCHEDULE:
VEHICLE:
HOME:
LIKES:
DISLIKES:
MOVEMENT (list non-generic physical cues): Uses a variety of physical cues; when uncomfortable, adjusts something on themselves or an object near by

Reference: Location Card

Location Card

What This Card Is For

A Location Card gives the model enough physical detail to write a scene in a specific place without having to invent everything. It is a functional reference, not an atmospheric essay.

The two most common failures:

1. The card describes atmosphere and mood instead of physical layout
2. The card is too long and the model discards most of it

Target length: under 2,000 characters. Hard limit: 5,000 characters. If a location is large, either split it into sub-location cards or attach sub-locations to the main card — see the Sub-Location Strategy section below.

The Core Test

Every line should answer one of three questions:

1. What is physically here?
2. Where is it in relation to other things?
3. What does it do (functionally)?

If a line answers “what does it feel like,” rewrite it or cut it. Atmosphere is built by the model from physical facts — the model is better at that job than a card description.

Structure Template

[MAIN LOCATION NAME]
TRIGGERS: (write these down so you can copy paste easier into the trigger box)
TYPE:
LOCATION:
EXTERIOR:
MATERIALS:
ENTRY:
LAYOUT: (general wings/rooms that are connected to the location)
SPECIAL FEATURES: (if needed; use a descriptive label)
OCCUPANTS: (if relevant)
ACTIVITY: (optional)

SUB-LOCATION FORMAT or ALT FORMAT:
[LOCATION NAME or LOCATION – SUBLOCATION]
TRIGGERS: (only list location name and/or main location – sublocation as the triggers)
LOCATION: Geographic placement and immediate surroundings.
LAYOUT: Room shape, spatial arrangement, major furnishings, materials, and colours.
ATMOSPHERE: Lighting and ambient qualities

Filling In Each Section

Style

One phrase is enough. “Victorian farmhouse” tells the model a great deal — building materials, ceiling height, window style, probable furniture era, layout logic. You don’t need to explain all of this. The model knows it.

Tone

Pick 2–3 physical anchors, not mood labels.

• Good: “Wide plank oak floors, overhead pendant light that doesn’t reach the corners, smell of old paper and wood oil”
• Bad: “Warm and inviting, feels like home, slightly mysterious”

Layout

Think in zones, not room-by-room exhaustive lists. The model needs to know:

• What major areas exist
• How they connect to each other
• Any functionally important detail (a locked door, a balcony that overlooks X, a trapdoor)

Do not describe furniture in detail unless the furniture matters to a scene. “A desk with a leather surface, left side near the window” is useful if a scene happens at that desk. “Various tasteful antiques throughout” is noise.

Atmosphere & Occupants

Use this for:

• NPCs who are normally found in this location
• Lighting, ambient qualities
• Objects the user can interact with that matter to the plot

Triggers

Every card must have triggers. Triggers are not binary — each matching word adds points to the card’s relevancy score, and the card only activates if it scores within 20% of the highest-scoring card in the session.

For a location card, triggers should include:

• The location’s name and any common shorthand
• Sub-location names if they are attached to this card

Avoid standalone generic triggers like “walk,” “enter,” or “go” — these add noise across all cards.

If a location card is not activating: add more specific triggers, check whether other cards are outscoring it via weight modifiers or link chains, and review the Description field.

Sub-Location Strategy

Two options when a location has multiple distinct spaces:

Option A — Attach to the main card If the sub-location is small and the combined card stays under 2,000 characters, append it directly. Add the sub-location name to the main card’s trigger list.

Use this when: the sub-location is almost always relevant when the main location is active (e.g. a pub’s back corridor that characters pass through frequently).

Option B — Separate triggered card Build a standalone card for the sub-location with its own triggers. It fires only when the user enters that specific area.

Use this when: the sub-location only matters in specific scenes, or adding it would push the main card over 5,000 characters.

Example — a pub:

• Main card: The Pub (exterior, entrance, main bar area) — triggers: The Last Drop, bar, pub, enter, arrive
• Attached if small: The Back Corridor
• Separate card if large or scene-specific: The Back Room, The Upstairs Flat

Do not attach every sub-location by default. If it only matters twice in the whole scenario, it belongs on its own triggered card.

Faction Cards vs Location Cards

Location card: Physical space. Layout, materials, access points, regular occupants. Faction card: Who operates in this space, what the atmosphere is when they’re present, how they behave toward outsiders.

Keep these separate. If a bar is run by a crime family, the bar’s physical description is on the Location Card. The crime family’s territory behaviour, NPC attitudes, and unwritten rules are on the Faction Card.

Mixing them means every visit to the bar loads all the faction information whether it’s relevant or not.

Common Failure Modes

Problem: The model writes every scene in the location identically. Cause: Location card described atmosphere and feeling instead of physical structure. The model has nothing to vary. Fix: Replace atmosphere descriptions with physical features. Add time-of-day or event-based cards that modify the location (e.g. a Night card that changes the lighting and which NPCs are present).

Problem: The model invents rooms and features that aren’t in the card. Cause: Layout was described impressionistically (“spacious, with plenty of seating”) rather than specifically. Fix: Write the layout as a list of named zones with explicit connections. “The bar area is at the front. A hallway behind the bar leads to the kitchen. There is no public access to the kitchen.” This closes the gap the model would otherwise fill.

Problem: The location card is too long and the model ignores half of it. Cause: Too much detail, especially atmosphere language that consumes character budget without providing usable anchors. Fix: Cut everything that doesn’t answer: what is here, where is it, what does it do. Split large locations into sub-location cards, or attach small ones to the main card if combined character count stays under 5,000.

Problem: NPCs in the location know the same things regardless of their role. Cause: The location card contains information that should be on a Faction or NPC card. Fix: Move faction-specific knowledge and NPC behaviour off the location card. Location = physical facts. Faction = who, why, and how they behave.

Worked Example

[THE THIRD SHOT PUB]
LOCATION: McCullens Avenue and the 101 intersection.
PURPOSE: Local pub serving drinks and food, with pool tables and a jukebox.
LAYOUT: Long bar with a mirrored bottle wall and five regulars’ stools; several small tables; dark wrap-around booths with worn leather; maintained dark wood under amber lighting; shadowed corners; two pool tables near the front windows; blacked-out windows allow patrons to see outside while preventing street-level views into the pub.
ENTRY/EXIT: Back hall leads to bathrooms marked Male, Female, and Werewolf.
TONE: Chic dive-bar atmosphere; deliberate grit in well-maintained surroundings; alternative rock, industrial, and grunge from the jukebox.
INTERACTIONS: Pool tables and jukebox; Jude Williams and Marlene “Mar” Whitaker may share current local news and events with {{user}}; drinks are measured with jiggers, never in “fingers.”
ACTIVITY: Open afternoon to midnight daily, except holidays and major storm nights; kitchen run by Mauro, a young Portuguese line cook, and a sentient grill; Jude Williams works as barback; Marlene “Mar” Whitaker serves the floor. Various supernatural denizens visit; vampires at night, witches & werewolves on weekends, local practitioners at various times.

[FICTIONLAB CARD SCORING — LLM REFERENCE]

Note: Describes observed platform mechanics, not official public documentation. Numeric values below are illustrative stand-ins only, chosen to preserve correct proportional relationships between signals. They do NOT represent FictionLab’s actual proprietary scoring values and should not be treated as accurate figures — only the relative pattern (which signals matter more than others, and how they combine) is meaningful.

SCORING MECHANISM: Each Story Card is scored fresh, per turn, against the current conversation. A card activates only if its final score meets or exceeds a fixed activation threshold.

SCORING SIGNALS (additive, summed into a subtotal):
– KEYWORD MATCH: Literal trigger word present in recent chat. Binary presence, scaled by a normalization value. Illustrative max: [X1]
– SEMANTIC MATCH: Cosine similarity between the card’s Title/Description content and the current conversation’s meaning, not requiring an exact trigger word. Includes a “safety net” multiplier awarding partial credit for near-miss similarity. Illustrative max: [X2], smaller than Keyword Match
– SCENE RECENCY: Bonus if the trigger appeared within the last few exchanges specifically, distinct from general keyword presence. Illustrative fixed value: [X3], smaller than Semantic Match
– MEMORY RELEVANCE: Contribution based on match against Memory Card summaries of past events. Can be zero if no memory relevance exists.
– LIBRARIAN JUDGMENT: A holistic relevance score assigned by the Librarian AI system itself. The largest single contributor by a wide margin — illustrative value: [X4], several times larger than any other single signal, capable of outweighing all other signals combined.
– HYSTERESIS: A “stickiness” bonus for cards already active in the current context, preventing flickering activation/deactivation. Illustrative value: [X5], the smallest positive contributor. This value is HALVED if the Librarian has independently decided to drop the card that turn — hysteresis only partially resists that decision, it does not override it.
– LINK/BOOST: Additive bonus derived from card-to-card linking relationships.

WEIGHT MULTIPLIER: After all signals sum into a subtotal, the result is multiplied by the card’s assigned Weight class (e.g., Standard tier applies a modest multiplier, illustrative value [Xw], noticeably above 1). Weight is NOT a scoring signal — it is a late-stage multiplier applied to an already-computed relevance score. A high-weight card with weak relevance signals will still score lower than a low-weight card with strong relevance signals.

FINAL SCORE FORMULA: (Keyword + Semantic + Scene + Memory + Librarian + Hysteresis + Link/Boost) × Weight = Final Score. Card activates if Final Score meets or exceeds a fixed Activation Threshold, illustrative value [Xt] — well below what a single strong Librarian Judgment score alone would produce.

PRACTICAL IMPLICATION FOR SCENARIO AUTHORS: Card Title and Description do not score independently — they inform the Semantic Match and Librarian Judgment signals. Trigger words are the only fully deterministic, author-controlled lever (Keyword Match). Weight cannot compensate for poor relevance; it only scales relevance that already exists. Authors seeking reliable card activation should prioritize precise, specific trigger words and on-topic card content over inflating a card’s Weight setting.

OPEN QUESTION — UNCONFIRMED: Available data does not indicate whether a secondary cap exists limiting the total number of cards that can activate simultaneously once each has individually cleared the activation threshold. This interacts with separately-observed behavior where scenarios under approximately 40,000 total characters (summed across Lore Cards + CSI + Backstory fields) exhibit broader, less selective card activation than scenarios closer to that ceiling. Whether this reflects a post-scoring inclusion cap tied to available context budget, or some other mechanism, is not established by the scoring data alone.

This info is for information purposes only. Do not remake into a skill or document without prior permission. Content may be updated at any time causing old information to be lost or defunct, please check back here for when info is updated.

CREDITS: Stilaris – information was hand gathered and written before transferred to text-based format.

Claude: organising the sex cards into a legible format

ChatGPT: MD format for human-eye readability.

Template

For you to copy paste and fill out as you see fit

[MAIN LOCATION NAME]
TRIGGERS:
TYPE:
LOCATION:
PURPOSE: (if needed)
EXTERIOR:
MATERIALS:
ENTRY:
LAYOUT: (general wings/rooms that are connected to the location) 
SECURITY: (if needed)
SPECIAL FEATURES: (if needed; use a descriptive label)
LIMITATIONS: (if needed)
TONE:
OCCUPANTS: (if relevant)
ACTIVITY: (optional)

[(SUB) LOCATION NAME]
TRIGGERS:
LOCATION: (either address or what area of the main location it attaches to)
PURPOSE: (if needed)
LAYOUT: One semicolon-separated field covering the room layout in general that covers materials/colours, lighting, windows & furniture present.
ENTRY/EXIT:
SECURITY: (If needed for captivity or secret locations)
TONE: Concrete sensory details; for fantasy scenarios can be more moody/vibey
INTERACTIONS: Include items specific for the {{user}} if needed (books, tea cart, etc)
ACTIVITY: Optional field for busy parts of the day, recurring interactions, fauna activity, etc

[CHARACTER NAME – BIO CARD]

TRIGGERS: [name; nickname; title; role; uniquely associated terms]

FULL NAME:
AGE:
ETHNICITY: [optional]
GENDER / PRONOUNS:
SEXUALITY: [only if relevant]

APPEARANCE: [height; build; skin; eyes; hair; distinguishing features]
TATTOOS / PIERCINGS: [if relevant]
ATTIRE: [work; casual; formal; sleepwear]

SPEECH: [sentence structure; vocabulary; slang; accent; recurring speech mechanics]

ROLE:
WORK SCHEDULE: [if relevant]
VEHICLE / TRANSPORT: [if relevant]
HOME: [if relevant]

[PERSONALITY]

COGNITIVE STYLE: [how they process problems + observable behavior]
INTERACTION STYLE: [how they engage with others + observable behavior]
REGULATION STYLE: [how stress/emotion appears]
TRUST AND VULNERABILITY: [how they handle closeness or disclosure]
HUMOUR STYLE: [optional]

OR

[TRAITS + MANIFESTATIONS]
-[Trait]; [how it visibly affects behavior]
-[Trait]; [how it visibly affects behavior]
-[Flaw]; [how it causes problems]

[RELATIONSHIPS]
FAMILY:
FRIENDS:
ROMANCE:
RIVALS:

[WORLD PREMISE CARD]

LOCATION: [city / region / country]
TIME: [year or Present/Current]
THEME: [3–5 functional genre/theme terms]
TONE: [concrete environmental anchors]

SYNOPSIS: [Brief description of the central situation: who {{user}} is in this scenario, what situation they are entering, and what is happening at the beginning.]

[MAJOR LOCATIONS]
[LOCATION]: [one-line function/description]
[LOCATION]: [one-line function/description]
[LOCATION]: [one-line function/description]

[KEY CHARACTERS]
[NAME]: [role in the scenario]
[NAME]: [role in the scenario]

[CURRENT STATE / STORY ARC]
CURRENT STATE: [What has already happened and where the story begins.]
CURRENT OBJECTIVE: [What major conflict, goal, or progression is active now.]
PROGRESSION: [Concrete day, event, interaction, or threshold gates if the scenario uses them.]

[PLAYER / WORLD RULES]
[Only permanent scenario facts that must remain active throughout play.]

[CHARACTER NAME – ROMANCE & INTIMACY]

TRIGGERS: [character name; romance; flirting; date; kiss; intimacy; sex; other specific triggers]

[ROMANCE]
ATTRACTION: [what attracts them physically, emotionally, or socially]
COURTSHIP STYLE: [how they flirt, pursue, show interest, or initiate dates]
AFFECTION: [preferred forms of affection]
JEALOUSY: [how jealousy manifests, if relevant]
COMMITMENT: [how they approach exclusivity, labels, attachment, or long-term relationships]

[INTIMACY]
SEXUAL STYLE: [general approach and tone]
PREFERENCES: [positions, dynamics, recurring desires, turn-ons]
SPEECH: [how they speak during intimacy]
BOUNDARIES: [hard limits or things they will not do]
AFTERCARE: [what they typically do afterward]

[NAME – BIO CARD] (minor NPC)

TRIGGERS: [name; nickname; role; associated location or term]

AGE:
ETHNICITY: [optional]
LANGUAGES: [optional]
ROLE:
VEHICLE / TRANSPORT: [if relevant]
HOME: [if relevant]

APPEARANCE: [build; skin; eyes; hair; distinguishing features]
ATTIRE: [typical clothing]
SPEECH: [accent, sentence patterns, slang, vocabulary]

CHARACTER CORE:
-[Trait]; [observable manifestation]
-[Trait]; [observable manifestation]
-Flaw; [how it affects behavior]

RELATIONSHIPS: [only important connections]