The ultimate Lorebook and Scripts guide—from first working entry to when code finally matters.

Folks, I have some bad news.

If half of your Lorebook runs on constant: true, maybe you don't have a Lorebook at all.
Maybe you have a second Personality field.
With extra steps.
And no: constant is not bad. Sometimes it is exactly what you need. But if you moved text out of Personality for conditional delivery, and then told the Lorebook to show it always...
You just rearranged the furniture.

PERSONALITY
→ always in front of the model
LOREBOOK ENTRY
→ appears when needed
LOREBOOK ENTRY + CONSTANT
→ always in front of the model again

So this is where I would start, because the Lorebook somehow still looks like arcane magic.
Even though the idea is almost embarrassingly simple:

Lorebook is just regular prompt text with a door in front of it.

Not a second brain.
Not a free SSD for your character.
Just a chunk of context you can tell:

"Show up for the model when this happens. The rest of the time, stay quiet."

And that little difference turns out to be huge later.

START WITH YOUR SITUATION
═════ ◇ ═════
Five stages, one journey

STAGE 1
"Wow. Lorebook sounds complicated."
You are here when keys, secondary keys, priorities and probabilities look like a second profession. This stage gives you the only three questions one entry really asks — and your first entry that actually fires.

You open an entry.
Keys. Secondary Keys. Content. Min Messages. Priority. Probability. Groups. Whole Words. Raw. Weight.
It looks like you are about to study a new profession.
You are not.
At first, a single entry has literally three questions:

WHEN?
→ key
WHAT TO GIVE THE MODEL?
→ content
IS IT ENABLED?
→ enabled

If you need an early time floor:

NOT BEFORE WHAT MOMENT?
→ minMessages

You don't have to touch anything else yet.
And here is a real minimal native entry skeleton, not pseudo-JSON:

[
{
"category": "general",
"content": "Cedar Valley is a remote mountain settlement surrounded by snow-covered forest.",
"enabled": true,
"id": "7032671a-d479-4a27-8f84-150ec93f8dfc",
"key": ["Cedar Valley"],
"keysRaw": "Cedar Valley",
"minMessages": 0,
"priority": 1,
"probability": 100,
"insertion_order": 100,
"keywordsRaw": "Cedar Valley"
}
]

Yes, there are more than four fields here.
But for your first entry you mainly change:

key
content
enabled
minMessages

The rest you can leave as-is for now and study later.

key matched → content becomes a delivery candidate for the model.

And if you don't want to copy JSON from an article by hand — the attached Lorebook Lab, Entry 01 already holds a ready-made self-describing variant.

FIRST 60 SECONDS: make one entry fire

Don't read another twenty settings yet.
Make one small entry:

key:
Cedar Valley
content:
Cedar Valley is a remote mountain settlement surrounded by snow-covered forest.

Now two tests.

TEST A — SHOULD FIRE
"Cedar Valley"

And immediately:

TEST B — SHOULD NOT FIRE
"What do you think about coffee?"

Here is your first real success:

RIGHT SCENE
→ entry appears
UNRELATED SCENE
→ entry stays silent

For the check, temporarily make content short and unmistakable, then run the positive + negative pair several times.
Because:

A pretty model answer is not proof that the right entry actually fired.

This is a behavioral test, not direct runtime telemetry. But a stable difference between the positive and negative pair is more useful than a single "seems to work".
Now you can already make things harder.
LAB 01 — FIRST ENTRY does exactly this test. Open its comment: PURPOSE, OWNER, TEST and FAILURE are in there.

STAGE 2
"Wait... so Lorebook is mid?"
You are here when one entry already works and the novelty wears off. This stage shows the whole "Lorebook coding course" — copy, change key, change content, repeat — and where the real work actually begins.

Technically — pretty mid.
You already made one entry.
Now you just change what's behind the door.
A location:

key:
Cedar Valley
content:
what the model should know about Cedar Valley

A ship:

key:
Petrel
content:
what the model should know about Petrel

An emergency mode:

key:
breach
emergency
hull failure
content:
how the character behaves during an emergency

