The journey of a message, chat client → model
One message, traced through relayd's deterministic control chain exactly as the code runs it (internal/relay/relay.go, Broker.Run). Each numbered gate can admit the message onward or divert it — the message only reaches the model if it survives every gate in order.
Inbound path & return path
Order is the security
The gates run in a fixed sequence — lockdown, then session, then anomaly, before a slash command or the model is ever considered. A message must pass every one, in order, to be admitted.
Most paths never reach the model
A slash command is answered locally; an over-budget or over-cap message is refused; a gated user with no live session gets a re-auth challenge. Only an admitted message crosses to the backend.
The socket boundary
relayd and the model are separate processes. Admitted messages cross a unix socket to relay-shim, which the model runs as an MCP server — so the daemon and the model can restart independently.
Fail-open where it should
The anomaly gate is advisory: if its backing store is down it fails open and logs the outage, because the real boundary is the session/allowlist controls — an outage there must not lock everyone out.