An Ormuz Process describes how a business outcome is produced across systems, services and people. Each node has a typed contract, and the process makes routing, waiting and hand-offs visible instead of burying them in integration code.
A process defines its inputs and outputs, then connects nodes that fetch or transform data, evaluate policy, call extensions, wait for events, collect user input or invoke another orchestration artefact.
Bindings are typed. A node that expects a party, invoice or payment can consume that platform object directly rather than forcing every process author to wire internal identifiers and provider-specific payload paths.
Match the payment to the invoice.
Start your reminder process.
An invoice becomes overdue. A provider confirms a payment. A customer completes a step. Each event can trigger the next decision, action or hand-off in the same operational flow.
Process definitions are versioned. A running or recorded instance keeps the exact revision it was created from, so later edits do not reinterpret historical execution.
The same principle applies when a process calls a Decision, Agent activity or External Task revision: the selected contract is part of the design, not a mutable ambient dependency.