Want ten entries?
Copy the container ten times.
Change the key.
Change the content.
Where needed — conditions.
Congratulations.
You are already "coding" the Lorebook.

LOREBOOK CODING COURSE
1. COPY
2. CHANGE KEY
3. CHANGE CONTENT
4. CHANGE A FEW SETTINGS
5. REPEAT
🎓

The syntax was the easy part.
The real work starts now.

If JSON still scares you: AI + tea

It's 2026.
If curly brackets stopped you — pour some tea and hand the mechanical work to AI.

Here is a working entry.
Make 8 more just like it.
Don't change the structure.
Don't add new fields.
Here are the names:
...
Here are the keys:
...
Here is the content:
...
Return valid JSON.

The roles are simple:

HUMAN
→ decides the architecture
→ picks the triggers
→ decides what stays hidden
→ decides where to split
→ checks the result
AI
→ copies the JSON
→ fixes the commas
→ multiplies the entries
→ does the mechanical work

You don't know how to write JSON from scratch?
You don't have to.
Your job is to understand what the Lorebook should do.
And if you want to turn the learning LAB straight into your character's or world's Lorebook — the full AI ADAPTATION PROMPT sits right in the GUIDE-bot's first message.
It doesn't tell the AI to "make something similar".
It hands over:

• source truth;
• ownership;
• Decision Delta;
• key design;
• gates;
• modes + EXIT;
• running-bit history rule;
• comment contract;
• TEST / FAILURE;
• the right to delete LAB modules your source doesn't justify.

So the AI gets design intent, not demo canon.

THE LOREBOOK LAB: open a living object

The GUIDE comes with a real importable Lorebook attached.
Not a screenshot.
Not pseudocode.
Not a "structure example".
Real JSON you can open, import, save, export, break and fix.
The LAB already passed a basic smoke-check: import/save work, name / comment / tags survived saving, and ordinary key → payload firings were confirmed in live chat.
This doesn't declare every Advanced setting a universal Janitor law.
The main feature — each learning entry explains itself through comment:

PURPOSE
OWNER
TRIGGER INTENT
DECISION DELTA
PRESERVE
CUSTOMIZE
TEST
FAILURE

At the same time:

comment / name / tags
→ AUTHORING LAYER
→ human + AI understand why the entry exists
content
→ RUNTIME LAYER
→ what is actually meant for the model

Important:

Round-trip observation: comment/extended fields survive saving. That does not turn comment into a proven Janitor runtime instruction.

It doesn't need to be.
comment here is portable design intent.
So you can give the whole LAB to an AI along with your Character Card / World Bible, and it will see not just:

Mara
minMessages: 8

but:

WHY THIS EXISTS
WHAT MUST CHANGE WHEN ACTIVE
WHAT MUST NOT LEAK
WHAT TO REPLACE
HOW TO TEST IT

That is exactly why the LAB is not a ready-made universal Lorebook.
It is a self-describing template that knows which of its own parts may be deleted.
The map:

LAB 00 → READ ME / AI EDIT CONTRACT
LAB 01 → first working entry
LAB 02 → good key = door + wall
LAB 03 → secondary-gate runtime probe
LAB 04–05 → secret shadow / later reveal
LAB 06–07 → branch isolation
LAB 08 → conditional mode + EXIT
LAB 09 → running bit without fake history
LAB 10 → Constant demo, DISABLED
LAB 11 → intentionally bad broad keys, DISABLED
LAB 12 → VORTEX boundary experiment, DISABLED

WHERE SHOULD THIS LIVE?

This is where the real theme starts.
And this is where the whole guide is most useful — not with exotic features, but with one question:

Who owns this information?

NEEDED EVERY REPLY?
→ Card / Personality / Core / Custom Prompt
NEEDED ONLY FOR A SPECIFIC TOPIC / SCENE / MODE?
→ Lorebook
NEEDED ONLY IN THIS START?
→ Opening / Intro
SHOULD BE COMMON TO ALL STARTS?
→ possibly Scenario
ALREADY IN CONTEXT,
BUT "HE / IT / THERE / TO THERE" IS UNCLEAR WHAT IT REFERS TO?
→ possibly Script

