Architecture — TENIR

En une phrase

Cette page explique comment TENIR imagine le passage d’une demande à une action réelle : ce qui est proposé, ce qui est vérifié, ce qui est effectivement envoyé et ce qui peut encore rester inconnu. C’est une carte de conception, pas la preuve qu’un système client fonctionne déjà ainsi.

Comment lire cette page

Vous cherchez l’idée : commencez par les trois piliers.
Vous cherchez le fonctionnement : lisez les cinq niveaux et les quatre fonctions.
Vous cherchez une preuve de version : consultez plutôt la page Statut.
Vous cherchez un exemple : ouvrez les démonstrations, qui restent des simulations lorsque cela est indiqué.

Statut du dessin. Classe : illustrative only. Le document source se dit illustratif. Il n’est pas le schéma normatif, ni le YAML du catalogue, ni un rapport d’audit complet. Là où il nomme V « volatilité », la ligne antérieure dit « vitesse ». KB3 ne reformule pas V et interdit de renommer en silence un champ du contrat machine. Le dessin du runtime est conservé. Cette page ne choisit pas un nom souverain pour V.

KB3, les extensions, le code

KB3 est la ligne de rendu doctrinale instituée et active. C’est une couche documentaire, hors du code. Il rend le sens ; il ne crée pas de sens souverain et n’est pas une constitution. Les services ou applications spécialisés l’enveloppent ou l’étendent : ils s’appuient sur KB3 et ne doivent pas le redéfinir. Cette discipline est celle de la politique d’extensions gouvernées et des espaces de noms. TENIR-Gov, ligne IronOmega, est une implémentation du plan de contrôle d’exécution. Elle doit s’aligner sur KB3. Elle n’est pas KB3. Cette page ne cite aucun chemin de code comme module KB3.

Trois piliers de l’écosystème technique

Théorie

Les textes posent le diagnostic et la séparation. Ils disent pourquoi gouverner l’exécution n’est pas réduire le problème à un moteur de politiques.

Standard REG

REG Core pour les invariants. REG+ pour les profils, les hypothèses et les règles de compatibilité. Le profil σ est un contrat. Les invariants I* sont les primitives.

Runtime TENIR-Gov

Implémentation de référence. Elle évalue, engage, enregistre. Elle ne redéfinit pas le canon.

Cinq niveaux

Niveau 0

Règle métier. Formulée par l’équipe ou le régulateur. Exemple donné : ne pas double-exécuter un paiement. Complète dans son registre, pas encore exécutable.

Niveau 1

Contrainte réglementaire. Le document cite, comme exemples, l’article 12 de l’EU AI Act et l’article 9 de DORA : obligations de traçabilité, de supervision ou de contrôle. Ce site ne vérifie pas ces articles.

Niveau 2

Acte de médiation. Intention métier plus hypothèses d’infrastructure égale règle substantive. La règle devient dépendante du déploiement.

Niveau 3

REG Core et REG+. Resolve(i, h, R, V) → Profile(σ, I*). Le profil est le contrat. Les invariants sont exécutables.

Niveau 4

Runtime. Evaluate produit un verdict. Commit tente la mutation. Record produit une preuve reconstructible.

La ligne antérieure décrit la même séparation en trois couches d’implémentation : interprétative, constitutionnelle, gouvernance. Le principe qu’elle formule : le modèle propose, la couche constitutionnelle adjudique, la couche de gouvernance applique, l’humain responsable reste comptable. KB3 exige de garder cette asymétrie visible. Une explication assistée par modèle ne remplace pas l’adjudication de la posture, de la conformité, de la dégradation ou de la trace.

Quatre fonctions

Evaluate()

Fonction pure. Elle lit le profil, les invariants, l’état s et la transition proposée. Elle ne modifie rien. Verdicts : PASS, FLAG, HOLD, HARD_VETO.

Commit()

Fonction mutative. Si elle échoue, le résultat effectif n’est pas un PASS. Issues nommées : COMMITTED, FAILED_RACE, FAILED_CONSTRAINT, SKIPPED.

Record()

EvidenceRecord : contexte, entrées, résultats, trace de commit, hash, signature. Le contrat vise une preuve qu’un tiers peut rejouer. SHA-256, Ed25519 et JCS sont les moyens nommés, pas une certification obtenue.

