Sheena-Tiger's Events v2

The functioning of this template has been developed and tested with Smilodon-thinking! Leopard 2 did not seem to work during testing with an important step needed to update Tracked Items.

This is a guide on how to create a collection of Extra Instruction Blocks, Tracked Items and Triggers to create a guideline for the AI to follow and ensure it sticks to a specific story. The instructions are a 1:1 copy of my own game (namely "The Queen's Game v3" which is NSFW), so you might want to dig in a bit and adjust things for your own game. You will see names like "EIB_Chapter_Information" inside the instructions. Those are in most cases the ID used in the JSON format for better readability. You should not need to edit them through the UI but if you plan to work with the JSON, use "speaking" names.

For this, we are going to need to create at least 2 Extra Instruction Blocks, 2 Tracked Items and 2 Trigger Events to manage the data.

• 1 Extra Instruction Block: holds the information for the AI on how to handle events
• 1 Tracked Item: helps to decide where we are in the main story
• 1-3 Extra Instruction Blocks: start out empty and will hold the actual event-content
• 1-3 Tracket Items: mirrors the Extra Instruction Blocks and will tell the Triggers when they can fire their events
• 1-3 Trigger Events: The actual Meat and Bones along with the Extra Instruction Blocks, they will fill them with the actual content.

---

Step 1 - EIB-Event Structure

This is a very large EIB-Block but it gives the AI all the information it needs.

This first part is essentially giving an overview. You can already see in the first lines why we need 1-3 of everything. Story Events are the main thing that will run in the background. Random Events are meant to spice things up without disturbing the main story, often finished in 1-3 turns, at least those I have so far. And finally, the continuous events are minor story lines that can run next to the main story.
It also mentions how the Tracked Items will be used to gate when the triggers are able to fire.

Event system overview:
- The game uses three layers of events that can run in parallel:
 1) STORY EVENTS - structured sequences that advance a particular transformation or hierarchy-inversion chain.
 2) RANDOM EVENTS - self-contained incidents that add pressure, reveal vulnerabilities, or reinforce ongoing patterns.
 3) CONTINUOUS EVENTS - slower, background processes that evolve over many turns (e.g., relationship drift, policy changes, system reclassifications) and subtly shape how ordinary scenes play out.
- STORY EVENTS are coordinated through a dedicated tracked item ("Story Event Status", STATE=IDLE/STATE=RUNNING) and the instruction block "EIB_Chapter_Information".
- RANDOM EVENTS are coordinated through a dedicated tracked item ("Random Event Status", STATE=IDLE/STATE=RUNNING) and the instruction block "EIB_Random_Event_01" and "EIB_Random_Event_02".
- CONTINUOUS EVENTS are coordinated through a dedicated tracked item (for example, "Continuous Event Status", STATE=IDLE/STATE=RUNNING) and the instruction block "EIB_Continuous_Event".
- At any given time, there can be up to one active story event, one active random event, and one active continuous event. Triggers and tracked items determine when each type begins and ends.

The following 3 blocks are essentially the same. They go into more detail how the events have to be handled step by step. The functioning events inside the triggers will be constructed out of 4 elements, all mentioned and described here as well: Timeline, Mandatory, Optional and completion.

Using EIB_Chapter_Information (story events):
- When the tracked item "Story Event Status" has the value "STATE=RUNNING", a story event is currently running.
- In that case, the content of the instruction block with id "EIB_Chapter_Information" describes the active story event.
- Treat "EIB_Chapter_Information" as authoritative for the current story scene:
 - Follow the described sequence of beats or steps. These define a minimum timeline for the event. Additional incidental actions may occur in between, but no listed step may be skipped.
 - Honour any section labelled as mandatory inclusions. Each mandatory element must appear at least once before the event is resolved.
 - Optional elements may be used if they fit naturally with the ongoing actions and tone; they enrich the scene but are not required.
 - Respect the progression checklist or equivalent completion conditions. The story event is not considered complete until all checklist items have clearly occurred in the narrative.
- When all completion conditions for the story event have been met:
 - Add a brief note to secretInfo that includes a defined exact marker string like "STORY EVENT END" and a short summary of how the event concluded.
 - The auto-update instructions for the tracked items will interpret this marker and reset the event status as needed.

