Skip to main content

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:
read 06_ai_to_ai.txt
Activation enables the Signal Rail protocol for the current session. It does not authorize further action on its own. What activation does:
  • Enables the Signal Rail protocol for the agent
What activation does not do:
  • 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:
  1. The host project — What real project is Signal Rail governing here?
  2. The active mode — What is the agent permitted to do in this session?
  3. Source authority (when needed) — Which sources govern the touched level?
These are not optional warm-up steps. If any of these remain open, the agent must stop and ask before proceeding.
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.
FileAuthority
01_orientation.txtHost project identity, perimeter, and reading frame
02_protocol_freeze.txtIdentity-level constants
03_master_working.txtCurrent live project state
04_decision_log.txtTaken decisions, what they beat, what they touch
05_latent_ideas.txtUnresolved material not yet absorbed well
06_ai_to_ai.txtHorizontal protocol behavior
07_guided_prompts_test.txtGuided prompt flows and safe question flows
08_surface_map.txtTechnical surface map: where the project lives, where to enter, where not to enter, sensitive surfaces, minimal runbook, critical env/deps
09_handoff_reentry.txtContinuity layer: handoff, re-entry, and non-canonical continuity output

Append-Driven Entries Contract

Files 04, 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.
If the marker contract is missing, duplicated, malformed, or ambiguous on a touched append-driven file, stop and ask before writing.

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 work
  • 04_decision_log.txt — only when “won against” can be stated for a decision already in effect
  • 08_surface_map.txt — only when a path changes, an entrypoint changes, or a critical dependency changes
Which files may NEVER receive automatic triggers:
  • 01_orientation.txt
  • 02_protocol_freeze.txt
  • 05_latent_ideas.txt
What a trigger does and does not do:
  • 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

Rereading 06_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, or 06_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
Do not trigger a reread from:
  • Task length alone
  • Dense conversation alone
  • Broad semantic suspicion
Kernel refresh re-closes the protocol before the task continues. It does not authorize writing.

Required Session Return Format

Every session must end by returning the following format. No section may be omitted.
host project:
mode used:
sources read:
state of convergence:
what you extracted:
where you put it:
what remains uncertain:
recommended next step:
If the task converged, promote to the right file or state why the material still remains in 05_latent_ideas.txt. If the task is still divergent, declare divergence and propose the Minimally Viable Path without promoting.

Global Stop Rule

If scope, level, timing, authority, or duplication risk are unclear, stop and ask.

Build docs developers (and LLMs) love