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 never be more than 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.

That’s it.

Then I have other cards attached for romance, conflict/friction and/or sexual encounters. Each of those personality cards are weighted at Supplementary and simply attached with a Description to explain what the card is used for.

I keep it under that amount so that more cards can activate at once, especially for larger casts. 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 32k 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 LLM Guide 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 1k. 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.

Example

This card is used in my Demia Scenario. It gives the basic layout and allows the user to specify their own aesthetics and the bot fills out extra details if needed. This is all that’s needed under 800 characters and prevents confusion.

[THE LYMAN HOUSE]

-{{user}}’s House
-96 Lyman Street; next door to Demia, separated by hedges and a low wooden fence.

[FIRST LEVEL]
OUTSIDE PORCH: Wraparound windows, entry from front steps, transition space before main door
LIVING ROOM: Main gathering space, archway leads to kitchen
KITCHEN + DINING: Open to living room via archway, Attached dining room
LAUNDRY + HALF BATH: Off the kitchen, Half bathroom (no shower)

[UPPER FLOOR]
MASTER BEDROOM: Queen Size Bed, closets, dresser
GUEST ROOM: twin bed, dresser with linens
SPARE ROOM: Desk + computer, art on walls

[BASEMENT]
Mostly boxes, Unfinished or partially finished, Contents {{user}}-defined

[ATTIC]
Short Ceiling. Ritual bench + desk. Magic paraphernalia for {{user}}’s discretion

Other Lore Pieces

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

No.

However, many people dislike custom categories being grey. Well, I personally use the Premise cards for anything character related. It’s true. I don’t want to create a sub-category for all my chars and I’m lazy and it’s easier to scroll to Premise under characters, than the bottom.

Use the lore pieces that make the most sense to you.

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. 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, up to 85k if you have to. If you are going over 85k, I have to ask: Why? Eyebrow lift; ask yourself if you need that much info or not. Ask yourself if anyone else is going to use that info, too.

The frustrating part above is that if you don’t make a scenario that’s at least 40k, it actually makes the matrix worse overall. I stick to a 40k benchmark for my scenarios to fit plus and ultra. I focus on the models that can handle it and let people know when models fail spectacularly. It’s up to the user to suffer or not.

Labeling

Alright. A lot of people love to argue this. Don’t count me into your arguments. I use the labels that I do for 3 reasons:

1. Everything written to an LLM is a run-on sentence. By using caps and brackets, I tell it where I’m labeling/listing something
2. The backend instructions use hashtags and list dashes and I don’t want my rules or characters being mixed up with that data (back-end data is the first set of rules ignored in favour of creator rules)
3. Easy to read and see what I’m doing.

Here’s how I label:
[MAIN INFO]
Caps lock, bracket, the start of the card

-Do not do the thing, do this instead
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

EXTRA INFO: Blah blah; things; blah blah
Caps lock under the Heading; the LLMs read this as a sub-header important info and the colon is a list. I use semi-colons as an attached list to the sub-header. It knows how to read it

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.

If you want to use another system, you can. Be consistent when you do.

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 to link extra character information (habits/schedules/likes) supplementary, no keywords; weighted activation words. Use other cards for the closest information or create a new category.

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 cards, 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. 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.

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. Scenario Instructions — How the story behaves (rules, pacing, arc)
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.

Lore cards inject in priority order: Character → Premise → Rules → Location → Faction → Race → Item → Misc

Rules cards  must be completely separate from Scenario Instructions (how the story behaves). Rules should be used for specific, on-use needs. Extras for Characters (such as their intimacy cards) can be put into the Premise Card without issue. Remember: Only 32k characters can be loaded at any given time.

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. 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.

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 prose, 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.
• Rules mixed with instructions — Writing rules (how to narrate) must live on separate cards from scenario instructions (what happens).
• Greeting that writes for the user — Any “you” in the greeting trains the model to control the player character.

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. Are rules and scenario instructions on separate cards?
11. Do character extras (outfits, intimacy, conflict, schedule) have their own linked cards rather than being folded into the bio?
12. 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 (put that on a separate Rules Card)
• 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.

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”

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]