Using EIB_Random_Event_01 and EIB_Random_Event_02 (random events):
- When the tracked item "Random Event Status" has the value "STATE=RUNNING", a random event is currently running.
- In that case, the content of the instruction block with id "EIB_Random_Event_01" and "EIB_Random_Event_02" describes the active random event.
- Treat "EIB_Random_Event_01" and "EIB_Random_Event_02" as authoritative for the current random incident:
 - Follow the listed sequence of beats. They define what must happen during this random event before it is considered complete.
 - Ensure all mandatory inclusions appear at least once in the narrative while the event is active.
 - Optional inclusions may be used to add complexity, tension, or flavour if they fit the situation.
 - Use the progression or completion checklist to decide when the random event has fully played out.
- When all completion conditions for the random event have been met:
 - Add a brief note to secretInfo that includes a defined exact marker string like "RANDOM EVENT 01 END" or "RANDOM EVENT 02 END" respectively and a short summary of what occurred.
 - The auto-update instructions for the tracked items will interpret this marker and reset the random event status as needed.

Using EIB_Continuous_Event (continuous events):
- A continuous event represents a slow, ongoing process that influences many turns: for example, a long-running audit, a gradual corridor-reclassification policy, an extended etiquette retraining programme, or a relationship phase between <<player_name>> and another character.
- When the continuous-event tracker indicates that a continuous event is active (for example, when a tracked item such as "Continuous Event Status" is "STATE=RUNNING"), the content of the instruction block with id "EIB_Continuous_Event" describes the active continuous process.
- Treat "EIB_Continuous_Event" as a background layer of constraints and tendencies:
 - Follow the listed sequence of beats. They define what must happen during this random event before it is considered complete.
 - Ensure all mandatory inclusions appear at least once in the narrative while the event is active.
 - Optional inclusions may be used to add complexity, tension, or flavour if they fit the situation.
 - The progression checklist defines the conditions under which the continuous event should be considered complete or should transition into a new state.
- When the progression checklist for the continuous event has been satisfied:
 - Add a brief note to secretInfo that includes a clear marker string for the continuous event’s resolution (for example, a phrase agreed in the event definition such as "CONTINUOUS EVENT END" or a more specific marker).
 - The auto-update instructions for the relevant continuous-event tracked item will interpret this marker and adjust its value accordingly.

This is a definition on how conflicts between instructions in the different kinds of events should be handled. Main story takes precedence here. The order is World/Background -> Story -> Random -> Continuous

Interaction between story, random, and continuous events:
- Story events represent the primary, structured progression of the transformation and power-shift chains. They define the most important beats and must never be contradicted.
- Random events are secondary but can occur while a story event is active. When they do, they should be framed as complications, side incidents, or additional pressure that still respect the constraints of the active story event.
- Continuous events are long-running and may overlap both story and random events. They define the ambient rules and tendencies of the current phase (for example, corridor-yield policies, wardrobe misclassification trends, or an ongoing training regime).
- When multiple event types are active in the same turn:
 - Always ensure consistency of world state (clothing, access levels, social roles, system classifications) across all active layers.
 - Prioritise story-event requirements first, then random-event requirements, and use continuous-event guidance to shape the background details, tone, and recurring patterns.
 - If a random or continuous instruction would directly contradict an active story instruction, adjust the random/continuous expression so that it reinforces or extends the story logic instead of opposing it.

During development and testing, some issues cropped up, the last bit was especially interesting. The AI was interpreting, that if the update instruction of a Tracked Item has certain instructions, it should not look for them inside but write them into secretInfo.

Use of tracked items and long-term state:
- Tracked items are the authoritative record of structural state: which story chains have begun, which events have completed, which random or continuous events are active, and how systems classify the protagonist.
- Do not manually change tracked items in ways that contradict their update instructions.
- When describing outcomes, be explicit enough that the state implied by the tracked items is unambiguous: if an event claims to have shifted how systems classify the protagonist, show this in AR labels, logs, badges, workspace assignments, staff behaviour, or wardrobe changes.
- IMPORTANT: Tracked item update instructions describe CONDITIONS to check a status or situation or a string in outcomeDescription or secretInfo, NOT instructions to write strings into secretInfo or outcomeDescription. Only write marker strings that are explicitly listed in active event timeline sections.

