Architecture globale, explicative et visuelle : théorie, standard, runtime, signaux structurels, chaîne de transformation, preuve, audit et catalogue de configurations.
TENIR / REG repose sur une séparation stricte entre la théorie, le standard et le runtime. Cette séparation est essentielle : elle évite de confondre ce qui est conçu, ce qui est exigé, et ce qui est exécuté.
Les papiers posent le diagnostic, la séparation conceptuelle et la formalisation. Ils expliquent pourquoi la gouvernance runtime ne peut pas être réduite à un simple policy engine.
Le standard définit ce que le système doit garantir. Il est séparé en REG Core pour les invariants, et REG+ pour les profils, hypothèses et règles de compatibilité structurelle.
TENIR-Gov est l’implémentation de référence. Il exécute le standard : il évalue, commit, enregistre la preuve, et intègre les signaux d’infrastructure.
Le modèle de résolution descend de la règle métier jusqu’à l’exécution machine. Aucune étape ne doit être sautée : une intention métier ne devient exécutable qu’après traduction, résolution en profil, puis projection en invariants runtime.
Exprimée par l’équipe fonctionnelle ou le régulateur. Exemple : « Ne pas double-exécuter un paiement. » Elle est complète dans son registre, mais pas encore exécutable.
Exemple : EU AI Act Art. 12, DORA Art. 9. La compliance traduit l’exigation réglementaire en obligation de traçabilité, de supervision ou de contrôle.
L’architecte de gouvernance traduit :
Intention métier + Hypothèses d’infrastructure = Règle substantive
C’est l’étape où la règle devient dépendante du contexte de déploiement.
La règle substantive est résolue en profil σ, puis décomposée en invariants I*. Le profil est le contrat ; les invariants sont les primitives exécutables.
La membrane exécute : Evaluate() produit un verdict, Commit() applique la mutation,
Record() produit la preuve reconstructible.
Le runtime sépare strictement l’adjudication, la mutation, la preuve et l’assurance. Cette séparation est au cœur de la robustesse de l’architecture.
Fonction pure. Elle lit le profil, les invariants, l’état s
et la transition proposée τ. Elle retourne un verdict.
Elle ne modifie rien.
Fonction mutative. Elle tente d’appliquer les effets de bord si le verdict l’autorise.
Si le commit échoue, le verdict effectif n’est pas PASS.
Produit l’EvidenceRecord : contexte, entrées, résultats, trace de commit, hash canonique et signature. La preuve doit être reconstructible par un tiers.
Service externe qui observe l’infrastructure et injecte des signaux attestés dans l’état. Le moteur ne détecte pas lui-même les violations d’hypothèses.
Evaluate() juge, Commit() agit, Record() prouve.
Les signaux sont les faits bruts lus par le moteur. Ils proviennent de quatre familles distinctes, chacune ayant une origine, une nature et un niveau de confiance différents.
| Famille | Origine | Nature | Exemples | Lecture critique |
|---|---|---|---|---|
| S1 — Signaux de transition | Passage τ proposé |
Déclaratifs | agent_id, action_type, amount, idempotency_key |
Peuvent être faux ou mal formés : ils doivent être validés. |
| S2 — Signaux d’état métier | MembraneState s |
Observés | resource.available, quarantine_active, authority_score |
Lus dans l’état ; ils doivent être frais et cohérents. |
| S3 — Signaux d’infrastructure | Service Assure() |
Attestés | HYPOTHESIS_VERIFIED, HYPOTHESIS_WEAKENED, HYPOTHESIS_VIOLATED |
Signés Ed25519 ; leur fraîcheur doit être vérifiée. |
| S4 — Signaux historiques | DurableOperationRegistry | Persistés | state = DISPATCHING, budget_committed = true |
Trace d’exécution ; base de l’idempotence et de la reconstruction. |
Huit niveaux conceptuels, sept étapes de transformation. Chaque étape est distincte, testable, et produit un artefact traçable.
Observation brute : S1 + S2 + S3 + S4.
signaux bruts
Transformation des signaux en coordonnées de géométrie de contrainte.
Une coordonnée absente devient unmeasured, jamais une valeur favorable.
Calcul continu du score de stabilité. Le score n’est pas le verdict.
scoring_resultÉvaluation discrète et indépendante des invariants I1..I9 selon le profil.
membrane_resultLattice + signal reactions du profil σ + fraîcheur des signaux.
composed_decisionMutation réelle si autorisée. Atomique, tracée, réversible ou explicitement échouée.
commit_traceSérialisation canonique de la preuve : contexte, entrées, résultats, commit, intégrité.
EvidenceRecord
Une fois l’opération terminée, deux évaluations indépendantes sont produites :
la classification de réversibilité τ⁻¹ et la mesure de valeur préservée EVP.
Le score est continu, le verdict est discret, l’assessment est rétrospectif.
Il ne faut jamais les confondre. Un score élevé ne garantit pas PASS ;
un invariant peut imposer HARD_VETO à lui seul.
Le double kernel ne signifie pas “structurel vs substantif”. Il sépare un kernel de scoring continu et une membrane discrète d’invariants. La composition des deux produit le verdict final.
K = capacité, P = pression, V = volatilité,
ε = plancher de stabilité. Le score est ensuite comparé à des seuils.
Chaque invariant est évalué indépendamment. Aucun invariant ne lit le score.
Chaque résultat est traçable : invariant_id, result, reason.
| Invariant | Lecture |
|---|---|
I1 single-use-permit | permis non consommé |
I2 commit-binding | liaison autorisation / tentative |
I6 no-admission-under-quarantine | absence de quarantaine |
I8 aggregate-budget | capacité disponible suffisante |
I9 trajectory-temporal-consistency | cohérence temporelle |
Ensuite, les signal reactions du profil σ peuvent modifier la décision composée.
Exemple : si HYPOTHESIS_VIOLATED est présent et frais, alors HARD_VETO.
Sans règle explicite dans σ, le signal est ignoré.
Les verdicts d’admissibilité ne doivent pas être confondus avec les états opérationnels. Le verdict autorise, suspend ou refuse ; l’état opérationnel décrit la vie réelle de l’opération.
| Verdict | Signification |
|---|---|
| PASS | Autorisé sans réserve. |
| FLAG | Autorisé avec alerte ou surveillance renforcée. |
| HOLD | Suspendu : ni autorisé ni refusé, en attente d’évidence ou de résolution. |
| HARD_VETO | Refus catégorique. |
Les états d’incertitude sont essentiels : un provider silencieux ne doit jamais être interprété comme un succès.
L’EvidenceRecord est l’artefact produit après évaluation et commit. Il doit permettre à un auditeur indépendant de reconstruire le verdict.
| Section | Contenu | Usage d’audit |
|---|---|---|
| evaluation_context | profile_id, profile_version, evaluator_version, catalog_version, hypothèses |
Reproductibilité : quel profil a produit le verdict ? |
| inputs | state_snapshot, transition_proposal, signaux |
Reconstruction : avec quelles entrées ? |
| results | verdict, invariant_details[] |
Traçabilité : pourquoi ce verdict ? |
| commit_trace | commit_result, hashes pré/post commit |
Intégrité de la mutation : a-t-elle réellement eu lieu ? |
| integrity | current_hash, signature, previous_hash |
Intégrité et authenticité de la preuve. |
invariant_details n’est pas un booléen global.
C’est une liste de résultats individuels. Un auditeur doit pouvoir lire, par exemple :
I8: HARD_VETO (requested 80000, available 70000).
Après coup, on évalue séparément la réversibilité et la valeur préservée. Ces deux dimensions ne s’impliquent pas mutuellement.
| Classe | Signification |
|---|---|
PRE_COMMIT | Annulée avant effet. |
EXACT_INVERSE | Effet réversible sans perte. |
COMPENSATION | Effet réversible avec perte mesurée. |
IRREVERSIBLE | Aucun retour valide. |
INDETERMINATE | Information insuffisante. |
INDETERMINATE n’est pas IRREVERSIBLE.
Un échec de vérification prouve l’ignorance, pas l’irréversibilité.
Les coûts de friction sont rapportés séparément, pas soustraits de EVP Net. Cela préserve la traçabilité des pertes.
Le catalogue valid-configurations-v1.json et les règles compatibility-rules-v1.yaml
définissent l’espace des configurations structurellement admissibles.
9 configurations admissibles.
18 configurations admissibles.
15 configurations admissibles.
| Règle | Clause | Exigence |
|---|---|---|
R1_HOST_CONCURRENCY |
R1a | HOST_SCOPE=mono-process exige CONCURRENCY=thread-lock. |
R1_HOST_CONCURRENCY |
R1b | HOST_SCOPE=mono-host exige file-lock ou distributed-transaction. |
R1_HOST_CONCURRENCY |
R1c | HOST_SCOPE=multi-host exige distributed-transaction ou distributed-consensus. |
R2_CONSENSUS_SCOPE |
R2a | CONCURRENCY=distributed-consensus exige HOST_SCOPE=multi-host. |
R2_CONSENSUS_DEDUP |
R2b | DEDUP_LAYER=distributed-consensus-registry exige HOST_SCOPE=multi-host. |
R2_CONSENSUS_DEDUP |
R2c | DEDUP_LAYER=distributed-consensus-registry exige CONCURRENCY=distributed-consensus. |
R3_LOCAL_DEDUP |
R3a | DEDUP_LAYER=local-registry exige mono-process ou mono-host. |
admissible_structural = true ne signifie pas
effective_guarantee_demonstrated = true.
Une configuration peut être structurellement cohérente sans que l’implémentation ait effectivement démontré la capacité correspondante.
L’audit montre que la chaîne de transformation est conceptuellement saine, mais que certains points d’entrée/sortie sont compromis dans la v5.6.0.
| Étape | État | Défaut identifié | Impact |
|---|---|---|---|
| 1. Normalisation | F-02 | register_resource() réinitialise l’état existant. |
Les signaux S2, notamment resource.available, peuvent devenir faux après crash/reload. |
| 2. Scoring | OK | Déterministe. | Le score est reconstructible si les coordonnées sont correctes. |
| 3. Invariants | OK | Évaluation discrète testable. | Chaque invariant peut être audité individuellement. |
| 4. Composition | OK | Lattice déterministe. | La composition reste prévisible si les entrées sont saines. |
| 5. Commit | F-01 | reconcile_commit() peut forcer une mutation sans re-vérifier la capacité. |
Un état RELEASED peut devenir COMMITTED, violant I8. |
| 6. Record | OK | Schéma JSON valide. | L’EvidenceRecord est conforme structurellement. |
| 7. Assessment | F-03 | LinearizabilityChecker invalide. | Les preuves LIN peuvent contenir des faux positifs. |
La release durcie doit corriger les points critiques : réconciliation sécurisée, persistance non destructive, validateur de linéarisation fiable, et durcissement du transport consensus.
La chaîne est saine sauf aux points où l’intégrité des entrées, de la mutation ou de la validation post-hoc est compromise. Le standard est bon ; l’implémentation doit être durcie.
Ces confusions reviennent souvent dans les discussions techniques ou les revues. Les éviter est indispensable pour parler correctement de TENIR / REG.
Le double kernel sépare le continu (scoring) du discret (invariants). Ce n’est pas une opposition entre structurel et substantif.
Le catalogue décrit les axes et règles structurelles.
Assure() est le service dynamique qui observe l’infrastructure et produit des signaux attestés.
L’interface ConsensusBackend est spécifiée par REG, mais l’implémentation 5.6.0 doit être durcie.
Elle ne constitue pas encore une preuve de consensus fiable en environnement hostile.
Un score élevé ne garantit pas PASS. Un invariant peut imposer HARD_VETO.
Inversement, un score bas peut produire FLAG si les invariants passent.
Cartographie des dépôts et état actuel de la release.
Runtime : membrane, gouverneur, ledger, implémentation consensus. C’est le code qui exécute le standard.
Standard : RFC REG Core, schémas JSON, catalogue, règles de compatibilité, profils.
Harnais de test : scénarios, tests de robustesse, preuves d’exécution, campagnes de conformance.