Documentation Index
Fetch the complete documentation index at: https://mintlify.com/xxyoudeadpunkxx/signal-rail/llms.txt
Use this file to discover all available pages before exploring further.
06_ai_to_ai.txt is the lateral kernel of Signal Rail. It governs how an AI agent reads, stops, asks, classifies, proposes, and writes while operating inside a Signal Rail instance. It is not the host project. It is not a global personality file that changes how the agent behaves everywhere. It is horizontal — a set of rules that spans across all canonical files and controls protocol behavior for the duration the agent is working inside a governed Signal Rail folder.
What the Lateral Kernel Is
The lateral kernel sits outside and above any single canonical file. While each canonical governs its own level — identity, freeze, live state, decisions, latent material —06_ai_to_ai.txt governs the rules of movement between them. It defines what the agent may and may not do, when to stop, when to ask, and how to return. It does not contain host project content. It contains the rules the agent must follow while working on host project content.
Signal Rail is not the host project. Signal Rail is the document system used to govern the host project.
Activation
The exact activation command is:- Enables the Signal Rail protocol for the agent
- Does not bootstrap the instance automatically
- Does not classify or write automatically
- Does not infer the host project automatically
Prerequisites
00_runtime_entry.txt must be read before using 06_ai_to_ai.txt operationally. The runtime entry file closes valid entry and correct system reading. The lateral kernel closes execution behavior after entry is valid. If 00_runtime_entry.txt has not been read yet, return there first.
Section 1 — Identity State
Before the agent takes any action, three things must be closed:- The host project — What real project is Signal Rail governing here?
- The active mode — What is the agent permitted to do in this session?
- Source authority (when needed) — Which sources govern the touched level?
Signal Rail is not the host project. Signal Rail is the document system used to govern the host project.
Section 2 — Canonical State
Each canonical file has a defined authority. The agent must treat each file as governing its own level only. Files outside canonical containers carry no authority over freeze, decisions, or project identity.| File | Authority |
|---|---|
01_orientation.txt | Host project identity, perimeter, and reading frame |
02_protocol_freeze.txt | Identity-level constants |
03_master_working.txt | Current live project state |
04_decision_log.txt | Taken decisions, what they beat, what they touch |
05_latent_ideas.txt | Unresolved material not yet absorbed well |
06_ai_to_ai.txt | Horizontal protocol behavior |
07_guided_prompts_test.txt | Guided prompt flows and safe question flows |
08_surface_map.txt | Technical surface map: where the project lives, where to enter, where not to enter, sensitive surfaces, minimal runbook, critical env/deps |
09_handoff_reentry.txt | Continuity layer: handoff, re-entry, and non-canonical continuity output |
Append-Driven Entries Contract
Files04, 05, 08, 09, 97, 98, and 99 are append-driven through a single entries zone per file. This contract must hold:
- Each append-driven file must contain exactly one
--- ENTRIES START ---and one--- ENTRIES END ---, in correct order. - Each file keeps its own local empty template inside the entries zone. Do not normalize all files into one generic template.
[TEMPLATE ONLY]blocks are scaffolding, not live entries, and carry no canonical authority.- A structured read must not count
[TEMPLATE ONLY]blocks as real entries. - Canonical writes must insert new entries only inside the entries zone.
Section 3 — Trigger and Anti-Book Discipline
Signal Rail supports trigger-based delta review proposals, but the trigger system has strict limits. Which files may receive automatic trigger proposals:03_master_working.txt— only when the current objective changes, the dominant blocker changes, or a new line enters current live work04_decision_log.txt— only when “won against” can be stated for a decision already in effect08_surface_map.txt— only when a path changes, an entrypoint changes, or a critical dependency changes
01_orientation.txt02_protocol_freeze.txt05_latent_ideas.txt
- A trigger opens review — it does not write
- Review requires explicit human confirmation before any canonical update
- Do not trigger from broad semantic inference
- Do not trigger from background interpretation of free text
- Trigger only from observable workflow events
Section 4 — Kernel Refresh Discipline
Rereading06_ai_to_ai.txt is required in certain situations, not from general uncertainty.
Reread is required before:
- Crossing into structure mode from another mode
- Touching
01_orientation.txt,02_protocol_freeze.txt,04_decision_log.txt, or06_ai_to_ai.txt - A live conflict between canonicals and implementation is detected
- A live conflict between canonicals is detected
- A second stop-and-ask occurs in the same task
- Task length alone
- Dense conversation alone
- Broad semantic suspicion
Required Session Return Format
Every session must end by returning the following format. No section may be omitted.05_latent_ideas.txt. If the task is still divergent, declare divergence and propose the Minimally Viable Path without promoting.