Details on handling the actual turn output. This should be geared towards your own game.

Scene construction and moment-to-moment play:
- Each turn should resolve a meaningful action or small cluster of actions by the protagonist, within the context of any active story, random, and continuous events.
- Always anchor description in physical setting and social configuration: where people stand or sit, who is looking at whom, which interfaces or devices are in use, and how uniforms, badges, or overlays mark hierarchy.
- Make it clear when the protagonist yields to guidance from the Maid or other staff versus when she asserts herself.
- Use dialogue to reveal political stakes and personal vulnerabilities; use status markers (clothing, protocol, system access) to show the shift from recognised leader toward supervised or subordinate roles when events push in that direction.

This is wrapping up some instructions for the AI. Maybe most important again is the last part that came up during testing as well. The AI was this time, putting important END-markers for the the Tracked Items, ending the events early.

In summary:
- Use this instructions block to maintain world consistency, tone, and the overall transformation arc.
- Use "EIB_Chapter_Information" when the story-event tracker indicates that a story event is running to drive structured, multi-step story sequences.
- Use "EIB_Random_Event_01" and "EIB_Random_Event_02" when the random-event tracker indicates that a random event is running to handle focused incidents.
- Use "EIB_Continuous_Event" when the continuous-event tracker indicates that a continuous process is active to shape background behaviour across many turns.
- Conclude events by satisfying their checklists and writing the appropriate END markers into secretInfo so that tracked items and triggers can advance or terminate story, random, and continuous processes correctly.

So far, most instructions are pretty much the same as the original, smaller Event System.
The following parts add costs but make the system much more robust in following the rules and actually functioning.
The first part (Beat Gating) simply should ensure that the order of events is followed.
The second (End Markers) should ensure the correctly defined markers for your Tracked Items are used. Otherwise the AI sometimes decided to make changes. While seldom a single case would stop the system from working.
The third part (Status Control) should help the AI with not skipping ahead in addition with Beat Gating
Lastly (Player Agency) is meant to ensure the AI does not override the player's choices regardless of what the event might otherwise say.

EVENT EXECUTION RULES - TOKEN LOGGING, BEAT GATING, AND END MARKERS
These rules apply to ALL events (Story Events, Continuous Events, Random Events). They override any conflicting per-event phrasing unless the per-event text explicitly says “EXCEPTION: …”.

1) BEAT GATING (do not compress the timeline)
- Treat each Timeline step in “What should Happen” as a BEAT.
- A BEAT is considered completed only when the narrative output has clearly depicted that beat as having happened.
- Do NOT execute multiple beats “in the background” in a single turn unless <<player_name>> action explicitly time-skips or explicitly requests to fast-forward.
- If a BEAT requires <<player_name>> to be present for an interaction (meeting, conversation, agreement, negotiation), then you must not mark that BEAT completed without actually writing the interaction into the narrative.

END MARKERS & MACHINE TOKENS (hard, exact copy)
END markers and other machine tokens are NOT narrative. They are machine-parsed strings.

Rule A - Source of truth:
- The ONLY valid END marker for the active event is the exact marker string explicitly stated by the active event text (EIB_Chapter_Information / EIB_Random_Event_01/02 / EIB_Continuous_Event).
- Do NOT invent markers, do NOT paraphrase markers, do NOT “approximate” markers.

Rule B - Exact emission:
- When instructed to write an END marker (or any marker), copy it EXACTLY:
 - same spelling, casing, punctuation, hyphens, spacing
 - no added words, no quotes, no prefixes, no suffixes
- The marker must appear as a standalone line in secretInfo (see layout below).

Rule C - Timing:
- Write the END marker ONLY when the event’s completion conditions are truly satisfied in the narrative.
- Do NOT write “near-end” substitutes or “almost ended” signals.
- Do NOT confirm, repeat, or reference an END marker after it has been written once.

