Three views, each answering a different question: what the components are and where the process boundaries sit; how a received message moves through the durable staged queue and earns a disposition; and how Connections, Routers, and Handlers wire together by name. The prose source of truth is the engine's ARCHITECTURE.md.
The engine is a headless service; clients are separate processes that reach it only through the localhost API. Dependencies point one way — the API depends on the engine, the engine never imports the API or a client.
A received message is ACKed on receipt — once it's durably committed to the ingress stage, before routing, transform, or delivery. Each handoff is a single committed transaction, giving at-least-once delivery, retries, and replay with no separate broker.
An inbound Connection names a Router; the Router forwards to Handler(s) by name; each Handler sends to outbound Connection(s). There's no enclosing "channel" object — set it up with guided wizards, or write it in Python.
From install to your first routed message — with the full feature set and the engine docs a click away.
