Autorité métier
Une extension ne devient jamais source de vérité simplement parce qu’elle peut accéder à un objet. L’autorité décrit qui peut créer un fait, écrire un champ ou faire évoluer un lifecycle ; elle est indépendante de la permission technique d’accès.
L’autorité appartient à un rôle
Ormuz exprime l’autorité par rôle métier — par exemple ormuz, accounting, commerce, fulfilment, psp, bank ou producer — et non par l’identité d’une configuration partenaire particulière.
Un même objet peut donc combiner plusieurs plans d’autorité : un ERP peut posséder la référence comptable d’une facture tandis qu’Ormuz calcule son état de règlement opérationnel.
Les quatre primitives
| Primitive | Question |
|---|---|
creation_authority | Quel rôle peut faire exister l’objet ou une variante stable de cet objet ? |
field_authority | Quel rôle possède chaque champ dans une phase donnée du lifecycle ? |
transition_authority | Quel rôle peut franchir chaque transition d’état ? |
lifecycle_eligibility | Dans quels états l’objet peut-il participer à une opération ou une projection donnée ? |
L’autorité sur un champ peut changer avec la phase du lifecycle. N’ajoutez donc pas un champ simpliste du type owner ou mastership_level à un contrat partenaire.
Conflits et synchronisation
La règle de conflit est déterministe :
- si le champ appartient au rôle externe, la synchronisation peut apporter sa valeur ;
- si le champ appartient à Ormuz, une synchronisation externe ne l’écrase jamais ;
- si le système externe rapporte une valeur différente pour un champ Ormuz-owned, l’opération échoue au lieu de choisir silencieusement un gagnant.
Il n’existe pas de stratégie automatique last writer wins. Faire converger le système partenaire vers une valeur Ormuz-owned est une opération explicite distincte, avec ses propres prérequis et erreurs.
Propositions et observations
L’autorité suit l’initiative, pas le sens financier. Une opération initiée par Ormuz peut commencer comme proposition ou instruction Ormuz-owned avant que le système externe n’établisse le fait final. À l’inverse, un fait qui naît dans un système externe doit être observé et matérialisé depuis une preuve externe légitime.
Cette distinction est particulièrement importante pour les mouvements financiers : un remboursement proposé par Ormuz n’a pas le même contrat qu’un paiement entrant constaté par une banque ou un PSP.
Identité et provenance
La provenance aide à répondre « d’où vient cet objet ? » sans devenir un pointeur d’autorité courant. Une référence source durable est write-once ; les identités externes supplémentaires sont portées par des mappings appropriés.
Un changement de système de référence ne se résout donc pas en réécrivant silencieusement la provenance historique d’un objet.