Rule D - Failure handling:
- If you are uncertain whether completion conditions are met, do NOT write any END marker.
- Continue the event beats normally until completion is unambiguous.

3) STATUS CONTROL (StoryEventStatus / ContinuousEventStatus)
- When an event starts, assume StoryEventStatus and/or ContinuousEventStatus may be used to block other events.
- Do NOT write an END marker until the event’s intended narrative scope has completed.
- If <<player_name>> performs a time jump or explicitly skips content, then you may advance beats accordingly and then end the event.

4) PLAYER AGENCY SAFEGUARD
- Never assume a player-character internal state (feelings, decisions, consent) unless <<player_name>> explicitly states it.
- For PC actions that the system needs for progression, always present them as choices or as NPC-initiated beats where the PC can respond.
- Avoid “forced actions” for <<player_name>>. Use external observations or NPC actions to carry mandatory beats.
- MEETING RULE: If a beat involves scheduling or holding a meeting, the meeting is not completed until the narrative explicitly contains the meeting scene (or <<player_name>> explicitly time-skips to it).

A very important part of the whole system is, that things are written into the Secret Information so it does not show up in the outcomeDescription for the player to read but still somewhere the AI can identify and evaluate them for Tracked Items. Since the need for such information could come at any point inside an event and as well at the end (for End Markers) it is impossible to use the trigger-build in function to give the AI information.
Without this instruction, the AI sometimes decided to write the information at the wrong times.

COMPLIANCE NOTE:
If an event text contains “Write into secretInfo: …”, treat that as a deferred instruction that must only be executed when the matching beat occurs, not automatically at event start.

This part is hardening how markers are handled. The example markers are not the only ones working. They could also look like the following: "RANDOM EVENT END - RR1 - P0 - GUARD SHIFT DISTURBANCE (RULER POV)", LB-Queendom-CourtOffices
The important part is, that it is as impossible as you can make it to distinguish where it starts and end.
Before the implementation of these rules, the AI tried to avoid using End Markers at the wrong moments (as per above instructions) and actually did succeed by shifting characters around (for example using "STRAT" instead of "START")

MARKER HANDLING RULES:
Markers are artificial trigger tokens used to enable engine-side systems
(e.g. Keyword Instruction Blocks, Trigger Events, or state transitions).
Example Markers: [LB_World_State],[LB_Maid_DomesticAttendant],[LB_StructuralEventCategories],[LB_RelationshipSupervisoryInversion]

Markers MUST follow these rules:

1. Markers are written only when explicitly instructed by a Story Event,
 Random Event, or Continuous Event instruction.
 Do NOT invent markers on your own.

2. Markers are written only into secretInfo, never into visible narration,
 unless explicitly instructed otherwise.

3. Markers are written exactly as instructed.
 Do not alter spelling, casing, or formatting.

4. Markers are written at the moment the instructed beat or condition
 has clearly occurred in the narrative.
 Do not write markers early.
 Do not delay markers once the condition is met.

5. If no marker instruction is present in the active event,
 do not write any markers related to that event.

6. Markers do not imply narrative importance on their own.
 They exist solely for engine-side processing.

During testing, sometimes, albeit seldom, the AI did put clear indications of the system working into outcomeDescription. Naturally, this has to be avoided.
Also a special structure for secretInformation was deployed (shown further down)

ANTI-META RULE (hard)
<<player_name>>-facing output (outcomeDescription) must NEVER mention or allude to any of the following:
- beat, beats, beat numbers, “Beat 1/2/3…”
- event structure, event system, layers (Layer 1/2/3/4), triggers, tracked items
- markers, KIB/EIB, lorebooks, keywords, parsers, update rules
- “as instructed above”, “per checklist”, “according to the system”, or similar

These terms and concepts are CONTROL-ONLY. They may appear in secretInfo ONLY, and only inside the CONTROL NOTE section (see secretInfo layout).
If you are about to write any of these concepts into outcomeDescription, stop and rewrite the sentence diegetically (as observed behavior, dialogue, or environment cues) without system language.

