sessions

What running a session actually does

A session is not a file being played. It is a protocol scaled to a chosen length, checked against the conditions that exist right now, compiled into audio, and delivered with a record of what was produced.

A protocol is a shape, not a duration

A protocol describes phases and the signal inputs each phase uses. The session length you choose scales those phases; it does not reorder them or drop them. A shorter session is the same structure compressed, which is why the available lengths are enumerated rather than free-form.

Preflight runs before anything is compiled

Before a session is built, the system establishes what is currently possible. The result is one of several distinct states, and they are kept distinct on purpose — collapsing them into a single unavailable would hide the reason.

Ready: The requested session can be compiled and delivered as asked.
Limited: It can be delivered, but not at everything that was requested. The limitation is named rather than silently applied.
Unavailable: The route cannot deliver this session at all.
Disconnected: The route is not currently reachable.
Unsafe: The combination is refused. This state fails closed: refusing is the default when the check cannot complete.

Compilation and delivery

Compilation turns the scaled protocol into the exact output for the chosen route, including the supported visual layer where one applies. Stop controls remain available throughout; ending a session is a first-class action, not an interruption of one.

A delivery record can describe what was compiled and what was observed during delivery. It answers a technical question — was this exact thing produced and sent — and it does not answer a question about the listener.