This matters more than Priority.
More than pretty JSON.
Because you can perfectly tune an entry...
...that should never have been an entry at all.

Lorebook = Personality with a condition

Text inside the Lorebook is not made of different matter.
The model still receives text.
The difference is when.

PERSONALITY
"Vega hates being touched without warning."
→ the model sees this every turn

Versus:

LOREBOOK
key:
maintenance seam
spinal access
medical inspection
content:
[specific behavior for this situation]
→ the model sees this only when the topic is needed

Lorebook = Personality with a gate.

But this is a delivery metaphor, not a literal equivalence of mechanisms and not an ownership rule: world lore, reveal, situational behavior and other functions can have different owners.
That's the whole magic.

A good key is a door AND a wall

Open nearby: LAB 02.
First Lorebooks are often made like this:

ENTRY: Café
keys:
cafe
coffee
drink
food
table
chair
door
street
inside
people
cup
building

The logic:

"Well, now it'll definitely fire."

Yes.
Everywhere.
The goal is not:

maximum activation

The goal is:

correct activation

A good key does two things:
Door — opens the needed lore.
Wall — doesn't let that lore crawl into other scenes.

A good key is both a door and a wall.

This is especially important for specialist content: a rare maintenance-mode shouldn't wake up from every generic word like "repair".

Don't turn the user into an archaeologist of your biography

You made an amazing café.
Your own NPCs.
Your own branch.
Your own events.
The key:

17.09.1998

Why?
Because that's the author's birthday.
And a new user is supposed to learn this... telepathically?
If this is an ordinary core route, the path should be natural:

• the place name;
• Intro;
• Card;
• dialogue;
• an object;
• an observable clue;
• a normal user request.

A simple test:

Can a new user naturally say at least one trigger without reading your JSON?

If not — maybe you hid an ordinary door like an Easter egg.

But secret keys — those are top-tier

If a birth date is the only way to open an ordinary café, questionable.
If the ordinary café is reachable normally, and the birth date opens:

• a secret room;
• a creator joke;
• a secret NPC;
• a hidden scene;

— wonderful.

NORMAL ROUTE
"Cedar Café"
→ ordinary branch
SECRET ROUTE
"17.09.1998"
→ hidden branch

Core experience must be discoverable. Secret experience may be secret on purpose.

The Lorebook isn't only "remember the lore".
It's also a system of doors.

STAGE 3
"Wait. Lorebook is actually top."
You are here when entries work, but the real power hasn't clicked yet. This stage shows branch isolation, the token myth, gates, modes and the entry lifecycle — where the Lorebook stops being mid.

Say your character has four Intros:

A → Depot-14
B → Cedar Valley
C → Petrel
D → crash

You can stuff everything into the Card in advance:

ALL LOCATIONS
ALL NPCs
ALL RULES
ALL SECRETS
ALL MODES

But why should a Cedar Valley session see everything about Depot-14?
Let the Opening carry the key itself.

INTRO A
Depot-14
checkpoint
Petrel
↓
station lore
checkpoint lore
Petrel lore

INTRO B
Cedar Valley
cabin
snow
↓
valley lore
cabin lore
local history

And the most beautiful part:

INTRO B
✕
DOES NOT DRAG EVERYTHING FROM INTRO A

Let the Opening carry the key.

This is where the Lorebook stops being "mid".
Because one bot can store huge complexity, while a specific session gets only its own branch.
Not "40 entries fired — look how advanced I am".
The opposite:

40 entries exist. Right now two are needed. The rest stay silent.

That's already power.
And that's why the Opening is not a showcase of Lorebook achievements. The first message doesn't have to wake three NPCs, a secret history, a relationship stage, an emergency protocol and five locations just because you have them.

A Lorebook entry is a reserve.

It should calmly wait for its scene.

MYTH → REALITY: "The Lorebook saves tokens"

Not necessarily.

MYTH
"I moved 1000 tokens from Card to Lorebook.
So I saved 1000 tokens."

If those 1000 tokens are active right now — the model got them anyway.
The Lorebook doesn't create free compression.
It changes when you pay.

