Signal Rail is a document governance system for personal and project material. It is not a notes app, a task manager, or a wiki. It is a discipline for keeping project material separated by nature, stability, and authority — so that work stays readable while the project grows, branches, changes shape, and comes back after interruption.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.
The problem it solves
Project documentation usually breaks when everything lives in the same undifferentiated space. A note becomes a decision. A possibility becomes a constraint. A current blocker gets buried under old context. A useful thread disappears because it was never placed anywhere stable. The failure is not that material was written down. The failure is that material was never given a destination. Without routing by level and authority, clarity looks like authority, strength looks like promotion, and continuity starts to look like truth — none of which it is. Signal Rail prevents that by giving material a destination before it becomes noise. It asks one practical question:03_master_working.txt. A decision that has already won belongs in 04_decision_log.txt. A still-mobile but important direction belongs in 05_latent_ideas.txt. A hard-to-reopen identity constant belongs in 02_protocol_freeze.txt. Nothing is promoted just because it sounds strong.
The three-tier model
Signal Rail separates three surfaces that are easy to confuse. Keeping them distinct is a precondition for correct operation.| Surface | Meaning |
|---|---|
| Clean baseline kit | This repository. The reusable Signal Rail source. |
| Deployed instance | A copy of Signal Rail used inside or beside a real project. |
| Host project | The actual project being governed by a deployed instance. |
| Workstation | Optional local interface for reading, staging, previewing, and writing a live instance. |
AI_TO_AI__DEPLOYED_INSTANCE_SIGNAL_RAIL.txt) only says that a folder is a Signal Rail instance — it does not identify what is being governed. The host project must always be closed explicitly before substantive action begins.
The rails
Signal Rail separates material by role. Each file governs exactly one level. Material is routed to the file whose level matches the material’s nature and stability — not the nearest available surface.| Rail | File | What belongs there |
|---|---|---|
| 🚪 Runtime entry | 00_runtime_entry.txt | Valid entry, minimum read, and reading boundaries |
| 🧭 Orientation | 01_orientation.txt | Project identity, perimeter, and reading frame |
| 🧊 Freeze | 02_protocol_freeze.txt | Identity constants that should be hard to reopen |
| 🔥 Master working | 03_master_working.txt | Current live state, blocker, active work, and next move |
| ⚖️ Decision log | 04_decision_log.txt | Choices already taken, already in effect, and already won against alternatives |
| 🌱 Latent ideas | 05_latent_ideas.txt | Important unresolved material that still needs motion or placement |
| 🧠 Lateral kernel | 06_ai_to_ai.txt | Agent operating behavior inside a Signal Rail instance |
| 🧰 Guided prompts | 07_guided_prompts_test.txt | Guided paths for safer starts, rebuilds, reviews, and routing passes |
| 🗺️ Surface map | 08_surface_map.txt | Real technical topology, entrypoints, sensitive surfaces, and minimal runbook |
| 🔁 Handoff | 09_handoff_reentry.txt | Re-entry support and continuity — not canonical project truth |
| 🧲 Field findings | 97_field_findings.txt | Lateral captures during an active pass before routing or discard |
| 📌 Parking | 98_parking.txt | Useful material that is not active now |
| 📦 Archive | 99_archive.txt | Closed, historical, duplicate, or no-longer-live material |
What Signal Rail prevents
Signal Rail is strict because project material becomes dangerous when level and authority blur. These are the specific failures it is designed to block:- a strong sentence becoming a decision
- a live blocker becoming project identity
- a temporary solution becoming freeze
- a hypothesis entering current work too early
- a handoff note becoming canonical truth
- a technical map becoming orientation
- a clean rewrite becoming less true than the messy source
- a deployed instance being mistaken for the host project
AI-assisted and manual operation
Signal Rail is mainly designed to be operated with an AI agent during real work. You think, work, speak, paste material, or bring a messy source set. The agent reads the Signal Rail entry layer, activates the lateral kernel, closes the working frame, and helps route material into the right document without mixing levels. The human stays in charge of meaning, authority, and approval. The agent handles frame closure, level separation, promotion discipline, and safe writes when authority is clear. Manual editing is a valid fallback, but it requires the same respect for canonical destinations, marker zones, ID families, and promotion boundaries that the governed operation enforces automatically.The lateral kernel
06_ai_to_ai.txt is a lateral kernel. It governs how an AI agent reads, stops, asks, routes, proposes, and writes while operating inside a Signal Rail instance.
06_ai_to_ai.txt is not the host project, not a global personality file, and does not make every AI answer follow Signal Rail everywhere. It activates in the right context — for the right folder, with the right entry layer — and governs only the agent’s behavior inside that deployed instance.00_runtime_entry.txt) has been read and valid entry has been established. It does not turn the whole AI session into a permanent document-management contract outside Signal Rail.
License
SeeLICENSE in the Signal Rail repository.
Quickstart
Deploy a Signal Rail instance and open your first governed AI session in under ten minutes.
Core Concepts
Understand routing discipline, canonical authority, level classification, and the write gate.