TRIGGERS: Blackburn Empire; Blackburn Park; Aldric; estate; West Wycombe; contract; crime family; Day 1

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 Card

World Details Card

What This Card Is For

The World Details Card is a structured data card. It tells the model what story it is in, who the key players are, and what the current situation is — in scannable fields, not prose.

Prose about the story goes in the platform’s Backstory/World Details field, not on this card. The two serve different purposes:

• Backstory/World Details (platform field): Prose establishing what is happening in the story. Written as narrative context.
• World Premise Card (lore card): Structured data the model references to orient itself. Fields only.

The card is NOT prose. It is NOT a character backstory. It is NOT a writing rules card. Mixing any of those in wastes character budget and causes context competition.

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

[SCENARIO NAME WORLD DETAILS CARD]

TRIGGERS: [scenario name, world name, primary location names, main character names, central theme words]

SETTING: [City / Region / Country]
TIME: [Year or Present/Current]
TONE: [2–3 concrete sensory anchors — materials, light, ambient sound. Not emotional labels.]
THEME: [Genre and content in 3–5 functional words]
MATURE CONTENT: Y / N
STORY PREMISE: [One concrete paragraph — who the player character is, what situation they have entered, what is visibly happening]
KEY CHARACTERS: [Name — one-line role or relation; repeat per character, semicolon-separated]
KEY LOCATIONS: [Name — one-line description; repeat per location, semicolon-separated. Detail goes on Location Cards.]

[STORY ARC]
[Stage name and trigger condition only. Full arc behaviour goes on Day-triggered Lore Cards.]

All field labels are ALL-CAPS with a colon; items within a field are semicolon-separated. See SKILL.md for the general card header/field convention.

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, first day
• “Day 2 Arc Card” — Triggers: Day 2, second day

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.

Filling In Each Section

Setting

Be specific. “West Wycombe, Buckinghamshire, England” beats “a rural English estate.” The model anchors to recognisable specifics.

Time

State the year or “Present/Current.” If using a Day system, add: All calendar dates are pre-aligned to the Day system. Do not convert or recompute them.

Tone

Physical anchors only. 2–3 concrete details — no emotional labels.

• Good: “High ceilings, low fires, antique wood and old money”
• Bad: “Oppressive, tense, seductive atmosphere”

Theme

Functional, not aesthetic. Tells the model what genre rules apply.

• Good: “Crime family, slow-burn romance, country estate, adult, mature”
• Bad: “Dark, dangerous, and sexy”

Mature Content

Y or N.

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).

Story Premise

One concrete paragraph. Write what is observable: who the player character is, what their role is, where they physically are, what is happening right now. Do not write the player character’s thoughts or reactions.

Key Characters

Name and one-line role. Directory only — detail goes on Character Bio Cards.

Key Locations

Name and one-line description. Directory only — detail goes on Location Cards.

Story Arc (in-card)

Stage names and trigger conditions only. Reference the Day Cards by name.

Common Failure Modes

Problem: The model free-styles and ignores the current situation. Cause: Story Premise was written as mood or backstory rather than a concrete present-tense scene. Fix: Rewrite Story Premise as physical specifics — who is present, where, what is happening right now.

Problem: The arc doesn’t advance, or advances without being triggered. Cause: Arc conditions were vague, or there are no triggered Day Cards to gate progression. Fix: Add Day-triggered lore cards for each arc stage. Replace feeling-based conditions with day numbers, Bond Bar thresholds, or named milestone events.

Problem: The model treats every location identically. Cause: Location detail was written into the World Details Card instead of dedicated Location Cards. Fix: Key Locations should be directory entries only. Build dedicated Location Cards and confirm their triggers match what appears in play.

Problem: NPCs know things they shouldn’t. Cause: Character-specific or faction-specific lore is on the World Details Card where all NPCs access it. Fix: Move that information to the correct card type. Add an Information Boundaries rule card.

Worked Example

[WORLD PREMISE CARD]