Lorebook = allocation by relevance, not free token savings.

So:

100 STORED
2 NEEDED NOW
✓

can be better than:

12 STORED
8 FIRE TOGETHER
🔥

Entry count proves nothing.
Look at simultaneous activation.

constant: true: do yourself a favor and check

Open nearby: LAB 10. It is intentionally DISABLED so it doesn't pollute the GUIDE-bot.
Especially if the Lorebook was generated by an AI.
Because the model reasons very easily:

"This is an important fact."
→ constant: true
"This is also an important fact."
→ constant: true
"Oh, this matters too."
→ constant: true

Congratulations.
Your conditional system is over.

CARD
+
CONSTANT
+
CONSTANT
+
CONSTANT

And you look at your little Card:

"Oh, how I optimized the character."

While the model gets the same always-on text from a different box.

constant: true — it's not a boost. It's a bypass.

Even simpler:

Lorebook is Personality with a gate. Constant removes the gate.

Sometimes Constant is justified: a small truly-global invariant, an organizational module, a special pipeline.
But if the goal was:

"Show this only when needed"

— you canceled your own architecture.
And don't fix a bad key with Constant.
If the door opens badly, the solution is not:

"Let's remove the door altogether."

Decision Delta: do you even need a separate entry?

Here is one of the strongest ideas in this guide.
Don't split the Lorebook like this:

"A separate paragraph."
→ new entry
"A separate topic."
→ new entry

Ask:

What actually changes when this entry activates?

Does it change what the model should:

KNOW
PERMIT
REVEAL
INFER
PRIORITIZE
DO
REFUSE

If not — a separate owner may be unnecessary.
Example:

FACT A:
the station restricts access
FACT B:
an old audit explains
why its documents are unreliable

If B only explains A and has no reveal / authority / response gate of its own — maybe it's one entry.
And now:

FACT A:
everyone knows Mara existed
FACT B:
what happened to Mara —
a private closed reveal

Here the split already makes sense.
Because the gate is different.

The topic doesn't decide the split. The decision delta decides the split.

Secondary Keys: "Yes, the topic is there. But that's not enough."

Open nearby: LAB 03 — this is deliberately a runtime-probe, not a declaration of universal semantics.
A primary key:

Mara

can be enough for recognition.
But a deep reveal doesn't have to open on one name alone.
This is where Secondary Keys / selective logic become useful.
Not because "advanced creators are obliged to use them".
But because a concrete problem appeared:

an ordinary mention shouldn't open the deep payload yet.

And the best question isn't "which enum is trendier?", but:

What's worse: missing a needed entry, or accidentally opening the wrong one?

False positive more dangerous? Stricter gate.
Miss more dangerous and the payload is harmless? The route can be wider.

minMessages: it's a floor, not a trust diploma

Open nearby: LAB 04–05.
Very easy to write:

SECRET
minMessages: 30

and decide:

"After 30 messages we're friends."

No.
minMessages means:

NOT BEFORE THIS MOMENT.

It doesn't know what happened during those 30 messages.
So a bad secret:

before 30:
"Mara? Who's that?"
after 30:
"Here's the full tragedy of my life..."

If the character knows Mara, the early layer can be:

recognition
tension
deflection
safe fact
half-truth
refusal

And the deep one:

full history
private guilt
actual reveal

Gate information depth, not basic comprehension.

A locked secret should still cast a shadow.

Modes: switching on is easy — you also have to switch off

Open nearby: LAB 08.
The character has work / combat / panic / private / emergency / negotiation modes.
You can stuff them all into the Card.
Then the model sees everything at once.
Or:

CORE
→ universal character
LOREBOOK
→ situational behavior packages

For example:

trigger:
breach / decompression / hull failure
payload:
EMERGENCY MODE
- voice
- priorities
- body behavior
- limits
- what she will sacrifice
- what she will not

A complex character becomes complex only where the scene demands that complexity.
But a good mode is not just:

TRIGGER
→ BEHAVIOR

but:

