Contrats économiques
Le contrat économique V1 permet à une extension de déclarer ce qu’elle sait sur les coûts et d’observer les usages ou montants réellement disponibles. Il constitue la mémoire économique de l’exécution ; il ne crée pas encore un moteur universel de budget ou d’approbation.
Ce que couvre la V1
Le champ optionnel economics appartient au contrat de l’exécutable qui porte l’intention : Node ou Tool. Il n’est pas hérité automatiquement d’une autre interface même lorsque les deux utilisent le même service.
Le schema actuel est versionné avec schema_version: 1 et peut décrire trois capacités complémentaires : declaration, observation et resolution.
L’absence de contrat économique ou d’observation ne signifie jamais coût nul.
Déclaration économique
La déclaration décrit ce qui peut être connu avant ou indépendamment du coût réel observé.
| Élément | Contrat |
|---|---|
perspectives | Points de vue économiques nommés. Leur connaissance est unknown, zero, amount ou upper_bound. |
amount | Safe integer dans l’unité mineure de la devise, uniquement pour amount et upper_bound. |
currency | Code devise majuscule associé au montant déclaré. |
usage | Couples metric/unit que l’exécutable sait éventuellement observer. |
upper_bound signifie une exposition maximale déclarée, pas une garantie absolue de facture maximale.
Observations de coût
Une observation peut transporter des usages, des montants ou une référence provider qui permettra un rapprochement ultérieur.
factdécrit un fait autonome ;deltadécrit une variation à appliquer à une série ;cumulativedécrit la valeur cumulative d’une série et exige unseries_keystable.
Les montants observés indiquent une base engaged ou observed, une perspective, un montant entier et une devise. Un provider_reference peut relier le fait à l’identité de facturation du partenaire ; un timestamp provider peut préciser quand le fait s’est produit.
Causalité et attribution
Chaque coût possède un propriétaire causal unique : l’opération qui consomme la ressource ou crée l’obligation économique. Les totaux d’un Process ou d’un Agent sont des agrégations de leurs descendants, pas de nouvelles dépenses.
Les parents agrègent les coûts de leurs descendants ; l’opération qui consomme réellement la ressource reste l’unique propriétaire causal du coût.
Ne comptez pas deux fois le même coût parce qu’un Tool agrège une opération enfant. Déclarez près de l’intention ; observez près de l’effet réellement connu.
Corrections et faits tardifs
Un fournisseur peut envoyer un coût ou une correction après la fin fonctionnelle de l’exécution. La V1 conserve la parenté économique afin que ces faits restent attribuables sans rouvrir le Process ou l’Agent Run.
Une observation tardive corrige les projections économiques ; elle ne modifie pas rétroactivement le résultat métier ou les snapshots de décision de l’exécution.
Ce que la V1 ne promet pas
- pas de budget universel obligatoire ;
- pas d’approbation automatique avant chaque dépense ;
- pas de maximum calculable pour toute opération ;
- pas de coût nul implicite lorsqu’une donnée manque ;
- pas de politique que l’extension pourrait choisir pour contourner celle d’un parent.
Les déclarations de coûts ne déclenchent pas automatiquement de plafond de dépenses ni d’approbation. Prévoyez explicitement les contrôles nécessaires avant une opération payante.