Operational adaptability
Adapting a journey to a country, segment, or risk policy does not mean hiding differences behind automatic selection. Ormuz favors an explicit model: context is typed, policy is versioned, routes remain visible, and every external capability is chosen through a known configuration.
Principle: share only what is genuinely common
Two markets may share information collection, produced business objects, and the expected outcome while diverging on a check, threshold, or external service. Keep these common elements in the same process when it improves readability; create branches or separate artifacts when their business contracts genuinely differ.
Context feeds an explicit policy. Branches may use different configurations while converging on the same Ormuz business contract.
An extension node uses the configuration explicitly associated with it. If service choice depends on country, segment, or risk, materialize that choice through a Decision or process route.
Carry context without creating a second business model
Start from data that is already canonical: the company, its groups, commercial objects, compliance outcomes, or credit projections. A process may also receive a dedicated input when contextual information does not correspond to an existing Ormuz object.
Bindings and expressions may read input, guaranteed outputs of previous nodes,
vars and env. An environment variable suits configuration that differs between sandbox and production or across merchants; it is not a substitute for business data that should live on a canonical object.
See Inputs, outputs, and bindings and Business-model principles.
Choose between routing and Decision
| Need | Prefer | Why |
|---|---|---|
| Simple local condition directly readable in the graph | Routeur Core | The choice remains close to the branches it controls. |
| Reusable, testable policy versioned separately | Decision | The deterministic logic has its own contract, revisions, and Runs. |
| Ambiguous case requiring contextual analysis and bounded capabilities | Agent | The activity has a typed contract, explicit tools, and guardrails; the process remains responsible for handling the result. |
If an operator must be able to understand why a branch or provider was selected, the rule must remain observable in the graph, a Decision, or the configuration of the relevant artifact.
Choose external capabilities explicitly
Extensions declare the nodes, events, and external objects they provide. An extension node references a compatible configuration; that configuration notably fixes the provider account and environment. The process can therefore use two different configurations on two branches without changing its Ormuz object model.
This decoupling does not mean all extensions are interchangeable. Two providers may expose different node contracts or outcomes. Factor the journey only up to the point where their guarantees remain genuinely comparable, then explicitly normalize the business result if your design requires it.
See Integrations for capabilities that are actually available and their status.
Segment without duplicating policy everywhere
Company groups provide a durable business identity for a population: commercial channel, managed portfolio, internal segment, or another grouping decided by the merchant. The node check_company_group_membership routes explicitly according to company membership.
For richer policy, pass the required information to a Decision instead of copying the same thresholds into several routers. The Decision can then evolve independently from the process while remaining deterministic and testable.
| Variation | Where to carry it |
|---|---|
| A threshold or rule varies by context | Decision — Version the policy independently from the graph and evaluate it with typed inputs. |
| Two genuinely different journeys should diverge | Process routing — Use an explicit route and keep branches visible in the graph. |
| A business population requires special handling | Company Group — Group companies and then test membership with `check_company_group_membership`. |
| A configuration value changes across environments | Variable d’environnement — Reference `env.<name>` in a binding or expression instead of duplicating the process. |
| An external capability differs by case | Extension configuration + explicit branch — Each extension node uses the configuration selected for that branch; Ormuz does not silently choose a provider based on country or segment. |
Evolve without ambiguity
Healthy operational adaptability separates axes that have different lifecycles. The process carries sequencing; a Decision carries deterministic policy; an Agent revision carries activities and authority; an extension configuration carries access to the external service. This separation prevents a threshold change from requiring a graph redesign or a provider change from silently changing a business rule.
- Test every important route with representative context.
- Pin required dependencies when the deployment contract requires it.
- Keep sandbox/production differences in the resources and variables intended for environment-specific values.
- Observe the final business outcome, not only technical success of the provider call.