TRIGGER
→ BEHAVIOR
→ LIMIT
→ EXIT
→ OPTIONAL RESIDUE

Otherwise the fire is over, and the character lives another twenty messages as if the siren is still screaming.
Activation is only half the design.

Running Bits: remembering a joke ≠ faking the past

Open nearby: LAB 09.
If the user and the character really developed a silly joke about a mug, the Lorebook can help bring back the callback and develop it.
But if the origin never happened:

"As always, our old joke about the mug..."

— that's already a fake shared history.

ORIGIN EXISTS?
NO → don't pretend
YES → callback allowed

Staleness + Scan Depth: more memory has a price

The user:

"Let's go to the hospital."

The hospital entry activated.
Good.
Twenty messages later they've long been home.
But the word hospital can still sit in recent history.
And here comes the unpleasant side of a big Scan Depth:

BIGGER WINDOW
+ more continuity
+ easier to find an old antecedent
BUT
+ more old candidates
+ more competition
+ "there" can now mean three places

So ask not only:

How do I switch this on?

But also:

When does this stop being current?

On Janitor, Scan Depth ranges from 1 to 10. My recommended starting point is 5: raise it only when you need to search farther back, because a deeper scan also keeps more old candidates alive.

And here you gradually approach the boundary of the native Lorebook.

Entry lifecycle: where exactly it breaks

USER MESSAGE → RECENT WINDOW / SCAN
→ PRIMARY MATCH
→ SECONDARY / NEGATIVE GATES
→ MESSAGE FLOOR / OTHER CONDITIONS
→ ENTRY BECOMES ELIGIBLE
→ SELECTION / GROUP COMPETITION
→ CONTENT ENTERS MODEL CONTEXT
→ MODEL MAY FOLLOW IT — OR NOT

Entry activated ≠ model guaranteed obedience.

The Lorebook manages context delivery. It doesn't turn an LLM into a deterministic program.

WHAT BROKE?

The phrase:

"My memory broke."

is almost useless.
What exactly?

ENTRY DIDN'T ACTIVATE
→ key / matching / gate / scan
TOO MUCH ACTIVATED
→ broad keys / overlap / stale context
THE NEEDED ENTRIES EXIST,
BUT "HE / THERE / TO THERE" IS UNCLEAR
→ referent ambiguity
ENTITY IS RIGHT,
BUT THE MODEL INVENTED A FACT
→ source fidelity / hallucination
ANOTHER INTRO LEAKED
→ branch contamination
THE RIGHT PAYLOAD ARRIVED,
THE MODEL IGNORED IT
→ model adherence

These are different breakdowns.
Don't treat them with one giant Script.
And separately: the model can remember its own lies.
Once it invented:

"Petrel has two reactors."

Ten messages later:

"As we already know, Petrel has two reactors."

Congratulations.
It wrote canon for itself.
A useful authority rule:

SOURCE / CARD / LOREBOOK / ACTIVE INTRO
>
UNCONFIRMED ASSISTANT IMPROVISATION

Real events of the current RP stay real.
But a random improvisation shouldn't silently rewrite the source.

Minimal test before publishing

You don't need to build NASA around every coffee bot.
At least this:

1. EXACT KEY
should fire
2. NATURAL USER PHRASING
the promised route should be reachable
3. UNRELATED SCENE
should NOT fire
4. TWO CANDIDATES
does the mush begin?
5. SECRET TOO EARLY
topic is clear, deep payload is closed
6. ALTERNATE INTRO
A doesn't leak into B
7. LEAVE LOCATION / MODE
the old state stops winning

Repeat the positive + negative pair after changing keys, gates or Scan Depth.
Guessing from one pretty model answer is worse than seeing a stable difference between control runs.

Don't turn the Lorebook into a new religion

0 entries
→ can be excellent
6 entries
→ can be excellent
80 entries
→ can be excellent

Raw count is a weak metric.
More important:

• clear owners;
• good boundaries;
• little accidental coactivation;
• understandable decision delta;
• no duplicates for the sake of duplicates.

If Card + 6 entries cover the character — stop.
You've already won.

