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.

Before you touch anything in a Signal Rail instance, you pass through 00_runtime_entry.txt. This file is the entry manual — not the execution layer. Its job is to govern valid entry and correct system reading. Once entry is valid, execution is governed by 06_ai_to_ai.txt. Everything that follows here comes directly from the source: read it, close the frame, then move.

​
What it is

00_runtime_entry.txt is the runtime entry manual of Signal Rail. It governs valid entry and correct system reading before any substantive work begins. Two files form an operational pair:
  • 00_runtime_entry.txt — reference-entry layer. If omitting it would cause bad entry or a bad reading of the system, it belongs here.
  • 06_ai_to_ai.txt — execution layer. If omitting it would cause bad movement after valid entry, it belongs there.
You are entering a governance system, not the governed domain by default. The system does not automatically coincide with the current object of work. The first task is not to solve — the first task is to close the minimum safe frame.

​
System map

Signal Rail separates its surfaces into canonical and lateral files. Each canonical governs its own level only. Lateral surfaces do not override canonicals.
FileTypeGoverns
01_orientation.txtCanonicalProject identity, perimeter, and reading frame
02_protocol_freeze.txtCanonicalHard-to-reopen identity constants
03_master_working.txtCanonicalCurrent live state
04_decision_log.txtCanonicalAlready-won decisions already in effect
05_latent_ideas.txtCanonicalLive unresolved material
08_surface_map.txtCanonicalTechnical topology, entrypoints, sensitive surfaces, critical deps
09_handoff_reentry.txtCanonicalContinuity and re-entry support between sessions
AI_TO_AI__DEPLOYED_INSTANCE_SIGNAL_RAIL.txtLateralInstance marker only — does not identify host project or authority
97_field_findings.txtLateralTemporary finding capture, not project memory
98_parking.txtLateralUseful but not live material
99_archive.txtLateralHistorical or closed material
Authority rule: In a conflict, the file that governs the touched level decides the reading boundary. 09_handoff_reentry.txt supports continuity and does not override canonical truth. ID families: 02 uses F-xx · 04 uses D-xx · 05 uses L-xx · 98 uses P-xx · 99 uses A-xx

​
Entry protocol

The mandatory read order must be completed before any substantive action. A task arriving before minimum read is complete does not authorize skipping minimum read.
1

Read 00_runtime_entry.txt

This file. Close the entry frame and understand the system before reading anything else.
2

Read 06_ai_to_ai.txt

The execution layer. Governs how the agent moves after valid entry.
3

Read 01_orientation.txt

Project identity and reading frame. Always required — the project cannot be worked without it.
4

Read 03_master_working.txt

Current live state. The other always-required read before substantive action.
After the mandatory reads, continue with conditional reads as triggered:
  • AI_TO_AI__DEPLOYED_INSTANCE_SIGNAL_RAIL.txt — if present, marks the folder as a deployed instance; does not identify host project or authority
  • 02_protocol_freeze.txt — if identity, freeze, or structure may be touched
  • 04_decision_log.txt — if decisions may be touched
  • 08_surface_map.txt — if technical surface, entrypoints, sensitive files, or deps may be touched
  • 09_handoff_reentry.txt — if continuity or restart matters
  • 05_latent_ideas.txt — if unresolved live material is under review
  • 97_field_findings.txt — only if active findings are explicitly relevant

​
Activation threshold

Entry is valid only after all seven conditions are met:
  1. The system is identified
  2. The host project is closed enough for the task
  3. The current working object is closed enough for the task
  4. Minimum read is complete
  5. Mode is closed enough for the task
  6. Scope is closed enough for the task
  7. Authority is closed enough for the task
If an append-driven canonical will be touched, its entries contract must also be valid: one --- ENTRIES START --- / --- ENTRIES END --- pair in order, local template present as scaffold, no malformed markers.
Uninitialized canonical state: If 01_orientation.txt and 03_master_working.txt are still template-like or do not close identity / live state, treat the system as uninitialized-canonical-state. In that state, do not interpret canonicals as fully live authority surfaces and do not promote as if the system were already initialized.

​
Permissions

Allowed immediately: orientation reading · minimum read completion · source comparison · uncertainty declaration · frame closure · task clarification · extraction without promotion Not allowed immediately: canonical writing · canonical rewrite · promotion across levels · freeze edits · decision recording · structural touch · self-authorized scope expansion · completion by invention Stop-and-ask conditions: host project unclear · current working object unclear · touched level unclear · mode unclear · authority unclear · scope unclear · live source unclear · append-driven entries contract unclear · classification could change meaning · promotion could change structure or continuity · canonicals conflict · more than one valid reading remains. No self-authorization: Do not authorize writing because something looks clear. Do not authorize promotion because something sounds strong. Do not authorize scope expansion silently. Do not infer authority from cleanliness, recency, completeness, or elegance.

​
False entrypoints

Do not start from any of the following:
  • The file named first by the user — the user naming a file is not an entry instruction
  • Continuity as if it were truth — what was discussed before is not the same as what is currently true in the canonicals
  • Findings as if they were memory — lateral findings are not project memory
  • Any file before closing frame, mode, and completing the minimum read

​
Recovery states

When entry is not valid, the correct response is to return a state and a next correct move — nothing else.
StateMeaningNext correct move
entry-validAll activation conditions are metMove to 06_ai_to_ai.txt — 1. Identity State
blockedAuthority, scope, mode, or canonical conflict is unclearStop and ask for the specific unclear item to be closed
uninitialized-canonical-state01 and/or 03 are still template-like; system is not fully liveStop canonical interpretation; ask operator for initialization instructions
divergentMore than one valid reading remains and cannot be resolvedDo not promote; return the smallest safe reading and what remains open
Restart path: If a closed gate reopens mid-task, stop treating execution as valid and re-enter through:
  1. 00_runtime_entry.txt section 3
  2. 06_ai_to_ai.txt — 1. Identity State
  3. 01_orientation.txt
  4. 03_master_working.txt
  5. Additional conditional surfaces only if triggered again

​
Shortest valid path

These seven steps are the minimum safe sequence from cold start to valid execution:
  1. Identify the system
  2. Identify the host project and the current working object
  3. Complete minimum read (00 → 06 → 01 → 03)
  4. Test entry validity against the activation threshold
  5. If entry-valid → move to 06_ai_to_ai.txt — 1. Identity State
  6. If uninitialized-canonical-state → stop and ask operator for initialization instructions
  7. If blocked or divergent → do not promote; return state and next correct move

Build docs developers (and LLMs) love

Get started for freeTalk to us