Signal Rail is a plain-text document governance system for personal and AI-assisted projects. It separates project material into typed rails — current state, decisions, constraints, unresolved ideas, surface maps, handoff, parking, and archive — so that work stays readable as a project grows, branches, changes shape, and returns after interruption. The system does not try to make a project smaller than it is. It keeps the material bounded, routable, and recoverable at every stage.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. There is no structural difference between a note and a decision, between a live blocker and a historical one, between a possibility that is still open and a constraint that has already won. When level and authority blur, the material becomes dangerous. Signal Rail prevents that by asking one practical question before anything is written:03_master_working.txt. A decision that has already won belongs in 04_decision_log.txt. A still-mobile direction belongs in 05_latent_ideas.txt. A hard-to-reopen identity constant belongs in 02_protocol_freeze.txt. A technical entrypoint or sensitive surface belongs in 08_surface_map.txt. Nothing is promoted just because it sounds strong.
The four-surface architecture
Signal Rail is built around four distinct things that must never be confused:| Surface | Meaning |
|---|---|
| Clean baseline kit | This repository — the reusable Signal Rail source. |
| Deployed instance | A copy of Signal Rail placed inside or beside a real project. |
| Host project | The actual project being governed by Signal Rail. |
| Workstation | Optional local interface for reading, staging, previewing, and writing a live instance. |
The tool surface and the host project are not the same thing. Signal Rail governs the host project — it is not the host project. Keep this separation sharp at all times.
What Signal Rail prevents
Signal Rail is strict because project material becomes dangerous when level and authority blur. These are the eight specific failure modes it blocks:- 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
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. It is not a global personality file, and it does not make every AI answer follow Signal Rail everywhere.
The kernel becomes active in the right context — for the right folder, with the right entry layer. It does not turn the whole AI session into a permanent document-management contract outside Signal Rail. This is why Signal Rail stays light: the kernel activates where it belongs, and nowhere else.
Rails overview
Explore every rail, its role, and what belongs in each canonical file.
Quickstart
Bootstrap a Signal Rail instance and start your first governed session.
Core Concepts
Understand rails, levels, authority, and the write gate.
AI agent operation
Learn how an AI agent moves through Signal Rail correctly.