Glossaire

Persisted resource representing a business entity — company, invoice, payment, credit limit, etc. Every platform object is typed, identified, and produces events on state transitions. See the business model.

Opaque string prefixed by object type (cmp_, inv_, cs_…) exposed in the id field of each resource. Stable and usable in the API, webhooks, and processes.

The source_reference field is a free-form value accepted by most platform objects. It lets you store your own identifier (ERP order number, CRM reference) directly on the object without a third-party mapping table.

Platform-object value prepared before persistence: same business type as the target object, but without an identifier. The draft mode belongs to the process data type and must not be confused with a persisted object whose business status itself is draft. See Core business-model principles.

Company or individual identified in the platform — buyer, supplier, partner. This is the root object to which contacts, orders, invoices, and credit decisions attach. Prefix: cmp_.

Natural person associated with a company, carrying identity and contact information. A contact may have one or more roles (legal representative, payment authorizer…). Prefix: ctc_.

Payment or credit-request session initiated by your platform and completed by the buyer through a User Journey. Directly exposes the url field for redirecting the buyer. Prefix: cs_.

Customer-onboarding case grouping data collection, compliance checks (KYC/KYB), and the final acceptance decision. Prefix: obc_.

Financial document issued by your platform, carrying an amount due, due date, and link to the buyer company. It can be reconciled with one or more payments. Prefix: inv_.

Amount owed by a buyer, produced by an invoice or used line of credit. The receivable carries collection state and serves as the basis for payment reconciliation.

Payment tracked with a provider (Stripe, bank transfer…) and imported into Ormuz. A PSP payment is then allocated to one or more receivables through reconciliation. Prefix: psp_.

Platform payment reconciled to a receivable or invoice. Independent from the source provider: represents the financial movement from Ormuz's perspective after reconciliation. Prefix: pay_.

Credit ceiling granted to a company or company group, with history and decision reason. Consumed by outstanding orders and invoices. Prefix: crl_.

Amount of credit currently used by a company — sum of outstanding receivables not yet settled. Updated as transactions evolve.

Orchestration program composed of nodes connected by routes. A process is versioned and may execute several instances in parallel. See The process model.

Published version of a process definition. Each process change creates a new revision; running instances continue on the revision with which they started.

Concrete execution of a process for a given context — buyer, order, case. An instance progresses through nodes until completion or cancellation. Prefix: pci_.

Atomic execution unit inside a process. Every node has a type (connector, user action, router, timer…), input parameters, and typed outputs. See the Core nodes and nodes provided by extensions.

Typed wiring between a node output and another node input. Bindings carry platform objects or scalars without requiring manual identifier handling. See Inputs, outputs, and bindings.

Conditional link between two nodes defining the execution path. A router exposes several routes; one is activated on each execution according to the evaluated condition.

Event or condition that automatically starts a new process instance. A trigger can listen to a platform event (invoice creation, payment completion…) or be invoked directly through the API.

Time event triggered at an absolute date or after a delay. Timers may start a parallel execution branch or resume a waiting instance after a delay expires.

Web page served by Ormuz for user interactions. The instance pauses when reaching a user action and automatically resumes after completion. See User Journeys.

Node that pauses an instance and opens a hosted page to collect an end-user interaction — form, choice, mandate collection, OTP verification. Action-object prefix: pua_.

Versioned artifact encapsulating deterministic policy behind typed inputs and outputs. A Decision calculates; the process orchestrates effects from its result. See Understanding Decisions.

Observable evaluation of an immutable Decision revision with an explicit input snapshot. The Run preserves the exact identity of executed logic and, when requested, its trace.

Versioned operational artifact composed of an objective, general instructions, and one or more business activities. See Understanding Agents.

Executable unit of an Agent. It carries instructions, input/output contract, tools, guardrails, and memory-access policy.

Optional namespace declared by a process to preserve Agent Memory continuity across multiple Agent Tasks. The role never selects the Agent or revision; each Agent Task carries that dependency directly.

Working-context resource belonging to an Agent Definition. It can be reused across Runs and revisions of the same Agent without becoming a source of business truth. In a process, it can be mapped explicitly or resolved from an Agent role.

Observable execution of an activity belonging to a precise Agent revision. A Run exposes status, results, tool calls, and diagnostics according to applicable protection rules.

Capability explicitly granted to an Agent activity during a Run. Its contract is designed for agentic use and remains independent from any equivalent process node. A tool may read or act according to its contract and permissions; its presence on one activity grants no rights to other activities.

Static classification low, medium, or high describing the maximum business consequence a tool can produce. It grants no right and remains distinct from data classification, authority, and cost.

Process delegated from a parent process. The parent waits for subprocess completion before resuming, enabling complex orchestration to be decomposed into reusable processes.

Authentication token used in the Authorization header to call the Ormuz REST API. Keys are created from the Console and can be limited to specific scopes.

HTTP notification sent by Ormuz to a URL you configure upon a platform event. Every delivery is signed; Ormuz provides at-least-once delivery with automatic replay. See Receive webhooks.

Structured message emitted by Ormuz on an object state transition — invoice.issued, payment.matched, onboarding_case.completed… Each event contains the complete relevant object. See the event catalog.

Third-party service used through an extension — payment, KYC, electronic signature, open banking, data, or financing. In generic documentation, provider means this business provider, not an Agent's AI engine.

AI execution capability offered to Agents and exposing a list of models. The model provider selected on an Agent revision is distinct from a business provider used through an extension.

Orchestration node interacting with a third-party provider — trigger a Stripe payment, launch KYB verification, initiate electronic signing. Parameters and outputs of each connector are documented on its extension.

How your platform interacts with Ormuz: directly driving processes via API, delegating a complete journey through a checkout session, or combining both. See Integration modes.

Authorization explicitly granted to an integration node so it can read or modify a business-object type inside its own behavior, beyond what its inputs and outputs show. It is checked up to the moment of access and can be revoked at any time. See Node permissions.

Technical link between a provider object and the Ormuz object it represents, recorded for one integration configuration. It enables reconciliation and rereading of that exact target without ever opening broader access. See Object mappings.