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.

Signal Rail files are plain text. Any text editor — Notepad, VS Code, Vim, a terminal editor on a remote machine — can open and modify them. Manual editing is a legitimate operating mode, not an unsafe fallback, but it requires discipline. The rails work because they stay strict, and nothing in a plain-text file prevents you from writing in the wrong place, using the wrong ID, or renaming a section that agents and the workstation depend on. These rules exist to make manual editing safe.

The core rule

Do not turn manual editing into free-form note taking. Every edit must respect the eight properties that make a Signal Rail instance coherent:
PropertyWhat it means
Canonical destinationWrite material to the file that governs its level
File authorityEach file owns its level — do not override one file with content from another
Local templatesUse the entry template inside each file as the shape for new entries
Entry markersAppend-driven files have an entry zone — stay inside it
Append zonesNew entries go at the bottom of the zone, not scattered through the file
ID familiesUse the correct ID prefix for each file (F-xx, D-xx, L-xx, P-xx, A-xx)
Source authorityDo not promote material whose governing source is not yet closed
Promotion boundariesA strong sentence is not a decision. A useful idea is not freeze. Meet the criteria.

Append-driven files and the entry zone

Files 04, 05, 08, 09, 97, 98, and 99 are append-driven. New live entries must be written only inside the entry zone:
--- ENTRIES START ---
[your new entry here]
--- ENTRIES END ---
Do not add entries above the --- ENTRIES START --- marker or below the --- ENTRIES END --- marker. Do not create a second START/END pair anywhere in the file. Each append-driven file must have exactly one start marker and exactly one end marker, in that order. If the marker contract is broken, the workstation and agents will treat the file as invalid and stop before writing.

Template scaffolding

Inside the entries zone of each append-driven file you will find one or more [TEMPLATE ONLY] blocks. These are scaffolding — they show the correct shape for a new entry in that file.
  • Do not delete [TEMPLATE ONLY] blocks. They preserve the entry shape for future use and for automated tools.
  • Do not treat them as live entries. A [TEMPLATE ONLY] block does not count as a real decision, latent idea, parking item, or archive record.
  • When you add a real entry, add it as a new block alongside the template — copy the template shape, fill in the fields, and keep the original [TEMPLATE ONLY] block in place.

ID families

Each file that uses IDs has its own prefix family. IDs are local to their container — a D-04 in the decision log is not the same namespace as an L-04 in the latent ideas file.
FileID prefixNotes
02_protocol_freeze.txtF-xxMaximum 5 entries (F-01 through F-05)
04_decision_log.txtD-xxNo maximum
05_latent_ideas.txtL-xxNo maximum
98_parking.txtP-xxNo maximum
99_archive.txtA-xxNo maximum
When one file references an entry in another (for example, a working state entry referencing D-03), the cross-file reference stays in the links to field of the entry — it does not become a new local ID in the referencing file. Increment IDs sequentially and never reuse a retired ID.

Section title stability

Section titles in 01_orientation.txt, 02_protocol_freeze.txt, 03_master_working.txt, 06_ai_to_ai.txt, and 08_surface_map.txt are operational anchors. Agents and the workstation navigate these files by locating specific section titles. If you rename a section, you break navigation. Keep every section title exactly as it appears in the canonical file. Fill in the content beneath a section title — do not rename the title itself.

What to edit in each file

01_orientation.txt governs project identity, perimeter, and reading frame. It is what lets an agent (or a new team member) understand the project correctly without reading everything else first.What to fill in: the named sections — Project Name, What It Is, Why It Exists, Core Direction, Accepted Trade-offs, Main Boundaries, Hard Boundaries. Write about the host project, not about Signal Rail.What not to put here:
  • Current work, active blockers, or what you did today (that belongs in 03)
  • Decisions that have already been made (that belongs in 04)
  • Ideas that are still unresolved (that belongs in 05)
  • Workflow explanations or operating instructions
When to update: only when the correct way to understand the project changes — when its identity, scope, or fundamental direction shifts. Do not update 01 every session.
02_protocol_freeze.txt holds identity constants — things that, if removed, would make the project stop being itself.What to fill in: F-01 through F-05 slots (maximum 5 entries). Each entry requires:
  • id — F-01, F-02, etc.
  • principle — the identity constant being frozen
  • why it is frozen — the reasoning that makes this hard to reopen
  • links to — cross-references to supporting decisions or orientation sections
  • reopening trigger — the specific condition that would justify reopening this freeze
