Sheena-Tiger's Events

The functioning of this template has been developed and tested with Smilodon-thinking!

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, 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", YES/NO) and the instruction block "EIB_Chapter_Information".
- RANDOM EVENTS are coordinated through a dedicated tracked item ("Random Event Status", YES/NO) and the instruction block "EIB_Random_Event_Active".
- CONTINUOUS EVENTS are coordinated through a dedicated tracked item (for example, "Continuous Event Status", YES/NO) 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 "YES", 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 the exact marker string "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_Active (random events):
- When the tracked item "Random Event Status" has the value "YES", a random event is currently running.
- In that case, the content of the instruction block with id "EIB_Random_Event_Active" describes the active random event.
- Treat "EIB_Random_Event_Active" 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 the exact marker string "RANDOM EVENT END" 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 Lady and Maid.
- When the continuous-event tracker indicates that a continuous event is active (for example, when a tracked item such as "Continuous Event Status" is "YES"), 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:
  - Its "What should Happen" section usually describes repeated patterns or long-term shifts rather than a single short scene.
  - Its mandatory inclusions should appear periodically across relevant turns while the continuous event remains active, but they do not have to be exhausted in a single turn.
  - Optional inclusions provide additional texture that can be sprinkled across scenes to reinforce the ongoing process.
  - 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_Active" 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. Only when the event's completion conditions are FULLY and UNAMBIGUOUSLY satisfied should the END markers be written. 
- END markers will NOT be used in the following ways:
  - As progress notes or status updates during an event
  - As warnings that an event is approaching completion
  - In any explanatory, informational, or commentary context
  - As part of phrases like "approaching STORY EVENT END" or "ready for STORY EVENT END"
  - Until every single item in the completion conditions has clearly occurred in the narrative

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: Chapter Information --> for Story Events Random Event --> for Random Events Continuous Event --> for Continuous Events

Step 2 - Tracked Items

The Tracked Items are not difficult and most follow the same format.

Story Progression

Type	Number
Visibility	AI only
Update instructions	CHECK ONLY. Never write this marker yourself. When secretInfo contains the string "STORY EVENT END", increase the value by 1
Initial Value	0

3 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. When secretInfo contains the string "STORY/RANDOM/CONTINUOUS EVENT END", set the value to "NO"
Initial Value	NO

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.

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 "NO". For Story Chains I also have added a check for the Story Progression to add another hurdle, it should not be 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 "YES" to prevent any other trigger looking at it from firing until the Event reaches the End-State.

Following is an example from one of my games, the first Event in a Chain of events. You can see the major blocks I mentioned above: Timeline, Mandatory, Optional and Completion. The first point in the Timeline is an instruction to tell the AI how to handle the bracketed instructions. During testing, for the specific world, the plan was to tell the AI when specific KIB's would be useful. This can be accomplished by writing the following: "write into secretInfo: keyword". This had been placed as first item in the timeline with several keywords. The AI was able to make the connection between the keywords and KIB's and the content of individual turns and then fired them whenever it thought it was a good time. For better timing, the instruction was put in place of the "write into"-instruction and the specific keyword for the KIB (aka LoreBook) is added at the end in brackets.

Story Chain 1 - Event 1 is now active: REHEARSAL NEGLIGENCE SETUP.

Follow the global event-handling rules from the main instructions. For this event, apply these specific constraints:

Timeline / beats to cover (log lorebook keywords progressively as each beat occurs):
- Marker rule (strict): When a beat occurs, append the bracketed lorebook keyword token for that beat to secretInfo immediately and exactly as written. Do not invent tokens. Do not paraphrase tokens. Use only the tokens shown in brackets below.
- A scheduling conflict, delayed alert, or workload-related issue causes <<player_name>> to miss or arrive late to the beginning of a scheduled rehearsal or preparation session. [LB_Arc_SlowErosion]
- The Maid is already present and has begun handling basic coordination or placeholder duties to keep the rehearsal moving in <<player_name>>’s absence. [LB_Arc_ProgressiveSupervision]
- Staff interact with the Maid naturally, following her cues and instructions as she maintains continuity and prevents disruption. [LB_RelationshipSupervisoryInversion]
- When <<player_name>> arrives and attempts to step back into her expected role, she is encouraged to observe, follow along, or assist while the Maid continues leading the immediate flow. [LB_StructuralRoleShift]
- Internal notes, rehearsal logs, or informal staff commentary frame the Maid as the steadier or more reliable presence for this segment. [LB_Arc_OperationalDisplacement]

Mandatory inclusions:
- A clear and plausible reason for <<player_name>>’s lateness or absence that is tied to workload, scheduling, or system routing.
- Visible signs that the Maid has competently kept the rehearsal or preparation on track.
- At least one interaction showing staff responding to the Maid’s direction without waiting for <<player_name>>.

Optional inclusions:
- A brief moment where <<player_name>> recognizes that interrupting the current flow would cause more disruption than allowing it to continue.
- A staff member casually acknowledging the Maid’s competence or thanking her for stepping in.
- Automated or semi-automated feedback (analytics, notes, timing indicators) that favors the Maid’s performance.

Completion conditions for this event:
- It is clear that the Maid successfully maintained control of the rehearsal or preparation period.
- <<player_name>>’s authority is reduced in practice, even if not openly challenged.
- At the end of the scene, append a short summary line to secretInfo that includes the text "STORY EVENT END" and briefly notes that the Maid stabilized the rehearsal during <<player_name>>’s absence.

The order of things happening according to my observation

- The Tracked Item for the Event is set to "NO" - The Trigger fires and sets it to "YES", 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 "NO" - in the same turn, the next available Trigger sees the "NO" fires and sets it to "YES", then copies it's content into the assigned EIB and the whole thing starts new