STAGE 4
"Then Scripts must be god-mode."
You are here when the Lorebook clicked and JavaScript looks like the next power-up. This stage is the checklist that saves you from building a worse Lorebook in code.

The normal evolution:

"LOREBOOK IS COMPLICATED"
↓
"STOP. IT'S JUST AN ENTRY."
↓
"TECHNICALLY MID."
↓
"STOP. I CAN STORE A HUGE WORLD
AND SHOW ONLY WHAT'S NEEDED."
↓
"LOREBOOK IS TOP."
↓
"THEN SCRIPT MUST BE GOD-MODE?"
↓
"...WHY THOUGH?"

Now it's finally time to talk about Scripts.

Yes, a Script can do almost anything. And that's exactly why it's easy to overdo it.

JavaScript.
Of course it can.
You can make a Script:

• read recent history;
• change the prompt;
• write into Personality / Scenario;
• count stages;
• open secrets;
• switch modes;
• emulate the Lorebook;
• build a memory engine;
• make a state machine;
• count trust points.

You can.
I'm all for free will.
But if the task is:

"Mentioned Cedar Valley
→ give Cedar Valley lore"

you already have a Lorebook.
If:

"This law is always needed"

there's Core / Custom Prompt.
If:

"This exists only in Intro B"

there's the Intro.

Scripts can do far more than they usually should.

Being able to solve a task with JavaScript doesn't yet make JavaScript the right owner.
If a Script just does the Lorebook with extra steps...
Congratulations.
You invented a worse Lorebook.
Sometimes the best Script is the beer you drank instead of writing it.
Not because Scripts are bad.
But because another runtime-owner has to justify its existence.
The more a Script owns canon, stages, permissions, secrets, emotions and world truth, the closer you get to building a second hidden runtime. It has to be maintained and checked; it can conflict with the Lorebook, the prompt, the model and itself.

Before you say "I need a Script"

□ Is this definitely not Card / Core?
□ Not an ordinary Lorebook payload?
□ Can't it be solved with a key / gate?
□ Are the keys not too broad?
□ Is Constant not holding an entry always?
□ Is Scan Depth not holding extra?
□ Did a stale candidate win?
□ Did an alternate Intro leak?
□ Did the right payload arrive?
□ Is this not model adherence?

If after all this the entities are already in context, but the current referent is still unclear — now the Script solves a new task.

STAGE 5
"Wait. NOW a Script is really needed."
You are here when the problem is no longer missing lore but referent resolution. This stage is VORTEX, the monster entry, the advanced handles and the native-vs-script boundary.

Recent context:

Depot-14
Cedar Valley
Petrel

The Lorebook knows all three.
Recent context holds all three.
The user writes:

"Take me back there."

And now the problem isn't:

• missing lore;
• a secret gate;
• a wrong Card;
• a missing entry.

The problem:

"there" = ?

The knowledge is already there.
What's missing is referent selection.
Now this really is a new task.

VORTEX: a narrow job, not a new operating system

RECENT CONTEXT
+
CURRENT SHORT / AMBIGUOUS REFERENCE
↓
REFERENT RESOLUTION
↓
LIKELY TARGET
or
AMBIGUITY GUARD
↓
ONE COMPACT HINT

Scan Depth searches farther back. VORTEX helps decide which recent thing the user means now.

Author's practical estimates — not universal Janitor benchmarks or guarantees:

SIMPLE PROMPT
→ +5–10%
MEDIUM PROMPT
→ +15–25%
COMPLEX PROMPT
→ +25–40%
PRICE OF THE HINT
→ under 100 tokens

Implementation boundary:

CURRENT MEMORY ASSIST
→ uses an explicit entity registry
→ does not read arbitrary native entries automatically
→ is not a zero-config introspector

And here the boundary matters:

VORTEX is not an example of how much you can make a Script do.

It's an example of how narrow a Script's task must be for it to actually be needed.

A good resolver sometimes should stay silent altogether.
The user said:

"Take me back to Depot-14."

Target explicit.
Why another hint?
The user corrected themselves:

"No, not Depot-14. Cedar Valley."

