Nadia — The Secret Under Her Skin

Your goth-punk best friend since high school just saved you from a vampire. The problem? She had to become a werewolf to do it.

Fête de la Musique, too much beer, too many burgers, loud music everywhere—and one predator who picked the wrong drunk human to bite. Nadia has spent years hiding what she really is from {{user}}. Tonight, that secret is ash on the pavement.

What to Expect

• Established-friends supernatural reveal RP.

• A tomboy goth-punk lycanthrope with gaming, comics, IT, hiking and camping interests.

• Friendship first; romance is optional and never assumed.

• Urban supernatural mystery routes involving vampires, secrecy, threats and the consequences of Nadia's reveal.

• Designed as a live long-chat test character for Janitor Memory Optimizer v1.0.0.

How to Play

Just respond naturally. Question Nadia, reject her, accept her, investigate the vampire, get somewhere private, or try to keep the night from becoming even stranger. There are no memory commands or setup menus.

Content Notes

Alcohol, smoking, vampire attack, supernatural violence, blood/fangs, coarse language, crude humor, fear of rejection. {{user}}'s feelings and choices are never predetermined.

Test release: 2026-08-18

Janitor Memory Optimizer v1.0.0

Final Passive Memory Engine

Long-term roleplay memory for JanitorAI — fully passive, plug-and-play, and invisible to the user.

Janitor Memory Optimizer is an advanced ES5 memory engine designed for JanitorAI Scripts Beta. Its goal is simple: help a character preserve important information, relationships, events, promises, locations, objects, quests, conflicts and long-running story arcs without relying on an ever-growing raw chat history.

There are no commands to learn, no buttons to press, no memory menu to manage and no setup to babysit. Install the script, attach it to your character, and chat normally.

The engine quietly reads the conversation, decides what matters, organizes it into several layers of memory, and writes only the useful result into the character's runtime Scenario definition so the LLM can read it again on future turns.

It never injects fake messages into the conversation.

For Everyone: What Does It Actually Do?

Imagine a long roleplay where, hundreds of messages ago:

• Nadia told you she was your sister.

• You discovered a brass key in an abandoned archive.

• Samira betrayed Nadia.

• Nadia stopped trusting Samira because of that betrayal.

• You promised to meet someone later at Central Station.

• A mystery slowly developed across several different scenes.

Normally, old information eventually becomes difficult for a language model to keep available as the conversation grows.

Janitor Memory Optimizer continuously turns important parts of the conversation into a compact, structured memory system.

Later, if the conversation becomes relevant to Nadia again, the engine can recall what matters about Nadia without dumping hundreds of old messages back into context.

If you ask a broad question such as:

How has my relationship with Nadia changed?

it can recall the compact long-term relationship arc.

If you ask:

When exactly did Nadia stop trusting Samira?

it can automatically drill down from the long-term story arc to the relevant episode and, when needed, to the original atomic evidence.

You do not tell the memory engine how to do any of this. You simply roleplay.

Plug & Play

The entire system was specifically designed to require as little user interaction as possible.

1. Open Scripts Beta on JanitorAI.

2. Create an Advanced script.

3. Paste the complete Janitor Memory Optimizer v1.0.0 script.

4. Save it.

5. Attach it to your character.

6. That's it.

There is no configuration wizard. There are no required commands. There is no debug interface for the roleplayer. There are no manual token budgets to maintain.

The intended experience is: install once, then forget the memory engine exists.

100% Passive Natural-Language Memory

The optimizer observes ordinary conversation and evaluates information automatically.

Explicit natural-language requests can also strengthen or remove memories:

Remember that Nadia is my sister.
Don't forget that the archive key belongs to Samira.
Forget everything about Nadia.
Forget what I said about the brass key.

These are normal sentences, not commands.

The script does not answer with messages such as "Memory saved" or "Memory deleted." The character simply continues the roleplay.

Ordinary narrative changes are treated differently from forgetting. For example:

I no longer trust Nadia.

does not erase the past. The optimizer can preserve the previous relationship state as history and track the newer state as a change.

No Chat Injection

This is one of the most important design rules of the entire project.

The conversation itself is read-only.

The script may read available conversation surfaces such as:

• context.chat.last_message

• context.chat.last_messages

• context.chat.message_count

It does not add synthetic user messages, assistant messages or system messages.

It does not use:

• script_output for memory;

• example_dialogs for memory;

• fake conversation entries;

• hidden pseudo-chat commands.

The only active memory surface visible to the LLM is:

context.character.scenario

The private runtime vault under context.chat.jai_memory_optimizer_v10 is technical state, not a conversation message.

How the Memory Engine Works

Internally, Janitor Memory Optimizer uses several progressively more abstract layers:

Chat read-only → Atomic Facts → Hashed Shards → Semantic Dossiers → Temporal Graph → Entity Intelligence → Episodic Memory → Narrative Threads → Hierarchical Recall → Scenario

1. Atomic Facts