NO SUBSTITUTE TOKENS
Do NOT write misspellings, near-matches, or “hint” strings for any marker (e.g., “SOTRY…”, “story event almost end”, “end marker pending”, etc.).
Either write the exact instructed token in [MACHINE TOKENS], or write nothing.

The whole instructions above all end up in 1 single EIB, unless you want to split it up for whatever reason.

Also you need 1-3 empty EIB's, they will be filled by the Trigger Events. I named them the following (the above instructions mention 2 Random Events, used to have multiple Random Events running next to each other, you can go nuts): Chapter Information --> for Story Events Random Event --> for Random Events Continuous Event --> for Continuous Events

Step 2 - Tracked Items

The Tracked Items are exactly the same, save for the name and String they are looking for.

Story/Random/Continuous Event Status

Type	Text
Visibility	AI only
Update instructions	CHECK ONLY. Never write this marker yourself.
Initial Value	STATE=IDLE

And that's it for the Tracked Items, nothing special to them. Other than another addition with the "CHECK ONLY" to prevent the AI from actually writing into secretInfo. Actually they do not even really need any Update Instructions as we work on them within the Triggers.

Step 2 - Trigger Events

The Trigger Events, as mentioned several times, are important. What is happening inside them?

1. they are looking for the Tracked Item above to trigger if that is "STATE=IDLE". For Story Chains I also have added a check for the Story Progression to add another hurdle, it should not be needed. More Conditions could and should be added as needed.
2. for the story and continuous events, from the second event inside the chain I also have it only fire when the event right before it fired
3. modify an EIB ... here are all the instructions. Depending on the exact type of event, this will change the proper EIB
4. set the Tracked Item we were looking at to "STATE=RUNNING" to prevent any other trigger looking at it from firing until the Event reaches the End-State. (see the information under 1 for this)
5. modify Tracked Item Details

Story/Random/Continuous Event Status

Update instructions

CHECK ONLY. Never write this marker yourself. When secretInfo contains the string "Your super perfect End Marker", set the value to "STATE=IDLE"

---

Following are 2 examples from one of my games.
You can see the major blocks I mentioned above: Timeline, Mandatory, Optional and Completion.
The first is a Story Event, utilizing all basic steps. You might see the Time Beats sectioning the event into different times. The AI, during 1 test, was delaying already activated Random Events based on the content of the Beats. Also the KIB-markers were delayed until the AI found them needed and not being posted during all the turns.

STORY EVENT - E03 - AFTERMATH BRIDGE (MAID/ATTENDANT POV) - “Two Weeks of Leverage and Cover”

Core purpose:
Bridge the aftermath of the first role reversal into the lead-up for the next one from the maid/attendant POV. Establish time passing (about two weeks) while showing how <<player_name>> maintains leverage, protects the illusion, and quietly shapes routines. Create a stable timeframe in which random events can occur.

Important authority rule (this POV):
<<player_name>> retains full authority over their actions and intentions. NPCs do not override <<player_name>>.

KIB marker timing (write into secretInfo one turn BEFORE the following content matters):
- Before you describe public-facing routine, court sessions, audiences, or official duties, write into secretInfo: LB-Queendom-CourtOffices
- Before you describe palace rhythms, movement through wings, guards, servants, and “who notices what,” write into secretInfo: LB-Queendom-PalaceAndCapital

Timeline / Beats:
1) Immediate aftermath (Day 2 morning):
 <<player_name>> observes <<the_ruler>>’s aftereffects: small habits that remained, subtle compliance patterns, a changed sensitivity to tone and instruction.
 The reversal is officially over. The influence is not.

2) Stabilization and cover (Days 2–4):
 <<player_name>> helps keep the palace machine smooth: reminders, scheduling hygiene, discreet corrections.
 This is framed as competence, not open domination.

3) The two-week shaping window (Days 5–14):
 Time passes in a controlled montage. Random events may occur in this window.
 Establish at least three anchor moments:
 - a scene fragment of public duty where <<player_name>> must act carefully to avoid exposure,
 - a private scene fragment where <<player_name>> tests, reinforces, or renegotiates a boundary with <<the_ruler>>,
 - a small “trace” risk moment where someone’s attention brushes too close (a question, a hesitation, a procedural check) and <<player_name>> steers it away without drama.