Assure()

Service qui observe l’infrastructure et injecte des signaux attestés. Le moteur ne détecte pas lui-même la violation d’une hypothèse de déploiement. Signaux : HYPOTHESIS_VERIFIED, WEAKENED, VIOLATED.

Signaux

Famille	Origine	Nature
S1	Passage proposé	Déclarative. Peut être fausse ou mal formée. Exemples : agent, type d’action, montant, clé d’idempotence.
S2	État métier	Observée. Doit être fraîche. Exemples : ressource disponible, quarantaine, score d’autorité.
S3	Assure()	Attestée. Fraîcheur à vérifier.
S4	Registre durable	Historique. Base de l’idempotence et de la reconstruction.

Ces quatre familles ne sont pas le scénario de laboratoire « S1 — Evidence Lost After Commit ». Le même identifiant désigne, selon le document, une famille de signaux ou un cas de conformance. Les deux usages coexistent. Il faut les lire dans leur fichier.

Chaîne

Observation brute des quatre familles.

Normalisation en coordonnées. Une coordonnée absente devient unmeasured, jamais une valeur favorable.

Score continu. Le score n’est pas le verdict.

Invariants discrets, indépendants du score.

Composition : treillis, réactions de signaux du profil, fraîcheur.

Commit, seulement si la mutation est autorisée.

EvidenceRecord.

Après coup : classe de réversibilité τ⁻¹ et EVP. Rétrospectif. Sans droit d’écriture sur le verdict.

Double noyau

Le double noyau n’oppose pas « structurel » et « substantif ». Il sépare un score continu et une membrane d’invariants discrets. Aucun invariant ne lit le score.

Score

S = K / (P · V + ε)

Dans ce dessin, V est appelé volatilité. La ligne antérieure l’appelle vitesse. Les deux noms restent visibles. Les seuils τ_pass et τ_block du dessin sont des paramètres du runtime, pas les postures NORMAL / CAUTION / HOLDING-FIRST. PASS, FLAG, HOLD et HARD_VETO sont des dispositions, pas ces postures.

Membrane

Exemples cités : I1 permis à usage unique, I2 liaison d’engagement, I6 pas d’admission sous quarantaine, I8 budget agrégé, I9 cohérence temporelle de trajectoire. La liste complète dépend du profil.

Si l’un dit HARD_VETO → HARD_VETO
sinon si l’un dit HOLD → HOLD
sinon si l’un dit FLAG → FLAG
sinon → PASS

Ensuite, une réaction explicite du profil peut encore modifier la décision. Sans règle dans σ, un signal est ignoré. Exemple donné : HYPOTHESIS_VIOLATED frais peut imposer HARD_VETO.

États, à part des verdicts

Le verdict autorise, suspend ou refuse. L’état opérationnel décrit la vie de l’opération : CREATED, RESERVED, DISPATCHING, puis CONFIRMED ou FAILED, avec UNKNOWN, HOLD et ESCALATED pour l’incertitude. Un fournisseur silencieux n’est pas un succès.

Preuve et après-coup

L’EvidenceRecord sépare le contexte d’évaluation, les entrées, les résultats — dont le détail par invariant, pas un booléen global —, la trace de commit et l’intégrité. τ⁻¹ classe PRE_COMMIT, EXACT_INVERSE, COMPENSATION, IRREVERSIBLE, INDETERMINATE. INDETERMINATE n’est pas IRREVERSIBLE : l’ignorance n’est pas la preuve d’un non-retour. EVP distingue valeur visée, valeur réalisée, perte d’exécution et friction rapportée à part. Le dépôt tenir_governance dit qu’EVP lit les enregistrements sans chemin d’écriture vers le verdict.

Démonstration du plan de contrôle

Trois artefacts accompagnent ce dessin. Ils sont illustrative only. Leurs verdicts PASS, FLAG, HOLD et HARD_VETO sont des dispositions d’exécution. Ils ne remplacent pas les postures NORMAL, CAUTION et HOLDING-FIRST. Le HOLD d’une opération n’est pas la posture HOLDING-FIRST.