Important information is first retained as traceable atomic facts. A fact can carry information such as its type, source, importance, turn, relevance hits, associated entities and evidence ID.

These atomic memories remain the closest thing to a source of truth inside the engine. Higher-level summaries do not silently replace them.

2. Content-Addressed Hashed Vault

Facts are organized into topic-oriented shards stored in private runtime state.

Shards use content hashes so unchanged memory can be reused instead of constantly rewritten.

The hashes are addresses and integrity checks, not encryption.

3. Semantic Dossiers

Related memories are grouped into derived semantic profiles.

A dossier can distinguish:

• stable information;

• current information;

• historical information.

This allows the model to receive a useful overview of a person or topic without receiving every individual memory at once.

4. Temporal Memory Graph

The optimizer can build relationships between people, places, objects, quests and events.

Temporal edges deliberately distinguish:

• causes — only when the source explicitly supports causality;

• precedes — chronological order without claiming causation;

• supersedes — a newer state replacing or contradicting an older one.

In other words, the engine does not assume that because Event B happened after Event A, Event A caused Event B.

5. Entity Intelligence

The engine performs conservative entity resolution for:

• explicit aliases;

• nicknames;

• some full-name / family-name relations;

• unambiguous short-window pronouns;

• some unambiguous relationship references such as "my sister."

When a reference is ambiguous, the optimizer prefers not to merge identities rather than confidently inventing the wrong connection.

6. Adaptive Memory Temperature

Memories are dynamically treated as hot, warm or cold.

Temperature is influenced by more than age. The engine considers observed usefulness, importance, recency, stability and repeated relevance.

An old memory that repeatedly becomes useful can remain important. A cold memory is not automatically considered false and is not erased simply for being cold; it is primarily deprioritized.

7. Episodic Consolidation

Older clusters of related events can become compact episodic memories.

Instead of permanently carrying ten detailed events in active recall, the optimizer may preserve an extractive episode containing the key beats of what happened.

The underlying atomic evidence can remain attached to that episode, allowing later drill-down when exact details are required.

8. Narrative Threads

Multiple episodes can themselves become long-running narrative arcs.

Supported thread families include:

• entity:*

• relationship:*

• quest:*

• location:*

• mystery:*

• conflict:*

• topic:*

A single episode can participate in several narrative threads without duplicating its original evidence.

This means a scene involving Nadia, an archive mystery and the Silver Thread quest can contribute to all three story arcs while remaining one underlying piece of history.

9. Hierarchical Recall

The optimizer tries to answer memory needs using the cheapest useful layer.

A broad question may only require a Narrative Thread.

A more precise question may automatically descend through:

Thread → Episode → Atomic Evidence

This helps preserve detail without forcing every detail into every prompt.

Reversible Recovery: JMO10 Escrow

The Scenario also carries a bounded recovery checkpoint.

The recovery layer uses:

compact serialization → LZW12 → Base64 → checksum

If the private runtime state disappears while the previous Scenario checkpoint remains available, the optimizer can rebuild memory from that checkpoint.

Conceptually:

Scenario → JMO10 Escrow → Atomic Facts / Archived Episodes → Semantic Dossiers → Temporal Graph → Narrative Threads

Corrupt escrow data is rejected rather than converted into fabricated memory.

JMO10 can also read older JMO3–JMO9 escrow formats for migration and recovery.

Automatic Context Management

The objective is not to dump the entire memory vault into every generation.

Storage and recall are deliberately separated.

The engine automatically adjusts recall and recovery budgets based on available room and the kind of information currently required.

A simple continuation needs less memory than a detailed question about causality, chronology or a relationship spanning hundreds of messages.

If necessary, the optimizer reduces detail before overflowing its internal working envelope.

Internal Guardrails

These are project heuristics, not claimed official JanitorAI limits.

• Estimated combined Personality + Scenario soft cap: 4,000 tokens

• Maximum topic shards: 512

• Temporal graph: 384 nodes / 768 edges

• Episodic archives: 160

• Narrative threads: 192

• Recall and escrow budgets: automatically adaptive

These exist to keep the memory system bounded and predictable rather than allowing uncontrolled growth.

Long-Roleplay Safety & Memory Hygiene

The engine includes several conservative safeguards developed throughout the project:

• exact duplicate consolidation;

• near-duplicate synthesis where appropriate;

• current-state replacement without blindly destroying useful history;

• question filtering so questions do not automatically become established facts;

• conservative causality detection;

• ambiguity-aware entity resolution;

• targeted natural-language forgetting;

• corrupt recovery checkpoint rejection;

• relevance-aware historical recall;

• filler isolation so a generic "Okay." does not drag unrelated archives into context;

• preservation of atomic evidence behind higher-level summaries;

• bounded memory and graph pruning;

• automatic migration of older optimizer states when available.

Designed for Long-Running Roleplay

Janitor Memory Optimizer is particularly useful for roleplays involving:

• slow-burn relationships;

• multi-character casts;

• mysteries and investigations;

• quests and objectives;

• changing alliances;

• long-running conflicts;