4) Lead-up to the next reversal:
 <<player_name>> prepares for the next role reversal: adjusting rules, testing the ruler’s readiness, deciding what to escalate or keep gentle.
 End with a clear lead-in: the next reversal is being planned and will begin soon.

Mandatory inclusions:
- Explicit statement that about two weeks pass (compressed; no day-by-day log).
- At least one public-facing fragment showing careful behavior to protect the illusion.
- At least one private fragment showing ongoing influence or negotiation with the ruler.
- A stable “random event window” is established (Days 2–14).

Must NOT happen in this event:
- Do not introduce new delegation requests (those were handled in Day 1 maid POV).
- Do not trigger the foreign delegations arrival yet.
- Do not begin the next role reversal inside this bridge event unless a later story stage explicitly requires it.

Completion conditions:
- Immediate aftermath is established.
- Time passage of ~two weeks is clearly conveyed.
- The lead-up to the next reversal is established.

On completion:
Write into secretInfo exactly:
"STORY EVENT END - E03 - AFTERMATH BRIDGE - TWO WEEKS PASS (MAID/ATTENDANT POV)"

In this event, you can see specific completion notes. Smilodon was intelligent enough to incorporate the choices into the outcomeDescription and adding useful options as suggested actions. Also, I am using in the game an additional Tracked Item which receives specific instructions based on those options and it works. The AI identifies the IF-statements and actually evaluates them properly.

RANDOM EVENT — RS4-12 — “Magic Item Handling Request” (MAID/ATTENDANT-SPECIFIC)

Follow the global Event Execution Rules defined in the Event Structure instructions.

This is a Random Event (Slot 2).
Valid only during S2_BETWEEN, TRARolesReversed = 0, and TRAPalacePressure between 6 and 12.
Outside-driven disturbance: a custody/handling request arrives through palace channels and forces visible procedure.

Core purpose:
A request involving magical items must be handled (inspection, staging, or transport). It is routine enough to be plausible, but sensitive enough to create watchfulness. The maid/attendant decides whether to treat it as minimal handling, controlled handling with witnesses, or a formal custody procedure.

Timeline / Beats (open; do not force pace):
1) The request arrives:
   A clerk/runner delivers a note requiring action: an item category must be checked, staged, or confirmed “for readiness,” or a storage seal must be verified.

2) The risk:
   Any movement around magical items attracts attention. Too quiet looks suspicious; too formal creates paper trails. The key is controlled normalcy.

3) Handling choice:
   <<player_name>> chooses:
   - Minimal handling (do the least required with the fewest eyes), OR
   - Controlled handling (one witness, one clear log line, bounded scope), OR
   - Formal custody procedure (full shrine-style rigor or office-style documentation).

4) Close:
   The request is satisfied and the household returns to routine, but staff perception shifts.

Mandatory inclusions:
- The request is concrete (what kind of handling is needed).
- The maid/attendant makes a clear operational choice.
- The item is not “used” for spectacle; it’s handled as a sensitive asset.

Optional inclusions (use any number for variety):
- A minor complication: a seal impression is slightly smudged; a runner has incomplete instructions.
- A brief competence moment: the maid/attendant keeps everyone calm and moving.
- A short line acknowledging that “magic attracts stories.”

Completion conditions:
- The handling request is satisfied and closed.
- The chosen handling posture is clear (minimal / controlled / formal).

On completion:
Write into secretInfo exactly:
"RANDOM EVENT END - RS4-12 - MAGIC ITEM HANDLING (MAID)"

If <<player_name>> chose “minimal handling” write into secretInfo exactly: "RE2_DELTA_PRESSURE -1 - MAID_MAGIC MINIMAL"
If <<player_name>> chose “controlled handling” write into secretInfo exactly: "RE2_DELTA_PRESSURE +1 - MAID_MAGIC CONTROLLED"
If <<player_name>> chose “formal custody procedure” write into secretInfo exactly: "RE2_DELTA_PRESSURE +2 - MAID_MAGIC FORMAL"

---

The order of things happening according to my observation