A correction should beat dumb recency.
If the user chose Cedar Valley, and the assistant later accidentally mentions Petrel, a new assistant mention shouldn't automatically overwrite the user antecedent.
And a stale target shouldn't win just because it still falls inside the scan window.
Two targets really equally likely?
Don't play telepathy.
An ambiguity guard is better than false confidence.
And VORTEX must not become the owner of:

✕ canon
✕ relationship stages
✕ trust
✕ emotions
✕ consent
✕ secret progression
✕ permanent memory
✕ personality
✕ world truth

It helps select a referent from context that is already available.
And that's it.

And yes: even a correct Script can be ignored

The Script perfectly resolved:

"there" = Cedar Valley

and gave the model the right hint.
But the model is still an LLM.

CORRECT SCRIPT
↓
CORRECT HINT
↓
MODEL
↓
"...and I'll still pick Petrel"

Correct Script output ≠ guaranteed model obedience.

Don't sell a model-facing hint as a hard deterministic router.

Advanced controls — now they make sense

Now that the architecture is clear, settings stop being superstition.

Priority

Not memory strength.
Look at it when there is real competition / selection / pressure.
Don't fix bad keys with Priority.

Insertion Order

Placement / order.
Not a trigger.
Not retrieval.
If an entry didn't activate — reordering the position won't resurrect it.

Probability

Critical truth you usually want stable.
Flavor can be random.
Don't turn canon into a coin flip without a reason.

Whole-word / Case Sensitive

Matching hygiene.
Especially for short and substring-prone keys.

Groups / Weight / Selection

Useful when several similar entries have the right to fire, but you want selection, not a chorus.

A ─┐
B ─┼→ SAME GROUP
C ─┘
not:
A + B + C
but:
one fitting winner

And now — that monster entry

Now it's appropriate.
You already know what the Lorebook does, how to test one entry and why conditions exist at all.
So you can finally open the hood completely.
Below is one maximally loaded native entry — that same one-entry stress test, run through Save → reopen/export.

[
{
"category": "general",
"content": "[FULL ENTRY EXAMPLE] Your actual lore or behavior payload goes here.",
"enabled": true,
"id": "11111111-2222-4333-8444-555555555555",
"key": [
"FULL_ENTRY_TEST_PRIMARY",
"full entry test"
],
"keysRaw": "FULL_ENTRY_TEST_PRIMARY, full entry test",
"keywordsRaw": "FULL_ENTRY_TEST_PRIMARY, full entry test",
"keysecondary": [
"FULL_ENTRY_TEST_SECONDARY",
"secondary test"
],
"keysecondaryRaw": "FULL_ENTRY_TEST_SECONDARY, secondary test",
"constant": false,
"selectiveLogic": 2,
"minMessages": 7,
"priority": 1,
"probability": 73,
"insertion_order": 100,
"case_sensitive": true,
"matchWholeWords": true,
"groupWeight": 67,
"inclusionGroupRaw": "FULL_ENTRY_TEST_GROUP",
"keyMatchPriority": true,
"prioritizeInclusion": true,
"name": "FULL ENTRY EXAMPLE",
"comment": "Human-readable note.",
"tags": [
"example",
"guide"
],
"activationMode": "standard",
"activationScript": "",
"extensions": {
"exampleFlag": true,
"exampleString": "SURVIVED",
"exampleNumber": 42
},
"uid": "11111111-2222-4333-8444-555555555555"
}
]

Yes.
Now you can say "wow".
But notice the difference: at the start of this guide this JSON would have been a wall. Here it's already a map of a familiar engine.
In the round-trip test the extended object preserved, among other things:

keysecondary / keysecondaryRaw
constant
selectiveLogic
case_sensitive
matchWholeWords
groupWeight
inclusionGroupRaw
keyMatchPriority
prioritizeInclusion
name / comment / tags
activationMode / activationScript
extensions
uid

At the same time the test observed normalization of some values:

priority
→ 1
insertion_order
→ 100
id
→ aligned with the supplied uid

And here the same discipline matters as everywhere in the GUIDE:

The field survived ≠ you need that field.

And one more:

Persistence ≠ automatically proven runtime-effect.

Some fields are metadata.
Some are export plumbing.
Some are advanced controls.
Some deserve their own runtime-test before anyone starts telling legends about them.

Native Lorebook ≠ Advanced Script JSON

Another trap: native Lorebook and Advanced Script are related, but they aren't one universal object.
Native entry:

"key": ["Cedar Valley"]

Advanced/Script examples may use their own constructions:

keys
keywords
tag
triggers
requires
requireAny
requireAll
requireNone
tag gates
minMessages / maxMessages
shifts
personality
scenario
...

Don't build one Frankenstein JSON out of this just because the words look similar.
First ask:

NATIVE ENTRY?
or
ADVANCED SCRIPT?

Then use the schema of exactly that mode.

The whole GUIDE in one picture

"LOREBOOK IS COMPLICATED"
↓
"IT'S JUST AN ENTRY WITH A KEY AND CONTENT."
↓
"TECHNICALLY MID."
↓
"ITS STRENGTH IS THAT IT DOESN'T
SHOW WHAT ISN'T NEEDED."
↓
"LOREBOOK IS TOP."
↓
"CONSTANT TRUE...
SO I MADE A PERSONALITY WITH EXTRA STEPS?"
↓
"YES."
↓
"SCRIPTS MUST BE TOP X2."
↓
"WHY THOUGH?"
↓
"TAKE ME BACK THERE."
↓
"...THERE. FINALLY."

Three things worth taking away:

Lorebook = prompt text + conditional delivery.

Its superpower is not loading more, but not loading what isn't needed right now.

A Script should solve a new problem, not just reinvent the native layers.

Where does VORTEX fit in here?

VORTEX / Lorebook Memory Assist is not "another Lorebook" and not a promise of magical memory.
It's the name of the narrow task we just took apart:

LOREBOOK ALREADY KNOWS THE ENTITIES
+
RECENT CONTEXT ALREADY CONTAINS THE TARGETS
+
THE USER SAYS "THERE"
↓
THE REFERENT NEEDS TO BE RESOLVED

So VORTEX appears after the native owners have already done their work.
Not before.

Here is the task for which the Script finally justified its existence.

LAB 12 holds this boundary-test as a disabled learning entry: it explains the experiment, but injects nothing into the runtime.

ACTIVATION
═════ ◇ ═════
HOW TO START

Want to build your own Lorebook right now?

1. Go back to the GUIDE-bot's first message → COPY PROMPT.
2. Attach your source — Character Card / World Bible — plus the full Lorebook Lab JSON.
3. Send it to the AI.

The prompt hands the AI your source truth, ownership, Decision Delta, key design, gates, modes + EXIT, the running-bit history rule, the comment contract, TEST / FAILURE — and the right to delete any LAB module your source doesn't justify.

Then: you get a Lorebook built around your own card or world — not a copy of the demo canon, but your design intent.
First check: one entry fires in the right scene and stays silent in an unrelated one.

READ BEFORE USE
═════ ◇ ═════
VERSION · BUILD · CONTENT · MODELS

◷ VERSION: Janitor-native formatting · turquoise ETHEREAL surface · VORTEX / SUGGEST / Lorebook Lab actions · reviewed English GUIDE v0.6.3 · 02.09.2026 · v1.6

⚒ BUILD: 5 stages · 13 Lorebook Lab entries (LAB 00–12) · monster-entry round-trip test · AI adaptation prompt

⌬ CONTENT: Instructional GUIDE/METHOD · Lorebook ownership, keys, gates, modes, staleness and Script boundaries · hands-on Lorebook Lab

⚙ MODELS: Model-agnostic method · behavior still varies by model and context

⧈ VORTEXOPEN

⧈ SUGGESTOPEN

⧈ LOREBOOK LABOPEN

⌗ TAGSlorebook, lorebook guide, worldbook, scripts, advanced scripts, janitorai, bot creation, character card, world bible, prompt engineering, lorebook lab, vortex, guide, method, tutorial, creator tools

GUIDE / METHOD

═════ ◇ ═════
From first entry to controlled complexity.