Business authority
An extension never becomes a source of truth simply because it can access an object. Authority describes who may create a fact, write a field, or advance a lifecycle; it is independent from the technical permission to access it.
Authority belongs to a role
Ormuz expresses authority through business roles — for example ormuz, accounting, commerce, fulfilment, psp, bank or producer — rather than through the identity of a particular partner configuration.
The same object can therefore combine several authority planes: an ERP may own the accounting reference of an invoice while Ormuz calculates its operational settlement status.
A technical permission lets a caller reach a surface; it never decides who owns the fact, field, or business transition.
The four primitives
| Primitive | Question |
|---|---|
creation_authority | Which role may bring the object, or a stable variant of that object, into existence? |
field_authority | Which role owns each field during a given lifecycle phase? |
transition_authority | Which role may perform each state transition? |
lifecycle_eligibility | In which states may the object take part in a given operation or projection? |
Authority over a field may change with the lifecycle phase. Do not add a simplistic field such as owner or mastership_level to a partner contract.
Conflicts and synchronization
The conflict rule is deterministic:
- if the field belongs to the external role, synchronization may provide its value;
- if the field belongs to Ormuz, external synchronization never overwrites it;
- if the external system reports a different value for an Ormuz-owned field, the operation fails instead of silently choosing a winner.
There is no automatic strategy last writer wins. Making the partner system converge to an Ormuz-owned value is a separate explicit operation, with its own prerequisites and errors.
Proposals and observations
Authority follows initiative, not financial direction. An operation initiated by Ormuz may begin as an Ormuz-owned proposal or instruction before the external system establishes the final fact. Conversely, a fact that originates in an external system must be observed and materialized from legitimate external evidence.
This distinction is particularly important for financial movements: a refund proposed by Ormuz does not have the same contract as an incoming payment observed by a bank or PSP.
Identity and provenance
Provenance helps answer “where did this object come from?” without becoming a pointer to current authority. A durable source reference is write-once; additional external identities are carried by appropriate mappings.
A change of system of record is therefore not resolved by silently rewriting an object's historical provenance.