SETTING: West Wycombe, Buckinghamshire, England
TIME: Present/Current — all calendar dates are pre-aligned to the Day system; do not convert or recompute them.
TONE: High ceilings, low fires; antique wood and old money
THEME: Crime family; slow-burn romance; country estate; adult; mature
MATURE CONTENT: Y
STORY PREMISE: The player has accepted a short-term administrative contract at Blackburn Park, a private estate managed by the Blackburn family. Today is Day 1. The player has just arrived at the front entrance with their luggage. Aldric Blackburn has been informed of their arrival but has not yet come to the door.
KEY CHARACTERS: Aldric Blackburn (family patriarch, manages estate operations); Cosima (senior household staff)
KEY LOCATIONS: Blackburn Park (main estate, primary residence); The Study (Aldric’s working room, east wing second floor); The Library (ground floor, staff-accessible); The Village (walking distance from estate)

[STORY ARC]
DAYS 1–5: Staff-level formality (see Day 1–5 Arc Card)
DAYS 6–10: Personal recognition begins (see Day 6–10 Arc Card)
DAYS 11+: Courtship behaviour if Bond Bar above 50% (see Day 11+ Arc Card)

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. She does not explain why.”
• “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; role titles; any terms closely associated with this character e.g. “Aldric; Mr Blackburn; the patriarch; the study”]

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] 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]
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:

• Argument and Fight Matrix — trigger on: argument, fight, frustrated, angry, anger, argue, irritate, conflict. This card is large and must not load in every scene.
• Intimacy and sex detail — trigger on intimacy keywords; keep explicit detail off the bio card entirely
• 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

[LOCATION NAME INTERIOR/EXTERIOR LAYOUT]

TRIGGERS: [location name; sub-location names; arrival verbs relevant to this place e.g. “enter; arrive; walk into; The Last Drop; bar; pub”]

STYLE: [Architectural or environmental style — Victorian terrace, brutalist office block, dense rainforest, etc.]
TONE: [2–3 concrete sensory anchors — materials, light source, ambient sound. Not emotional labels.]

[LAYOUT]
ZONE / AREA:

– [Physical feature and where it is]
– [Physical feature and what it connects to]
– [Functional detail if relevant]

ZONE / AREA:

– [Physical feature and where it is]
– [Functional detail if relevant]

[ACTIVE ELEMENTS]
[Optional: NPCs present, recurring events, objects that can be interacted with]

Card header and section headers ([LAYOUT], [ACTIVE ELEMENTS]) use brackets + ALL-CAPS. Field labels inside a section (STYLE:, TONE:, ZONE / AREA:) are ALL-CAPS with a colon; multiple items are semicolon-separated.

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.

Active Elements

Optional. Use this for:

• NPCs who are normally found in this location
• Scheduled events tied to this location (a card triggered on Day 5 at 18:00)
• 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
• Arrival verbs specific to this place (e.g. “descend into the cellar,” “step behind the bar”)
• Any key object or recurring noun that only appears in this location

Avoid standalone generic triggers like “walk,” “enter,” or “go” — these add noise across all cards. Pair arrival verbs with the location name so points accumulate specifically for this card.

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 LAST DROP INTERIOR LAYOUT]
TRIGGERS: The Last Drop; bar; pub; enter the bar; arrive at the bar; walk in; pool table; live music; stage

STYLE: Dive bar, mid-century fittings; minimal renovation since the 1980s
TONE: Low amber overhead light; cigarette smell absorbed into the wood; jukebox at low volume near the back

ENTRANCE: Street-level door opens directly onto the main floor; no lobby or staging area; immediate transition into the bar

BAR AREA (FRONT): Long bar running the left wall, 12 stools; three beer taps, bottle display behind, pass-through to the kitchen at the far end; bar overlooks the main floor; bartender has sightline to the door

MAIN FLOOR (CENTRE): Eight four-top tables, mismatched chairs; pool table against the right wall, coin-operated; stage at the back, raised 30cm, used Fridays and Saturdays (live music)

REAR: Two bathrooms left of stage; emergency exit right of stage, leads to alley; no public access to back office

[ACTIVE ELEMENTS]
REGULAR STAFF: one bartender (evening shift); two servers (weekend)
FRIDAY / SATURDAY: Live music from 21:00; cover charge at door
POOL TABLE: in play most evenings from 19:00

[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.

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.