The specification: three rails, five informational patterns

Where and how flows form, and precisely where the key vectors that move knowledge between planes are declared.

Source: spec/PROGRAMME_MANUAL.md (chapters 6, 10, 11), nestvm/programmes/epistemic-cascade.yaml, nestvm/lib/API.md §5, CLAUDE.md (host, "Thinking rails").

§Rail 5 — a return socket is declared at birth, never improvised

A listener may only ever be told, at the moment it is registered, which of its own slots a later delegated answer is allowed to fill (config.meta.return, naming one of its collection rules). This is not a convenience — it is a hard rule of the underlying specification (Vol. 02 §5.1): nothing committed before a listener existed can ever reach it, so there is no way to wire a return after the fact. Concretely, in the worked study of Part 4, the vector listener declares its return before any question has even been typed:

id: press.facts.wanted
config:
  meta: { return: findings }
  wind:
    collect:
      - { as: question,  match_type: press.vector.given,   reduce: latest, where: [{field: vector, equals: facts}] }
      - { as: findings,  match_type: press.findings.given, reduce: latest, where: [{field: vector, equals: facts}] }
  condition: "question != null && findings != null"

When a Cell is later opened from this exact slot, the machine already knows — because it was told at registration, not guessed afterwards — that whatever comes back must arrive as a press.findings.given fact carrying the facts discriminator. Nothing about opening the Cell has to re-specify where its answer belongs; the address was fixed the moment the listener was born.

§Rail 4 — represent, the one reuse move, used for every kind of carry

Rail 4 is the specification's name for the single mechanism behind everything 2.1 called "carrying": a committed value re-entering a different declared hearing, as a fresh fact, without ever being retyped. It has exactly three request shapes, and the manual (chapter 11, "the informational patterns") is precise about keeping them distinct rather than collapsing them into one idea of "reuse":

• answer — the value fills the hearing's own field directly, as if the person had typed it themselves;
• attach — the value rides alongside a person's own note, as a named attachment, never silently replacing what the person wrote;
• citation — a released value is pointed at again from a new location, carrying a stamp naming exactly where it originally came from, rather than being copied as if freshly stated.

Every one of these answers, on the log, is stamped represented, naming its source by session and offset — so a reader can always tell a value's current location from its point of origin, however many times it has been carried since.

§Rail 6 — authoring a line of reasoning is heavier than adding to one

Committing a fact is light: it is one entry, on an existing lane, judged by rules that already exist. Opening a Cell — descending into a new branch of the reasoning — is categorically heavier, because it registers new topology: new listeners, new doers, an entire admission ceremony behind them, all before the first fact reaches any of it. The specification names this explicitly as its own rail, deliberately distinguished so that the surface never lets the two actions look alike — Part 4's worked walkthrough shows this as a visibly heavier gesture (a gold, "authoring weight" control) than the ordinary grey commit button beside it, and that visual difference is a direct, deliberate reflection of this rail, not a styling choice made independently of it.

§The seven-level cascade's own two extra wrinkles

Two details in epistemic-cascade.yaml are worth naming because they show the chain of 2.1 is not perfectly rigid:

• Level 3 has a side channel. Alongside its ordinary two demands (the person's own refinement, the previous level's output), L3 also listens for addressed.given facts pointed at it by name, accumulating them (reduce: "append") as running annotations rather than requiring exactly one. A chain, in other words, can have a step that keeps gathering rather than only ever waiting for one fixed thing.
• Level 7 is not a plain deterministic gate at all. Its listener runs under a different strategy entirely — semantic_evaluator — whose condition is not a null-guard but a genuinely semantic one: two explicit questions ("does the gathered answer serve what was sought," "do the control questions hold against the whole") judged against a minimum grade. And even once that semantic bar is cleared, L7 still will not seal until a second, entirely separate fact arrives — the person's own response — so the chain's very last link is deliberately built to require both a machine judgement and a human one before it closes.

§Beyond one session — the same move, at a larger scale

Nothing about a line of reasoning is confined to one session. A fresh session's opening fact may itself declare a parent — the exact slot, in an entirely different session, that it exists to answer — and a lineage reading walks this chain of parents upward to a root and downward to every child, entirely by reading each session's own opening fact by address, never by any separate index maintained on the side. This is rail 5's return socket, generalised one level up: a whole session can be a delegated branch of a larger line of reasoning, exactly as a Cell is a delegated branch of a single session's.