Preuves
Des faits,
pas des adjectifs.
Une garantie sans artefact est une déclaration. Cette page ne cite que des contrôles exécutés, chacun relié à la pièce qui le documente. Ce qui n’a pas été exercé n’y figure pas.
exercice du 17/08/2026 · REQ-064 · AUD-000001
Trois faits, trois artefacts
- 21/21
- empreintes identiques à l’exercice de restauration du 17 août 2026
- 114 s
- pour restaurer la base depuis un dépôt hors-site chiffré
- 0
- suppression aboutie du journal d’audit à l’exercice du 17 août 2026
02
Chaque garantie tient à une pièce
-
Journal d’audit en ajout seul
La suppression, la modification et la troncature d’une entrée du journal d’audit sont rejetées par des déclencheurs du moteur de base de données. Deux rôles ont été éprouvés le 17 août 2026, sur deux bases distinctes — nous le disons plutôt que de les confondre. Sur la base de production, sous le rôle applicatif, qui n’est pas propriétaire des tables : la modification et la troncature sont refusées par les permissions, et le désarmement du déclencheur par la propriété — « must be owner of table ». Sur un clone jetable de cette même base, sous le rôle superutilisateur : la suppression a été rejetée par le déclencheur lui-même — « audit_events is append-only : DELETE is not permitted ». Aucune tentative n’a abouti. Cette garantie tient à une condition d’exploitation, que nous énonçons plutôt que de la taire : l’application se connecte sous un rôle non propriétaire ; un propriétaire de table, lui, pourrait désarmer le déclencheur avant d’écrire.
Artefacts : rapports d’exercice b2-p5-non-owner-role-2026-08-17 (rôle applicatif non propriétaire, base de production) et b2-p2-pitr-oldest-antitest-20260817, § 3.3 (rejet du déclencheur sous superutilisateur, clone jetable) — dépôt hospitality-lcos, docs/audit.
-
Restauration exercée, pas promise
Le 17 août 2026, la base a été restaurée à un instant donné depuis un dépôt hors-site chiffré, en 114 s. Les 21 tables du périmètre ont rendu 21/21 empreintes identiques aux attendus, 0 divergence. La portée mesurée est celle de l’exercice : serveur survivant, outillage en place.
Artefact : journal d’exercice b2-drill-pitr-20260817221349.json (empreintes canoniques, cardinalités, durée mesurée).
-
Approbations par matrice de rôles
Le niveau de risque d’un contrat détermine les rôles dont la décision est exigée, jusqu’au conseil externe et à la direction pour les niveaux les plus élevés. La ratification d’une règle d’approbation émet un événement journalisé (APPROVAL_RULE_RATIFIED) ; un approbateur ne peut pas approuver sa propre demande.
Artefact : suite de tests de bout en bout de la matrice d’approbation (module 35), qui vérifie l’événement et son entrée au journal d’audit.
-
Erreurs stables, corrélées
Un refus du système porte un code d’erreur stable : la même cause produit le même code, accompagné d’un identifiant de corrélation qui relie la réponse à son entrée de journal.
Artefact : catalogue d’erreurs stables de la spécification maîtresse (§51) ; les suites de tests du dépôt vérifient les codes rendus.
03
La portée, dite d’avance
Ces preuves datent et se rejouent. Elles couvrent le périmètre exercé à leur date — pas davantage — et chaque nouvel exercice remplace une déclaration par une mesure.
LCOS conduit une seule chaîne : le tiers, l’affaire, le dossier, le contrat, l’approbation. Ce qu’il ne fait pas se nomme ici. Il ne rédige ni ne génère aucun document ; il ne tient ni bibliothèque de clauses, ni gabarit de contrat, ni comparaison de versions ; il ne signe pas et ne s’adosse à aucun prestataire de signature ; il ne conserve aucun fichier. La spécification compte quarante modules — elle se nomme, et le compte se refait : `docs/superpowers/specs/2026-08-12-hospitality-lcos-master-spec.md` au dépôt du produit. Le dépôt, lui, porte neuf modules applicatifs, qui s’énumèrent : tiers, affaires, dossiers, contrats, approbations, matrice d’approbation, pare-feu éditorial, journal d’audit, identité. Ces deux comptes ne se soustraient pas l’un de l’autre, et nous ne les soustrayons pas : un module du dépôt ne recouvre pas terme à terme un module de la spécification. Ce qui reste au dossier — droits média, finance, protection des données, exploitation en service partagé, international — n’est donc pas chiffré ici. L’authentification d’entreprise repose sur un adaptateur réel, qui vérifie le jeton contre le jeu de clefs publiques du fournisseur ; le raccordement à un annuaire d’entreprise, lui, reste à construire. Le cycle de vie du tiers s’arrête à sa création et à sa lecture. Nous préférons l’écrire ici plutôt que le laisser découvrir.
REQ-064 · 17/08/2026
04
Le journal d’audit, en ajout seul
Aucune de ces lignes n’a été effacée : la suppression, la modification et la troncature sont rejetées par le moteur de base de données lui-même. Le 17 août 2026, deux rôles ont été éprouvés sur deux bases : le rôle applicatif, qui n’est pas propriétaire des tables, sur la production, et le rôle superutilisateur sur un clone jetable de celle-ci. Aucune tentative n’a abouti.
- 2026-08-17T22:13:49Z drill-pitr-20260817221349 Point témoin créé, puis restauré depuis le dépôt hors-site chiffré.
- 2026-08-17T22:15:45Z 21/21 · 114 s Base restaurée : empreintes identiques aux attendus, 0 divergence.
- 2026-08-17T22:16:27Z b2-drill-oldest-20260817221627 Sauvegarde la plus ancienne rejouée à son tour.
Référence d’une écriture du journal : AUD-000001. Ratification d’une règle d’approbation : APPROVAL_RULE_RATIFIED (MODULE 35). Exigence de résilience : REQ-064.