Un espace financier lié peut échouer sans afficher d’erreur. Un résultat peut refléter une nouvelle entrée tandis qu’un autre dépend encore de l’ancienne. Chaque chiffre paraît plausible, mais l’ensemble est incohérent. La conception publique de Calculator traite ce risque : les blocs compatibles peuvent être liés, leurs unités et leur ordre d’exécution doivent être validés, et les changements dépendants peuvent être propagés en une seule transaction plutôt que produire des résultats partiels.
Le danger est un mélange crédible
Un calcul isolé reçoit des entrées, applique une méthode définie et produit une sortie. Lier des blocs crée un graphe de dépendances : une valeur en amont peut alimenter un résultat qui en alimente plusieurs autres. Il ne suffit plus que chaque bloc fonctionne seul ; tous les résultats doivent décrire la même version des entrées.
Si un bloc amont change et qu’une partie seulement du graphe est actualisée, un chiffre en aval peut rester lié à l’état précédent. Sa présentation ne révèle pas l’écart. L’utilisateur risque alors de comparer ou d’interpréter des chiffres qui n’ont jamais appartenu à la même exécution. La protection doit donc se trouver dans l’exécution elle-même.
Valider le graphe avant de l’exécuter
Calculator est conçu pour relier des blocs compatibles, et non des sorties arbitraires. L’unité d’une valeur doit convenir à l’entrée qui la reçoit. L’ordre compte ensuite : un bloc dépendant ne peut produire son résultat courant avant les blocs qui l’alimentent.
La validation transforme ces relations en plan exécutable. Le système doit connaître l’amont, l’aval et l’ordre d’application des méthodes définies. Si une relation requise est invalide, refuser la mise à jour préserve davantage de sens que calculer uniquement le sous-ensemble disponible.
Une transaction crée un avant et un après nets
Une fois le graphe valide, la propagation doit avoir un résultat visible unique : soit tous les blocs concernés terminent avec le nouvel état, soit l’espace conserve son état cohérent antérieur. Une mise à jour en une transaction empêche qu’un résultat intermédiaire paraisse définitif.
Cela ne garantit ni la justesse de chaque formule ni la pertinence de chaque hypothèse. La transaction résout un problème plus précis : tous les résultats dépendants affichés appartiennent à la même mise à jour acceptée. La reproductibilité et la trace du moteur offrent ensuite un objet stable à examiner.
L’historique doit conserver le contexte
Calculator est conçu autour d’espaces persistants, de blocs réutilisables et d’un historique d’exécution, avec entrées, sorties, avertissements et traces réunis. Ce contexte montre quelles entrées ont été utilisées, quelles opérations ont eu lieu et comment les résultats dépendent les uns des autres.
Il clarifie aussi la place d’une explication générée. Viotus sépare les moteurs financiers déterministes du langage généré. Une explication peut faciliter la lecture, mais elle n’est pas la trace et ne décide pas de la réussite d’une mise à jour. Cette responsabilité appartient au graphe, aux règles de validation et au moteur contrôlé.
Un test pratique pour un logiciel de calcul lié
Demandez si le système valide la compatibilité, fixe l’ordre avant l’exécution et affiche ensemble tous les résultats concernés. Si l’un d’eux échoue, évite-t-il de présenter une actualisation partielle comme terminée ? Vérifiez aussi qu’il conserve les entrées, sorties et traces nécessaires à la révision.
Calculator est en cours de développement comme espace financier modulaire de bureau où des résultats compatibles pourront être liés et l’historique consulté. Il n’est pas disponible au téléchargement. Son principe public donne néanmoins un bon critère : un espace lié doit représenter un seul état de calcul, et non un assemblage convaincant d’anciennes et de nouvelles réponses.