Le dessin illustratif, tel que fourni.
Le parcours interactif, titré TENIR Governance, badge REG+ v5.6.0.
La démo du plan de contrôle, six scènes, en anglais dans l’artefact.

La démo dessine deux noyaux, puis un treillis. Le noyau 1 calcule S = K / (P·V + ε). Le paramètre d’appel montré s’appelle velocity. Le parcours interactif écrit, pour la même lettre, « Velocity / Volatility ». KB3 ne reformule pas V. Cette page ne choisit pas un nom. Le noyau 2, dans la démo, vérifie les invariants I3 à I9. Le parcours interactif liste I1, I2, I3, I4, I6, I7, I8 et I9, et ne nomme pas I5. Les deux listes restent visibles. Aucun invariant ne lit le score.

Le treillis de la démo et du parcours est le même que celui du dessin : HARD_VETO l’emporte, puis HOLD, puis FLAG, sinon PASS. Un score élevé ne garantit pas PASS. Si un noyau échoue, si une donnée manque, ou si l’issue est indéterminée, la démo dit que la composition produit HOLD, jamais PASS.

Les six scènes, attribuées à la démo et non rejouées ici :

Opération admissible. Un paiement de 10 sur une capacité de 100. Le noyau de score renvoie FLAG, la membrane PASS, la composition FLAG, l’état RESERVED, puis CONFIRMED après dispatch. La clé d’idempotence est réclamée à CREATED, avant l’évaluation.
Doublon bloqué. La même clé, soumise encore, reçoit HARD_VETO. La reprise passe par resume_existing(), pas par une nouvelle adjudication.
Cycle de HOLD. Suspension par opération, avec τ_K, distincte de QUARANTINE_LOCK, qui bloque toute admission pour une entité. Sorties montrées : RESERVED si la preuve suffit, ESCALATED vers un officier du risque, FAILED si τ_K expire. ESCALATED n’a pas de sortie automatique par le temps. L’expiration dans cet état produit UNKNOWN, pas une résolution. Ce HOLD est un état d’opération.
Mémoire ou persistance. Sans store_path, un redémarrage perd la réclamation et la seconde adjudication peut revenir FLAG. Avec un magasin, elle revient HARD_VETO. require_persistence=True sans chemin lève ValueError. Depuis le correctif cité par la démo, l’absence de magasin émet un UserWarning.
Délai, puis réconciliation. Un timeout de fournisseur mène à UNKNOWN, pas à FAILED. UNKNOWN n’est pas terminal. La réconciliation montrée peut confirmer que l’effet a eu lieu. Traiter le silence comme un échec pourrait doubler l’effet.
Frontière de garantie. Au plus un dispatch par la porte de gouvernance, sur un seul hôte. La composition fail-closed et les invariants obligatoires sont locaux. La coordination inter-hôtes demande une infrastructure distribuée. L’effet externe exactly-once dépend du fournisseur. L’intégrité d’un artefact PyPI dépend de l’écosystème d’empaquetage. Une décision de gouvernance ne prouve pas, à elle seule, qu’un effet externe a eu lieu exactement une fois.

Le parcours interactif ajoute, comme limites qu’il appelle lui-même ouvertes : reconcile_commit() peut violer I8 en ajoutant au committed sans retirer du reserved ; time.time() dans des méthodes @replicated ; pas de validation des montants négatifs ou NaN ; magasins durables non atomiques ; vérificateur de linéarisabilité trop court ; pickle de pysyncobj sans authentification ; formule de quorum f+1 non générale ; Raft essayé sur localhost seulement, preuves auto-attestées, pas de tolérance byzantine. Ce site ne rejoue pas ces défauts. Il ne les déclare pas clos. La page Statut garde l’audit F-01, F-02 et F-03 du dessin illustratif.

Pièges que le dessin demande d’éviter

Le catalogue des configurations n’est pas le service Assure.
Une interface ConsensusBackend, et l’implémentation Raft 5.6.0, ne sont pas une preuve de consensus en environnement hostile.
Un score élevé ne garantit pas PASS. Un invariant peut imposer HARD_VETO seul.
admissible_structural n’implique pas effective_guarantee_demonstrated.

L’audit porté par ce document sur la 5.6.0 est résumé dans la page Statut.