Before freezing anything, ask three questions:
  1. Would the project stop being itself if this were removed?
  2. Are you defending a foundation, or a solution that just feels right today?
  3. Does this truly belong to the project’s identity — not to its current implementation?
Do not freeze things too early. Premature freeze locks in decisions that have not fully won yet.
03_master_working.txt is the live operational picture of the project — where it is right now, what is active, what is blocking it, and what comes next.Named sections: Project Name, Last Updated (date), Current Objective, Current Blocker, Current State, Work In Progress, Open Items That Matter Now, Real Open Questions, Active Risks, Next Step.What to update: all named sections whenever the operational picture changes. At minimum, realign these five sections at every session close:
  • Current State
  • Work In Progress
  • Real Open Questions
  • Active Risks
  • Next Step
Cross-references: references to D-xx IDs in 03 must point to real, existing entries in 04_decision_log.txt. Do not reference a decision ID that has not been logged yet.What not to put here: project identity (that belongs in 01), historical decisions (that belongs in 04), ideas that are still mobile (that belongs in 05).
04_decision_log.txt records choices that have already won against a real alternative and are already in effect. The key test: if you cannot state what the decision won against, it is not a decision yet — it is a preference or a direction.How to add an entry:
  1. Open the file and locate the --- ENTRIES START --- / --- ENTRIES END --- zone
  2. Copy the [TEMPLATE ONLY] entry shape
  3. Add your new entry inside the zone, after any existing entries
  4. Fill in all fields: id (D-xx, next in sequence), decision, date, won against, because, links to, status
  5. Leave the [TEMPLATE ONLY] block in place
The won against field is not optional. If it is blank, the entry is not ready to be logged.
05_latent_ideas.txt holds live but unresolved material — ideas, directions, and threads that matter and need to stay visible, but are not stable enough for 04 or 02.How to add an entry:
  1. Locate the --- ENTRIES START --- / --- ENTRIES END --- zone
  2. Copy the [TEMPLATE ONLY] entry shape
  3. Fill in: id (L-xx), title, state, body, next step, links to
  4. Valid state values: new, to review, to absorb, parked, dead
Every entry should have a next step — even if the next step is “review at next session” or “decide whether to park or promote.” An L-xx entry without a next step is incomplete.
98_parking.txt holds useful material that is not active now but could matter later. Parking is not the same as archiving — parked material is still potentially live.How to add an entry:
  1. Locate the --- ENTRIES START --- / --- ENTRIES END --- zone
  2. Copy the [TEMPLATE ONLY] shape
  3. Fill in: id (P-xx), title, body, parked on (date), next step to reactivate it
The Next Step to Reactivate It field is required. A parking entry without a reactivation path is an archive entry in disguise — move it to 99 instead.
99_archive.txt holds closed, historical, superseded, or no-longer-live material. Once something is archived, it is not active and should not be referenced as current authority.How to add an entry:
  1. Locate the --- ENTRIES START --- / --- ENTRIES END --- zone
  2. Copy the [TEMPLATE ONLY] shape
  3. Fill in: id (A-xx), title, body, archived on (date), reason
Do not archive material just for visual cleanliness. Archive when something is genuinely closed, superseded, or decided against. If it is still potentially useful, park it in 98 instead.

What never to do manually

These actions will break instance integrity and may cause agents or the workstation to misread, stop, or produce incorrect output:
  • Do not add entries outside the --- ENTRIES START --- / --- ENTRIES END --- zone in any append-driven file
  • Do not create a second START/END pair in any file — exactly one per file, always
  • Do not delete [TEMPLATE ONLY] scaffolding blocks — they are structural, not decorative
  • Do not rename section titles in 01, 02, 03, 06, or 08 — they are navigation anchors
  • Do not create new files — use the canonical containers; the system does not recognize arbitrary files
  • Do not promote material to 02 or 04 without meeting the entry criteria (identity test for freeze, won-against test for decisions)
  • Do not write to 01, 02, or 06 without the equivalent of a structured review — these files govern identity, freeze, and agent operating behavior, respectively

Workstation

Use the offline HTML workstation to read, stage, and write to a live Signal Rail instance with built-in guardrails and preview.

Lateral Kernel

Understand how the lateral kernel governs agent behavior inside a Signal Rail instance — the execution layer that sits above the entry rules.

Build docs developers (and LLMs) love