Architecture overview
Every integration this platform runs is one loop: publish, select, deliver. Once you can narrate a message through that loop, every other article in these docs is detail. This page is the narration.
In words: a message arrives through a receive port’s adapter. The port’s inbound flow runs, pipeline components transform or split, classification stamps a message type (or the port’s Publish Message Type Fallback does), and promotions defined on that type lift the handful of values routing will need. The message is then published onto the bus, a purpose-built message exchange, with no destination attached. Every running send port’s subscription expressions are evaluated against it; each match gets its own copy to deliver, shaped on the way out by the port’s map and pipeline, then handed to the outbound adapter. Zero matches, one, or twenty, the publisher neither knows nor cares.
Three ideas do all the routing. A message type is a name, not a schema, not a contract, and it is the coarse routing key: most subscriptions start with {{Message.MessageType}} == "Order". Promotions, defined on the message type, lift specific payload values into routing reach, referenced message-type-qualified: {{Promoted.Order.Region}}. And expressions combine them, one engine, the same {{…}} tokens, everywhere a string can be typed: subscriptions, map bindings, component properties, adapter fields. Promote what you route on or bind into an adapter parameter; in a subscription, everything else is reachable on demand with {{Message.Body}}.XPath.
There is no orchestration engine, deliberately. A multi-step process is the same loop repeated: stage one publishes a canonical type, stage two subscribes to it and publishes its own output type, stage three subscribes to that. The “process” is the visible sum of its messages, every intermediate step tracked, every handoff a subscription you can read. State lives in three places, all inspectable: messages themselves (the preferred home, state as messages), Variables (per-flow-instance working values), and Constants (per-deployment configuration). The composition catalogue, from splitting to the countdown loop, lives in Patterns.
A Tracking ID is stamped when a message is received and persists across every hop, through pipelines, onto the bus, through each matching send port’s delivery. Tracking answers “where did my message go?”; Monitoring answers “is the platform healthy?”; Logs answers “who changed what, and prove it.” Failures are first-class citizens of the same model: a failed delivery is a message with somewhere to go, never silently dropped, alerted through Activity Notifications, and replayable once the cause is fixed.