Standard proposé · REG · brouillons gelés

Le standard

Runtime Execution Governance (REG) propose des exigences pour la frontière où une action peut devenir un effet, et les preuves qui vont avec. L’architecture qui les réalise reste distincte.

Sources et contexte de lecture

RFC-0 à RFC-7 dans reg-conformance ; spec.md v0.3.1 ; KB3, séparation posture et exécution

Rendu public simplifié, lecture du 19 octobre 2026. KB3 : ligne de rendu doctrinale instituée et active. Elle rend le sens ; elle n’est pas le code, ni une constitution. KB2 : ligne antérieure. Ce site ne certifie aucune implémentation. Lire le statut détaillé →

En une phrase

REG est une proposition de règles pour décider si une action sensible peut partir et pour garder la trace de cette décision. Ce n’est ni une certification, ni un produit installé chez un client, ni la preuve qu’un fournisseur externe a bien produit l’effet attendu.

Ce que cette page vous aide à distinguer

  • La proposition : les RFC décrivent ce qu’un système devrait vérifier.
  • Le logiciel : TENIR-Gov est une implémentation publiée, avec un périmètre précis.
  • La preuve : les tests et simulations montrent seulement ce qu’ils ont réellement couvert.
  • La réalité externe : une autorisation locale ne confirme pas à elle seule l’effet chez le fournisseur.

Le mantra de RFC-0, daté du 3 octobre 2026, statut « Proposed Standard (Frozen Draft) », est : « The agent proposes. The membrane decides. Authorised / Admissible. » L’origine déclarée du texte est la convergence de TENIR-Gov, CCEAF et CommitGate. Les dépôts publics lus ne documentent pas CCEAF ni CommitGate au-delà de cette ligne.

Ce que REG n’est pas. Ce n’est pas KB3, ni la ligne antérieure, ni TENIR 2.0. KB3 est la ligne de rendu doctrinale instituée et active, hors du code. REG est le standard d’exécution. TENIR-Gov doit s’aligner sur KB3 ; il ne le constitue pas. Une disposition PASS n’est pas la posture NORMAL. Un mode d’exécution — shadow-passive, shadow-critical, enforce — n’est pas non plus une posture : s’il apparaît, c’est un champ séparé. Le symbole τ du faisceau TAU n’est pas le τ de la transition proposée, ni la fenêtre τ_K.

Lexique de RFC-0

  • Frontière d’exécution. Là où une action conséquente peut devenir un effet externe.
  • Action conséquente. Ce qui modifie un état externe, déplace de la valeur, ou produit un effet qui n’est pas trivialement réversible. Dans le doute, elle est conséquente.
  • Membrane. La surface qui intercepte ces actions avant la frontière. Le mot est technique dans les RFC. Il n’est pas un synonyme de la posture TENIR.
  • Fail-closed. En cas d’incertitude, d’expiration ou de panne, l’action est bloquée.

Trois dimensions indépendantes composent l’admissibilité : la standing (l’acteur a-t-il encore l’autorité), la structure (l’action est-elle compatible avec l’état), le commit (la décision peut-elle devenir exactement cet effet sans perdre son intégrité). Le standard n’impose pas un pipeline séquentiel. Si les dispositions divergent, la plus restrictive l’emporte. HARD_VETO l’emporte sur tout.

DispositionInstruction
PASSAutoriser, borné par valid_until et par la dérive d’état. Un PASS n’est pas permanent.
FLAGAutoriser seulement sous une condition ou une supervision explicite. Jamais un allow nu.
HOLDSuspendre. Déclenche la fenêtre τ_K.
HARD_VETORefuser pour cette évaluation. Produit un reçu de refus signé.

Cycle et τ_K

  1. Pré-exécution : la demande porte l’intention, la cible, les effets attendus, un instantané d’état.
  2. Autorisation conditionnelle : verdict et enveloppe d’octroi.
  3. Exécution supervisée : si un HARD_VETO survient, l’exécution s’arrête ou passe dans un état sûr.
  4. Clôture : un manifeste de preuve ancre le cycle.

τ_K est la fenêtre maximale de résolution humaine d’un HOLD. RFC-0 dit qu’elle se dérive d’accords de niveau de service existants. Elle ne s’invente pas. À l’expiration, la politique pré-déclarée s’applique. Le défaut est fail-closed. Un mode dégradé n’est admis que s’il a été déclaré et s’il préserve l’invariant.

RFC-2 fixe S = K / (P × V + ε) comme modèle de référence de l’admissibilité structurelle, avec d’autres modèles permis s’ils respectent les contraintes épistémiques, d’invariant et de conservatisme. L’incertitude contracte la région admissible. L’absence de preuve qu’un invariant tient n’est pas la preuve qu’il tient. Dans ce RFC, V est la volatilité et l’irréversibilité, pas la vitesse nommée par la ligne antérieure. KB3 ne fond pas les deux noms.

La série

RFCTitreStatut dans l’arbre
RFC-0Constitution du standardv0.2, gelé, 3 octobre 2026
RFC-1Enveloppe d’octroi et protocolev0.1, gelé
RFC-2Admissibilité structurellev0.1, gelé
RFC-3Standing et continuité d’autoritév0.1, gelé
RFC-4Commit et preuve d’exécutionv0.2, gelé, 2 octobre 2026
RFC-5Vivacité et opérationnalisationv0.1, gelé
RFC-6Sécurité, transport, cryptographiev0.1, gelé
RFC-7Suite de conformancev0.1, gelé

RFC-0 sépare l’obligation normative du statut d’implémentation. Si la référence n’a pas encore réalisé une obligation, elle est marquée écart d’implémentation. Elle ne réécrit pas l’obligation. Le fichier spec.md est titré « REG Conformance Spec — v0.3.1 » (29 septembre 2026). Le runner se décrit « v0.3.2 ». Le message du dernier commit lu dit « v0.5.0 ». Trois étiquettes coexistent. Ce site ne les fond pas en une seule version.

Le manuscrit Governing the Unobserved, v7.1 du 12 octobre 2026, est un working paper. Il étudie la membrane après l’admission, quand l’effet peut rester inobservé. Il ne revendique ni la sûreté générale sous concurrence, ni la certification d’une passerelle de production. DOI de version : 10.5281/zenodo.23314839. Le DOI concept est 10.5281/zenodo.23270928.