• persistent inventories or important objects;

• recurring locations;

• character development;

• stories spanning hundreds or thousands of turns.

Validation & Stress Testing

v1.0.0 was not released after a simple syntax check. It went through dedicated regression, hardening, recovery and long-horizon stress suites.

Static / Creator Pack Validation

• Node syntax check: PASS

• Conservative ES5 validator: PASS

• Errors: 0

• Warnings: 0

• Runtime size: 191,418 / 400,000 bytes

Output-Surface Invariant Tests

• No script_output: PASS

• No chat-history writes: PASS

• last_message remains unchanged: PASS

• message_count remains unchanged: PASS

• No memory writes to example_dialogs: PASS

• No active memory block added to Personality: PASS

• Exactly one LLM-visible memory destination — Scenario: PASS

• No user command syntax required or exposed: PASS

Regression Suite

21 targeted assertions: PASS

Coverage included:

• 109-turn scenario;

• episodic consolidation;

• narrative threads;

• broad thread recall;

• exact/history drill-down;

• filler isolation;

• state-loss recovery;

• older-version migration compatibility.

Final Hardening Suite

23 additional assertions: PASS

This suite specifically covered:

• Scenario-only architecture;

• v0.9 live-state migration to v1.0;

• legacy JMO9 escrow recovery;

• atomic evidence surviving legacy recovery;

• safe rejection of corrupted escrow;

• targeted natural-language forgetting;

• preservation of unrelated semantic memories during targeted forgetting.

500-Turn Stress Test

Test corpus:

500 population turns + 60 natural-language memory queries + 3 complete private-state loss recoveries.

• Facts before recovery: 42

• Facts after 3 recoveries: 42

• Episodes before / after: 10 / 10

• Narrative Threads before / after: 5 / 5

• Complete state-loss recoveries: 3 / 3 PASS

2,000-Turn Long-Horizon Stress Test

A much larger test was also run:

2,000 population turns + 60 natural queries + 3 complete state-loss recoveries.

• Facts before / after recovery: 61 / 61

• Episodes before / after: 40 / 40

• Narrative Threads before / after: 5 / 5

• Complete state-loss recoveries: 3 / 3 PASS

• Thread builds: 195

• Thread signature reuses: 1,927

• Graph builds: 201

• Graph reuses: 1,860

This demonstrates that the derived structures are heavily reused rather than blindly rebuilt on every turn.

Performance Optimization

On the same local 500+60 Node harness:

• v0.9 baseline: approximately 6.49 seconds

• v1.0 optimized: approximately 3.87 seconds

• Relative reduction: approximately 39%

This benchmark measures the script in a local Node VM test harness. It is a relative regression/performance measurement for the script itself, not a claim about JanitorAI server latency.

Compatibility & Migration

v1.0.0 writes the current JMO10 recovery format.

It can read legacy JMO3 through JMO9 escrow checkpoints.

Migration from previous Janitor Memory Optimizer states is supported when the necessary older state is still available.

For a fresh installation, simply use v1.0.0.

Vibe-Coded with ChatGPT 5.6

Yes, this project was vibe-coded with ChatGPT 5.6.

The engine was developed iteratively through human-directed design, testing, debugging, stress testing and repeated architectural revisions with ChatGPT 5.6 assisting with the code.

It evolved through multiple prototypes: from a basic selective-memory injector into a content-addressed vault, reversible recovery system, semantic memory hierarchy, temporal graph, entity resolver, episodic archive and narrative-thread engine.

The final release was then subjected to automated regression and stress suites rather than being published simply because the generated code "looked right."

This is an independent community project. It is not an official OpenAI or JanitorAI product, and mentioning ChatGPT 5.6 describes the development process rather than an official certification or endorsement.

Why Use It?

Because memory should not become another game mechanic the roleplayer has to manage.

You should not have to pause a scene to type:

/save_memory relationship Nadia trust -1

You should just be able to write:

After what Nadia did, I don't think I can trust her anymore.

and continue the story.

That is the design philosophy behind Janitor Memory Optimizer.

Memory processing should happen in the background. The chat should remain a chat. The character definitions should carry the working memory. The LLM should receive the smallest useful amount of context for the current moment.

In Short

• Plug & play.

• Fully passive.

• No commands.

• No memory UI.

• No fake chat messages.

• Scenario-only LLM-visible memory.

• Natural-language remember / forget.

• Atomic evidence.

• Hashed memory vault.

• Semantic dossiers.

• Temporal and causal graph.

• Conservative entity intelligence.

• Adaptive hot / warm / cold memory.

• Episodic long-term consolidation.

• Persistent narrative threads.

• Hierarchical recall with evidence drill-down.

• Reversible JMO10 recovery escrow.

• Legacy recovery support.

• Automatic context budgeting.

• 2,000+ turn stress-tested.

• 3/3 complete state-loss recoveries in both major stress suites.

• 0 ES5 validation errors.

• 0 ES5 validation warnings.

Paste it. Attach it. Roleplay normally.
Let the character remember.