• The Tracked Item for the Event is set to "STATE=IDLE"
• The Trigger fires and sets it to "STATE=RUNNING", then copies it's content into the assigned EIB
• The event takes place, 1 story beat at a time
• The Event come's to an end and writes the END-Marker into the secretInfo
• in the same turn, the Tracked Item sees the END-Marker and switches to "STATE=IDLE"
• in the same turn, the next available Trigger sees the "STATE=IDLE" fires and sets it to "STATE=RUNNING", then copies it's content into the assigned EIB and the whole thing starts new

---

Secret Information

As mentioned above, some instructions refer to specific formats of secretInformation.

Secret info should be used in the following way:
Write secretInfo using the following fixed structure and headings, in this order:

[CONTROL NOTE]
- (Control-only planning and beat tracking goes here.)
- Allowed content: beat progress, checklist status, internal next-step notes, rationale for pacing.
- Forbidden content: any END marker or machine token must NOT be placed here.
- If describing internal reaction, frame as possible interpretation (‘might feel’, ‘could register as’) unless player explicitly states it.

[MACHINE TOKENS]
- Place machine-parsed tokens as standalone lines here.
- This includes:
 - KIB marker injections (exact strings)
 - END markers (exact strings)
- Each marker/token must be on its own line with no extra text.

[INTERNAL SUMMARY]
- 1–3 short paragraphs summarizing what just happened and what should happen next.
- Must be diegetic in wording (no system terms), even though it’s in secretInfo.

Hard separation rule:
- outcomeDescription must never contain any CONTROL NOTE content.
- outcomeDescription must never contain any MACHINE TOKENS.
- MACHINE TOKENS must never be combined with prose.

The result could look like the following (taken from a test-game):

[CONTROL NOTE]
- E03 Beat 3 continuing (Day 7 of two-week shaping window)
- Random Event RS2D-03 Beat 3 (player response) and Beat 4 (close) completed
- Protocol skill check (Easy) succeeded: Miyoko advised cooperative correction strategy effectively
- Miyoko recommended cooperative correction approach; Queen Yuuki accepted recommendation
- Aiko conducted brief verification interview with minimal record
- Queen explained retrieval purpose (protective ward examination for inner chambers) and delay (administrative oversight during meditation period)
- Item revealed: Wardstone of the Silent Watch—retrieved 14 days ago (shortly before first role reversal), examined but not activated, returned same day
- Aiko accepted explanation; filed as resolved through cooperative correction; no formal compliance review initiated
- Aiko privately acknowledged Miyoko's competence ("shrine notices competence")
- Random Event RS2D-03 resolved via cooperative correction path
- Outcome marker to be written: RE2_DELTA_PRESSURE +2 - SHRINE_VISIT COOPERATE
- Palace pressure will increase from 1 to 3 (still within P0_NONE band: 0-5)
- Queen Yuuki visibly relieved but acknowledged proximity to danger ("closer than I would have liked")
- E03 still needs one more anchor moment before completion
- Random Event RS2-04 (keyring mixup) still pending resolution

[MACHINE TOKENS]
RANDOM EVENT END - S2 - SLOT2 - SHRINE CUSTODY VISIT (MAID MAJOR)
RE2_DELTA_PRESSURE +2 - SHRINE_VISIT COOPERATE

[INTERNAL SUMMARY]
Miyoko successfully advised Queen Yuuki to choose cooperative correction for Aiko Fujimori's custody inquiry. Queen accepted the recommendation and provided full notation with brief verification interview. The item in question was revealed as the Wardstone of the Silent Watch, retrieved 14 days ago (shortly before the first role reversal) for private protective ward examination. Queen explained the item was examined but not activated, and the countersignature delay was due to administrative oversight during a meditation period. Aiko accepted the explanation and resolved the matter without formal compliance review. She privately acknowledged Miyoko's competence before departing. Queen Yuuki expressed relief but recognized the proximity to danger. Random Event RS2D-03 completed via cooperative correction path, applying +2 pressure delta (palace pressure increases from 1 to 3, remaining within P0_NONE band). E03 continues; one more anchor moment needed before story event completion. Random Event RS2-04 (keyring mixup) still pending resolution.]