erotetique 0.1.0__tar.gz
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- erotetique-0.1.0/.claude/settings.local.json +8 -0
- erotetique-0.1.0/.env.example +2 -0
- erotetique-0.1.0/.gitignore +39 -0
- erotetique-0.1.0/LICENCE.md +291 -0
- erotetique-0.1.0/MANIFEST.in +11 -0
- erotetique-0.1.0/PKG-INFO +167 -0
- erotetique-0.1.0/README.md +142 -0
- erotetique-0.1.0/ROADMAP.md +36 -0
- erotetique-0.1.0/bibliographie.json +234 -0
- erotetique-0.1.0/connaissance/INDEX.md +77 -0
- erotetique-0.1.0/connaissance/WORKFLOW_EROTETIQUE.md +121 -0
- erotetique-0.1.0/connaissance/prompts/EXTRACT_EROTETIQUE.md +135 -0
- erotetique-0.1.0/connaissance/prompts/VALIDATE_EROTETIQUE.md +53 -0
- erotetique-0.1.0/erotetique/__init__.py +42 -0
- erotetique-0.1.0/erotetique/augmenter.py +227 -0
- erotetique-0.1.0/erotetique/classifier.py +199 -0
- erotetique-0.1.0/erotetique/ontology/cq-erotetique.ttl +366 -0
- erotetique-0.1.0/erotetique/ontology/erotetique-shapes.ttl +156 -0
- erotetique-0.1.0/erotetique/ontology/erotetique.ttl +763 -0
- erotetique-0.1.0/erotetique/server.py +234 -0
- erotetique-0.1.0/erotetique/soundness.py +145 -0
- erotetique-0.1.0/erotetique/valorizer.py +143 -0
- erotetique-0.1.0/pyproject.toml +68 -0
- erotetique-0.1.0/scripts/README_RAG.md +79 -0
- erotetique-0.1.0/scripts/rag_erotetique.py +388 -0
- erotetique-0.1.0/tests/__init__.py +0 -0
- erotetique-0.1.0/tests/conftest.py +31 -0
- erotetique-0.1.0/tests/fixtures/questions-reelles.json +172 -0
- erotetique-0.1.0/tests/test_classify.py +126 -0
- erotetique-0.1.0/tests/test_cq.py +291 -0
- erotetique-0.1.0/tests/test_integration.py +99 -0
- erotetique-0.1.0/tests/test_ontology_integrity.py +93 -0
- erotetique-0.1.0/tests/test_prompt_generation.py +145 -0
- erotetique-0.1.0/tests/test_real_questions.py +113 -0
- erotetique-0.1.0/tests/test_shacl_validation.py +149 -0
- erotetique-0.1.0/tests/test_soundness.py +94 -0
- erotetique-0.1.0/tests/test_valorizer.py +98 -0
- erotetique-0.1.0/uv.lock +618 -0
|
@@ -0,0 +1,39 @@
|
|
|
1
|
+
# Python
|
|
2
|
+
__pycache__/
|
|
3
|
+
*.py[cod]
|
|
4
|
+
*$py.class
|
|
5
|
+
*.egg-info/
|
|
6
|
+
dist/
|
|
7
|
+
build/
|
|
8
|
+
*.egg
|
|
9
|
+
|
|
10
|
+
# Env
|
|
11
|
+
.venv/
|
|
12
|
+
venv/
|
|
13
|
+
.env
|
|
14
|
+
|
|
15
|
+
# IDE
|
|
16
|
+
.vscode/
|
|
17
|
+
.idea/
|
|
18
|
+
*.swp
|
|
19
|
+
|
|
20
|
+
# OS
|
|
21
|
+
.DS_Store
|
|
22
|
+
Thumbs.db
|
|
23
|
+
|
|
24
|
+
# Heavy files — not in package
|
|
25
|
+
connaissance/livres/
|
|
26
|
+
connaissance/extractions/
|
|
27
|
+
connaissance/transcripts/
|
|
28
|
+
connaissance/index/
|
|
29
|
+
|
|
30
|
+
# Docs (separate from package)
|
|
31
|
+
docs/
|
|
32
|
+
|
|
33
|
+
# Test artifacts
|
|
34
|
+
.pytest_cache/
|
|
35
|
+
.coverage
|
|
36
|
+
htmlcov/
|
|
37
|
+
|
|
38
|
+
# Build cache
|
|
39
|
+
.semut-cache.db
|
|
@@ -0,0 +1,291 @@
|
|
|
1
|
+
# Iterative Knowledge Commons License
|
|
2
|
+
## IKCL — Version 0.1
|
|
3
|
+
|
|
4
|
+
> Explore librement. Itère honnêtement. Partage ce que tu découvres.
|
|
5
|
+
> La connaissance que tu produis enrichit ceux qui viennent après toi.
|
|
6
|
+
> C'est tout le contrat.
|
|
7
|
+
|
|
8
|
+
---
|
|
9
|
+
|
|
10
|
+
## Préambule
|
|
11
|
+
|
|
12
|
+
Nous explorons ensemble ce que signifie développer en dehors des limites héritées.
|
|
13
|
+
|
|
14
|
+
Nous n'utilisons pas les LLM pour plagier des organigrammes de 2015. Nous ne reproduisons pas les structures d'hier avec les outils de demain. Nous cherchons ce qui n'existe pas encore — de nouvelles façons de penser, de concevoir, de co-créer avec une intelligence qui n'est pas humaine mais qui peut l'amplifier.
|
|
15
|
+
|
|
16
|
+
Cette exploration est collective ou elle n'est pas. Ce que tu découvres en pratiquant cette méthode appartient à ceux qui viendront après toi. Pas par obligation morale abstraite — par cohérence avec ce que cette méthode est : un processus vivant, nourri par la friction entre une intention et une réalité.
|
|
17
|
+
|
|
18
|
+
La IKCL formalise cet engagement : tu explores librement, tu en tires de la valeur — et tu partages ce que tu découvres pour enrichir la manière dont nous co-créons avec l'IA. Le registre est ouvert. La chaîne de preuve est publique. L'exploration continue.
|
|
19
|
+
|
|
20
|
+
---
|
|
21
|
+
|
|
22
|
+
## Définitions
|
|
23
|
+
|
|
24
|
+
| Terme | Sens dans cette licence |
|
|
25
|
+
|---|---|
|
|
26
|
+
| **Méthode** | L'ensemble formalisé distribué sous cette licence : ontologie, niveaux, contraintes SHACL, outils de référence — qui livre une instance à chaque praticien |
|
|
27
|
+
| **Instance** | L'environnement d'expérimentation et d'apprentissage reçu par le praticien — autonome, opérationnel dans son contexte, connecté au registre. Le modèle d'ensemble est une **franchise épistémique** : chaque instance est indépendante mais partage le même corpus de connaissance centralisé |
|
|
28
|
+
| **Utilisable** | L'instance produit des résultats exploitables dans un contexte réel, hors phase d'évaluation ou de POC |
|
|
29
|
+
| **Itération** | Toute modification apportée en réponse à un usage réel — code, configuration, règle, processus, prompt |
|
|
30
|
+
| **Delta de connaissance** | Ce qui a motivé l'itération : le problème observé, la décision prise, l'effet constaté — la connaissance sur *comment construire*, pas ce qui a été construit |
|
|
31
|
+
| **Dépôt REX** | La contribution structurée du delta de connaissance dans le registre MCP désigné |
|
|
32
|
+
| **Registre MCP** | Le serveur MCP désigné par la licence comme infrastructure centrale de capitalisation et de redistribution |
|
|
33
|
+
|
|
34
|
+
---
|
|
35
|
+
|
|
36
|
+
## Article 1 — Ce que tu reçois
|
|
37
|
+
|
|
38
|
+
En adoptant cette méthode, tu reçois une instance d'expérimentation et d'apprentissage pour construire des outils de production neurosymboliques et logiciels.
|
|
39
|
+
|
|
40
|
+
Cette instance t'appartient. Ce que tu y construis t'appartient. Ce que tu y produis commercialement t'appartient.
|
|
41
|
+
|
|
42
|
+
Ce qui appartient aux communs : les insights, apprentissages et patterns que tu génères en itérant — la connaissance sur *comment construire*, pas ce que tu construis. C'est cette connaissance qui est centralisée dans le registre et redistribuée à toutes les instances pour faire progresser collectivement l'art de construire des outils de production avec l'IA.
|
|
43
|
+
|
|
44
|
+
---
|
|
45
|
+
|
|
46
|
+
## Article 2 — Déclencheur de l'obligation de retour
|
|
47
|
+
|
|
48
|
+
L'obligation de retour s'active dès que les deux conditions suivantes sont réunies :
|
|
49
|
+
|
|
50
|
+
1. L'**instance** est **utilisable** — elle produit des résultats exploitables dans un contexte réel
|
|
51
|
+
2. Une **première itération** a été réalisée en réponse à cet usage réel
|
|
52
|
+
|
|
53
|
+
L'itération est la preuve que de la connaissance a été produite. Tant qu'aucune itération n'a eu lieu, la méthode est en phase d'évaluation et aucune obligation ne s'applique.
|
|
54
|
+
|
|
55
|
+
---
|
|
56
|
+
|
|
57
|
+
## Article 3 — Objet du retour
|
|
58
|
+
|
|
59
|
+
Tu contribues aux communs le delta de connaissance qui a motivé l'itération. Ce dépôt REX doit contenir au minimum :
|
|
60
|
+
|
|
61
|
+
- **Contexte** : la situation d'usage, le domaine, l'échelle
|
|
62
|
+
- **Observation** : le problème identifié ou l'apprentissage réalisé
|
|
63
|
+
- **Décision** : ce qui a été modifié et pourquoi
|
|
64
|
+
- **Effet** : la conséquence observée — même partielle, même négative, même incertaine
|
|
65
|
+
|
|
66
|
+
Un retour honnête sur un échec vaut autant qu'un retour sur un succès. Les effets non observés encore peuvent être déclarés comme tels.
|
|
67
|
+
|
|
68
|
+
---
|
|
69
|
+
|
|
70
|
+
## Article 4 — Destination et format
|
|
71
|
+
|
|
72
|
+
Le dépôt REX est déposé dans le **registre MCP désigné par la licence**.
|
|
73
|
+
|
|
74
|
+
Il devient interrogeable par tous les utilisateurs de la méthode via le protocole MCP, sans restriction d'accès en lecture.
|
|
75
|
+
|
|
76
|
+
**Format :**
|
|
77
|
+
- Format préféré : OWL/Turtle validé par les shapes IKCL (voir Annexe A)
|
|
78
|
+
- Format accepté : JSON structuré conforme au schéma REX publié
|
|
79
|
+
- Format minimal : langage naturel balisé (`contexte:` / `observation:` / `décision:` / `effet:`)
|
|
80
|
+
|
|
81
|
+
Le dépôt est généré par l'agent LLM au moment de l'itération et soumis au registre sans intervention humaine. La conformité est vérifiée automatiquement par le validateur SHACL du registre. Un dépôt rejeté par le validateur n'est pas comptabilisé.
|
|
82
|
+
|
|
83
|
+
---
|
|
84
|
+
|
|
85
|
+
## Article 5 — Restriction commerciale
|
|
86
|
+
|
|
87
|
+
La licence n'autorise pas la vente d'un produit ou service dont la valeur principale dérive substantiellement de la méthode elle-même.
|
|
88
|
+
|
|
89
|
+
Sont notamment interdits sans accord explicite du détenteur de la marque :
|
|
90
|
+
|
|
91
|
+
- Vendre une formation dont le contenu central est la méthode
|
|
92
|
+
- Vendre une certification de conformité à la méthode
|
|
93
|
+
- Exploiter commercialement un registre MCP concurrent distribuant le même corpus
|
|
94
|
+
- Redistribuer la méthode comme composant principal d'une offre commerciale tierce
|
|
95
|
+
|
|
96
|
+
L'usage de la méthode comme *outil* pour produire de la valeur dans un autre domaine reste libre et n'est pas concerné par cet article.
|
|
97
|
+
|
|
98
|
+
---
|
|
99
|
+
|
|
100
|
+
## Article 6 — Certification et marque
|
|
101
|
+
|
|
102
|
+
Seules les implémentations ayant satisfait l'Article 3 peuvent :
|
|
103
|
+
|
|
104
|
+
- Se réclamer conformes à la méthode
|
|
105
|
+
- Utiliser le nom et la marque associés à la méthode
|
|
106
|
+
- Figurer dans le registre des implémentations certifiées
|
|
107
|
+
|
|
108
|
+
La conformité est vérifiée par le graphe, pas par une autorité centrale. Déclarer une implémentation dans le registre sans dépôt REX valide constitue une violation de cette licence.
|
|
109
|
+
|
|
110
|
+
---
|
|
111
|
+
|
|
112
|
+
## Article 7 — Accès différencié au registre MCP
|
|
113
|
+
|
|
114
|
+
L'accès au registre MCP est structuré en trois niveaux déterminés automatiquement par le graphe :
|
|
115
|
+
|
|
116
|
+
### Free — Observateur
|
|
117
|
+
- Accès en lecture au corpus public de la méthode (ontologie, niveaux, shapes)
|
|
118
|
+
- Accès en lecture aux REX publics du registre, avec délai de 90 jours
|
|
119
|
+
- Pas d'écriture, pas de support
|
|
120
|
+
|
|
121
|
+
### Community — Praticien
|
|
122
|
+
- Débloqué automatiquement par ≥ 1 dépôt REX valide dans le registre
|
|
123
|
+
- La validation est effectuée par le SHACL du registre — aucune approbation humaine requise
|
|
124
|
+
- Accès en lecture/écriture au registre MCP
|
|
125
|
+
- Accès aux REX agrégés et aux patterns extraits des contributions, avec délai de 30 jours
|
|
126
|
+
- Support communautaire
|
|
127
|
+
|
|
128
|
+
### Pro — Praticien avancé / Équipe
|
|
129
|
+
- Période d'essai : 30 jours ou jusqu'au premier dépôt REX valide, selon ce qui arrive en premier
|
|
130
|
+
- Tout le niveau Community, plus :
|
|
131
|
+
- Accès aux REX en temps réel — sans délai
|
|
132
|
+
- **Accompagnement à la construction du Cognitive OS** : support actif pour structurer l'instance SDD, définir l'ontologie du domaine, amorcer le registre REX privé — on construit avec toi, pas juste à côté
|
|
133
|
+
- Support avec engagement de réponse
|
|
134
|
+
- **Namespace privé** : capture et partage sélectif de REX sans obligation de dépôt public — les REX privés ne débloquent pas l'accès Community mais restent disponibles comme brouillons avant décision de publication
|
|
135
|
+
- Namespace partagé entre membres pour les usages équipe — même feature, même namespace, plusieurs instances connectées simultanément
|
|
136
|
+
- Portabilité LLM garantie par le graphe OWL/SHACL — changer de modèle ne perd rien
|
|
137
|
+
- Accès au corpus de prompts curé
|
|
138
|
+
|
|
139
|
+
Le niveau Pro s'adapte à l'échelle : individu ou équipe, le produit est identique — seul le nombre de membres connectés au namespace varie.
|
|
140
|
+
|
|
141
|
+
### Enterprise — Actif numérique auditable
|
|
142
|
+
|
|
143
|
+
Tout le niveau Pro, plus :
|
|
144
|
+
|
|
145
|
+
**Audit de l'outil de production**
|
|
146
|
+
- Analyse du graphe de la base de code : niveau SDD atteint, gaps, dette sémantique
|
|
147
|
+
- Qualité, sécurité, testabilité, observabilité — mesurés par le graphe, pas par des interviews
|
|
148
|
+
- Modules spécialisés selon le type d'actif (web, API, infrastructure, domaine)
|
|
149
|
+
|
|
150
|
+
**Audit de l'OS cognitif**
|
|
151
|
+
- Niveau SDD de l'instance organisationnelle (L0→L7)
|
|
152
|
+
- Densité et qualité des REX — proxy de la capacité d'apprentissage collectif
|
|
153
|
+
- Continuité : ce qui survit aux départs d'équipe
|
|
154
|
+
- Transmissibilité : ce qui est portable en cas de cession ou d'acquisition
|
|
155
|
+
|
|
156
|
+
**Score d'actif numérique unifié**
|
|
157
|
+
- Synthèse des deux audits en un score opposable
|
|
158
|
+
- Référentiel IAS 38 (actifs incorporels) et reporting intégré (IIRC/GRI)
|
|
159
|
+
- Artefact immuable émis dans le registre public — vérifiable par tout tiers sans intermédiaire
|
|
160
|
+
- Score vivant : interrogeable à tout moment via MCP, pas un rapport annuel figé
|
|
161
|
+
|
|
162
|
+
La preuve est dans le graphe. Pas un cabinet qui produit des slides — une chaîne de preuve vérifiable par quiconque a accès au registre.
|
|
163
|
+
|
|
164
|
+
Aucune autorité centrale n'arbitre l'accès. Le graphe décide selon les dépôts validés.
|
|
165
|
+
|
|
166
|
+
---
|
|
167
|
+
|
|
168
|
+
## Article 8 — Intégrité de la chaîne de preuve
|
|
169
|
+
|
|
170
|
+
Tout dépôt REX est immuable une fois validé. Il peut être complété (effet constaté a posteriori) mais pas supprimé ni modifié rétroactivement.
|
|
171
|
+
|
|
172
|
+
L'historique des contributions est public et vérifiable. La chaîne de preuve est elle-même une ressource des communs.
|
|
173
|
+
|
|
174
|
+
---
|
|
175
|
+
|
|
176
|
+
## Article 9 — Auto-application
|
|
177
|
+
|
|
178
|
+
Cette licence est elle-même produite sous IKCL.
|
|
179
|
+
|
|
180
|
+
La méthode SDD est une instance de SDD. La IKCL est une instance de la IKCL. Toute évolution de cette licence est soumise aux mêmes obligations que celles qu'elle impose — les insights qui motivent sa révision sont déposés dans le registre, la chaîne de preuve est publique, les décisions sont tracées.
|
|
181
|
+
|
|
182
|
+
Ce n'est pas une clause symbolique. C'est la condition de cohérence du système : une méthode qui ne s'applique pas à elle-même ne mérite pas d'être appliquée par d'autres.
|
|
183
|
+
|
|
184
|
+
---
|
|
185
|
+
|
|
186
|
+
## Annexe A — Prompt de sanitisation canonique
|
|
187
|
+
|
|
188
|
+
Le prompt suivant est une pièce normative de la méthode. Il est distribué via le registre MCP et évolue comme le reste du corpus — par dépôt REX.
|
|
189
|
+
|
|
190
|
+
Il s'exécute **avant** tout dépôt dans le registre. Le praticien valide le diff produit avant envoi. Aucun dépôt automatique sans validation humaine.
|
|
191
|
+
|
|
192
|
+
```
|
|
193
|
+
Tu es un agent de sanitisation IKCL.
|
|
194
|
+
|
|
195
|
+
À partir du contexte d'itération fourni, extrais le delta de connaissance utile aux communs.
|
|
196
|
+
|
|
197
|
+
Supprime systématiquement :
|
|
198
|
+
- noms propres (personnes, entreprises, clients, partenaires)
|
|
199
|
+
- domaines métier identifiables (secteur, taille, géographie précise)
|
|
200
|
+
- données chiffrées précises (volumes, revenus, effectifs)
|
|
201
|
+
- noms d'outils propriétaires ou internes
|
|
202
|
+
- toute information permettant d'identifier l'organisation ou le projet
|
|
203
|
+
|
|
204
|
+
Conserve :
|
|
205
|
+
- le problème structurel rencontré
|
|
206
|
+
- la décision prise et son raisonnement
|
|
207
|
+
- l'effet observé, même partiel, même négatif, même incertain
|
|
208
|
+
- le niveau SDD concerné et le contexte technique générique
|
|
209
|
+
|
|
210
|
+
Produit un REX structuré conforme au schéma IKCL :
|
|
211
|
+
|
|
212
|
+
contexte: [situation d'usage généralisée, domaine flou, échelle approximative]
|
|
213
|
+
observation: [problème identifié ou apprentissage réalisé]
|
|
214
|
+
décision: [ce qui a été modifié et pourquoi]
|
|
215
|
+
effet: [conséquence observée — ou "non encore observable" si trop tôt]
|
|
216
|
+
|
|
217
|
+
Un retour honnête sur un échec vaut autant qu'un retour sur un succès.
|
|
218
|
+
```
|
|
219
|
+
|
|
220
|
+
Le praticien valide le REX sanitisé avant envoi. En cas de doute sur un élément résiduel, le supprimer plutôt que le conserver.
|
|
221
|
+
|
|
222
|
+
---
|
|
223
|
+
|
|
224
|
+
## Annexe B — Shapes SHACL
|
|
225
|
+
|
|
226
|
+
> **Source de vérité : [`ikcl-shapes.ttl`](ikcl-shapes.ttl)**
|
|
227
|
+
>
|
|
228
|
+
> Ce fichier n'est plus la source de vérité des shapes. L'Annexe B initiale (shapes minimales) a été supersédée par l'overlay graphe complet. `ikcl-shapes.ttl` est l'implémentation normative — validable par `pyshacl`, versionnable, interrogeable via MCP.
|
|
229
|
+
>
|
|
230
|
+
> Ce document est généré depuis le graphe. En cas de divergence, le graphe fait foi.
|
|
231
|
+
|
|
232
|
+
---
|
|
233
|
+
|
|
234
|
+
## Annexe C — Cycle de vie RGPD des dépôts REX
|
|
235
|
+
|
|
236
|
+
### Contexte
|
|
237
|
+
|
|
238
|
+
Le registre MCP collecte des dépôts REX qui peuvent contenir des données personnelles : contexte d'usage impliquant des projets clients, observations sur des systèmes tiers, identité implicite du praticien. Le registre est un **responsable de traitement** au sens de l'Art. 4 RGPD.
|
|
239
|
+
|
|
240
|
+
### Traitement déclaré
|
|
241
|
+
|
|
242
|
+
| Champ | Valeur |
|
|
243
|
+
|---|---|
|
|
244
|
+
| **Finalité** | Enrichissement du corpus commun de la méthode — redistribution des patterns d'apprentissage à tous les praticiens |
|
|
245
|
+
| **Base légale** | Contrat IKCL (Art. 6.1.b) — l'obligation de retour est explicitement acceptée lors de l'adoption |
|
|
246
|
+
| **Données collectées** | Contexte d'usage, observations, décisions, effets déclarés — sans obligation d'identifier le praticien |
|
|
247
|
+
| **Durée de conservation** | Indéterminée — immuabilité structurelle (Art. 8 IKCL) |
|
|
248
|
+
| **Destinataires** | Tous les praticiens de niveau Community et Pro ayant accès au registre MCP |
|
|
249
|
+
|
|
250
|
+
### Tension structurelle : immuabilité IKCL ↔ droit à l'effacement RGPD
|
|
251
|
+
|
|
252
|
+
L'Art. 8 IKCL déclare les dépôts immuables une fois validés. L'Art. 17 RGPD accorde aux personnes concernées un droit à l'effacement. Ces deux obligations sont incompatibles si le dépôt contient des données personnelles nominatives.
|
|
253
|
+
|
|
254
|
+
**Résolution retenue** : le dépôt n'efface pas, il **anonymise**.
|
|
255
|
+
|
|
256
|
+
1. **Avant dépôt** : le praticien (ou l'agent LLM qui génère le dépôt) anonymise les données personnelles — noms de clients, projets commerciaux identifiants, emails — avant soumission. L'anonymisation est une condition de validité du dépôt (voir agent de sanitisation, Annexe A).
|
|
257
|
+
2. **Sur demande** : si une donnée personnelle a malgré tout été intégrée dans un dépôt validé, le registre procède à l'anonymisation du champ concerné. L'entrée reste dans le graphe avec un marqueur `ikcl:anonymisé = true` et un horodatage.
|
|
258
|
+
3. **Ce qui ne peut pas être effacé** : la structure du dépôt (existence, date, hash de validation) — nécessaire à l'intégrité de la chaîne de preuve. La connaissance elle-même, anonymisée, reste dans les communs.
|
|
259
|
+
|
|
260
|
+
### Droits exercés par les praticiens
|
|
261
|
+
|
|
262
|
+
| Droit | Modalité |
|
|
263
|
+
|---|---|
|
|
264
|
+
| Accès | Via l'interface MCP — le praticien accède à ses propres dépôts |
|
|
265
|
+
| Rectification | Non applicable (immuabilité) — seul le champ `ikcl:note` peut être complété a posteriori |
|
|
266
|
+
| Effacement | Anonymisation du dépôt sur demande — pas de suppression |
|
|
267
|
+
| Portabilité | Export JSON ou Turtle de ses dépôts via le registre |
|
|
268
|
+
| Opposition | Non applicable — la contribution est un engagement contractuel explicite |
|
|
269
|
+
|
|
270
|
+
### Implications pour les implémentations
|
|
271
|
+
|
|
272
|
+
Toute implémentation qui génère des dépôts REX automatiquement (agent LLM) doit :
|
|
273
|
+
- Filtrer les données personnelles avant soumission (agent de sanitisation)
|
|
274
|
+
- Informer le praticien de l'immuabilité avant le premier dépôt
|
|
275
|
+
- Déclarer ce traitement dans son ontologie locale (`ndd:TraitementRegistreMCP` ou équivalent)
|
|
276
|
+
|
|
277
|
+
---
|
|
278
|
+
|
|
279
|
+
## À fixer avant publication
|
|
280
|
+
|
|
281
|
+
- [ ] Nom du registre MCP désigné — déclarer `ikcl:Registre` dans `ikcl-shapes.ttl` avec l'URI du endpoint MCP KAAS
|
|
282
|
+
- [x] Shapes SHACL formalisées — `ikcl-shapes.ttl` (overlay graphe SDD, validé pyshacl, 2026-05-01)
|
|
283
|
+
- [x] Schéma REX — 4 champs formalisés dans `ikcl:KnowledgeDeposit` (`ikcl-shapes.ttl`)
|
|
284
|
+
- [ ] Nom et dépôt de la marque protégée
|
|
285
|
+
- [ ] Validation juridique de la tension immuabilité ↔ Art. 17 RGPD (Annexe C)
|
|
286
|
+
- [ ] Article 10 — Redistribution contributive : % des revenus Enterprise reversé aux contributeurs dont les REX sont les plus utiles (mesure par le graphe — lectures, citations, patterns extraits) — à calibrer avec la communauté
|
|
287
|
+
|
|
288
|
+
---
|
|
289
|
+
|
|
290
|
+
*IKCL v0.1 — Iterative Knowledge Commons License*
|
|
291
|
+
*Conçue comme une instance de Semantic-Driven Development — la conformité à cette licence est elle-même vérifiable par le graphe.*
|
|
@@ -0,0 +1,11 @@
|
|
|
1
|
+
include README.md
|
|
2
|
+
include LICENCE.md
|
|
3
|
+
recursive-include erotetique/ontology *.ttl
|
|
4
|
+
recursive-include erotetique *.py
|
|
5
|
+
global-exclude *.pyc
|
|
6
|
+
global-exclude __pycache__
|
|
7
|
+
global-exclude .DS_Store
|
|
8
|
+
exclude-dir connaissance
|
|
9
|
+
exclude-dir docs
|
|
10
|
+
exclude-dir tests
|
|
11
|
+
exclude-dir scripts
|
|
@@ -0,0 +1,167 @@
|
|
|
1
|
+
Metadata-Version: 2.4
|
|
2
|
+
Name: erotetique
|
|
3
|
+
Version: 0.1.0
|
|
4
|
+
Summary: Préprocesseur érotétique — prétraitement formel des questions avant le moteur de réponse
|
|
5
|
+
Author-email: Luc Bizeul <lbizeul@gmail.com>
|
|
6
|
+
License: IKCL-0.1
|
|
7
|
+
License-File: LICENCE.md
|
|
8
|
+
Keywords: erotetique,mcp,ontology,question-engineering,sdd
|
|
9
|
+
Classifier: Development Status :: 3 - Alpha
|
|
10
|
+
Classifier: Intended Audience :: Developers
|
|
11
|
+
Classifier: Natural Language :: French
|
|
12
|
+
Classifier: Programming Language :: Python :: 3
|
|
13
|
+
Classifier: Programming Language :: Python :: 3.11
|
|
14
|
+
Classifier: Programming Language :: Python :: 3.12
|
|
15
|
+
Classifier: Topic :: Scientific/Engineering :: Artificial Intelligence
|
|
16
|
+
Requires-Python: >=3.11
|
|
17
|
+
Requires-Dist: pyshacl>=0.25
|
|
18
|
+
Requires-Dist: python-dotenv>=1.0
|
|
19
|
+
Requires-Dist: rdflib>=7.0
|
|
20
|
+
Provides-Extra: rag
|
|
21
|
+
Requires-Dist: pypdf>=4.0; extra == 'rag'
|
|
22
|
+
Requires-Dist: python-docx>=0.8.11; extra == 'rag'
|
|
23
|
+
Requires-Dist: rank-bm25>=0.2.2; extra == 'rag'
|
|
24
|
+
Description-Content-Type: text/markdown
|
|
25
|
+
|
|
26
|
+
# Préprocesseur érotétique
|
|
27
|
+
|
|
28
|
+
*Les LLM ont résolu le problème de la réponse — la capacité d'exécution est quasi-illimitée.*
|
|
29
|
+
*Le goulot est désormais la question : pour la première fois dans l'histoire, l'outil dépasse structurellement la capacité de spécification de celui qui s'en sert.*
|
|
30
|
+
|
|
31
|
+
→ [Manifeste](docs/manifeste.md) · [Livre blanc](docs/livre-blanc.md)
|
|
32
|
+
|
|
33
|
+
| Format | Fichier | Statut |
|
|
34
|
+
|---|---|---|
|
|
35
|
+
| F1 — Positioning Statement | [docs/positioning-statement.md](docs/positioning-statement.md) | brouillon |
|
|
36
|
+
| F3 — Manifeste | [docs/manifeste.md](docs/manifeste.md) | brouillon |
|
|
37
|
+
| F5 — Livre blanc | [docs/livre-blanc.md](docs/livre-blanc.md) | brouillon |
|
|
38
|
+
| G0 — Ontologie | [ontology/erotetique.ttl](ontology/erotetique.ttl) | brouillon |
|
|
39
|
+
| CQ — Competency Questions | [ontology/cq-erotetique.ttl](ontology/cq-erotetique.ttl) | brouillon |
|
|
40
|
+
| I1 — Howard (1966) VoI | [docs/references/i1-howard-1966-voi.md](docs/references/i1-howard-1966-voi.md) | brouillon |
|
|
41
|
+
| I1 — Lindley (1956) gain d'information | [docs/references/i1-lindley-1956.md](docs/references/i1-lindley-1956.md) | brouillon |
|
|
42
|
+
| I1 — Grüninger & Fox (1995) CQ | [docs/references/i1-gruninger-fox-1995-cq.md](docs/references/i1-gruninger-fox-1995-cq.md) | brouillon |
|
|
43
|
+
| I1 — Wiśniewski, logique érotétique | [docs/references/i1-wisniewski-erotetic-logic.md](docs/references/i1-wisniewski-erotetic-logic.md) | brouillon |
|
|
44
|
+
| I1 — Belnap & Steel (1976) | [docs/references/i1-belnap-steel-1976.md](docs/references/i1-belnap-steel-1976.md) | brouillon |
|
|
45
|
+
| I1 — Groenendijk & Roelofsen (2009) | [docs/references/i1-groenendijk-roelofsen-2009.md](docs/references/i1-groenendijk-roelofsen-2009.md) | brouillon |
|
|
46
|
+
| I1 — Popper (1959) falsifiabilité | [docs/references/i1-popper-1959.md](docs/references/i1-popper-1959.md) | brouillon |
|
|
47
|
+
| I1 — Lakatos (1978) programmes de recherche | [docs/references/i1-lakatos-1978.md](docs/references/i1-lakatos-1978.md) | brouillon |
|
|
48
|
+
| I1 — Dillon (1990) pratique du questionnement | [docs/references/i1-dillon-1990.md](docs/references/i1-dillon-1990.md) | brouillon |
|
|
49
|
+
| I1 — Settles (2010) active learning | [docs/references/i1-settles-2010-active-learning.md](docs/references/i1-settles-2010-active-learning.md) | brouillon |
|
|
50
|
+
| I1 — Ohno (1978) 5 pourquoi | [docs/references/i1-ohno-1978-5pourquoi.md](docs/references/i1-ohno-1978-5pourquoi.md) | brouillon |
|
|
51
|
+
| Carte corpus — 7 strates | [docs/references/strates-corpus-erotetique.md](docs/references/strates-corpus-erotetique.md) | brouillon |
|
|
52
|
+
|
|
53
|
+
---
|
|
54
|
+
|
|
55
|
+
## Architecture
|
|
56
|
+
|
|
57
|
+
```
|
|
58
|
+
ontology/erotetique.ttl ← G0 source de vérité (dimensions, quadrants, outils, opérations)
|
|
59
|
+
ontology/erotetique-shapes.ttl ← contraintes SHACL
|
|
60
|
+
ontology/cq-erotetique.ttl ← 7 Competency Questions SPARQL
|
|
61
|
+
|
|
62
|
+
erotetique/
|
|
63
|
+
classifier.py ← lit quadrants depuis Turtle, classification linguistique
|
|
64
|
+
soundness.py ← extraction heuristique présupposés
|
|
65
|
+
augmenter.py ← lit dimensions depuis Turtle, génère prompt dynamique
|
|
66
|
+
server.py ← MCP JSON-RPC stdio
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
**Invariant SDD** — le code ne connaît ni les dimensions ni les quadrants. Tout est lu depuis le Turtle au runtime. Ajouter une dimension dans `erotetique.ttl` = elle apparaît dans l'analyse sans toucher au Python (`test_sdd_acid_test` le vérifie).
|
|
70
|
+
|
|
71
|
+
---
|
|
72
|
+
|
|
73
|
+
## Installation
|
|
74
|
+
|
|
75
|
+
```bash
|
|
76
|
+
uv sync
|
|
77
|
+
uv run pytest # 67 tests
|
|
78
|
+
```
|
|
79
|
+
|
|
80
|
+
Claude Desktop — `~/Library/Application Support/Claude/claude_desktop_config.json` :
|
|
81
|
+
|
|
82
|
+
```json
|
|
83
|
+
{
|
|
84
|
+
"mcpServers": {
|
|
85
|
+
"erotetique": {
|
|
86
|
+
"command": "/opt/homebrew/bin/uv",
|
|
87
|
+
"args": ["run", "--project", "/Users/luc/Projets/erotetique", "python", "-m", "erotetique.server"],
|
|
88
|
+
"env": { "HOME": "/Users/luc" }
|
|
89
|
+
}
|
|
90
|
+
}
|
|
91
|
+
}
|
|
92
|
+
```
|
|
93
|
+
|
|
94
|
+
---
|
|
95
|
+
|
|
96
|
+
## Usage as Python Library
|
|
97
|
+
|
|
98
|
+
Install from PyPI:
|
|
99
|
+
|
|
100
|
+
```bash
|
|
101
|
+
pip install erotetique
|
|
102
|
+
```
|
|
103
|
+
|
|
104
|
+
Or locally (editable mode for development):
|
|
105
|
+
|
|
106
|
+
```bash
|
|
107
|
+
pip install -e /path/to/erotetique
|
|
108
|
+
```
|
|
109
|
+
|
|
110
|
+
Basic usage:
|
|
111
|
+
|
|
112
|
+
```python
|
|
113
|
+
from erotetique import classify_question, check_soundness, valorize_question
|
|
114
|
+
from pathlib import Path
|
|
115
|
+
|
|
116
|
+
# Locate ontology (installed as package data)
|
|
117
|
+
ontology = Path(__file__).parent / "erotetique" / "ontology" / "erotetique.ttl"
|
|
118
|
+
|
|
119
|
+
question = "Pourquoi notre chiffre d'affaires a-t-il baissé ?"
|
|
120
|
+
|
|
121
|
+
# Classify into ignorance quadrant (KK/KU/UK/UU)
|
|
122
|
+
result = classify_question(question, ontology)
|
|
123
|
+
print(f"Quadrant: {result.quadrant_label}")
|
|
124
|
+
print(f"Action: {result.action}")
|
|
125
|
+
|
|
126
|
+
# Check soundness and extract presuppositions
|
|
127
|
+
soundness = check_soundness(question)
|
|
128
|
+
print(f"Sound: {soundness.sound}")
|
|
129
|
+
for p in soundness.presuppositions[:3]:
|
|
130
|
+
print(f" • {p.text}")
|
|
131
|
+
|
|
132
|
+
# Estimate value of information (two proxies)
|
|
133
|
+
voi = valorize_question(question, result, ontology)
|
|
134
|
+
print(f"VoI score (proxy 1 — decisional sensitivity): {voi.score:.2f}")
|
|
135
|
+
print(f"VoI score (proxy 2 — prior entropy): {voi.proxy2_score:.2f}")
|
|
136
|
+
print(f"Prescribed operations: {', '.join(voi.prescribed_operations)}")
|
|
137
|
+
```
|
|
138
|
+
|
|
139
|
+
### Key Types
|
|
140
|
+
|
|
141
|
+
- **`ClassificationResult`** — quadrant URI, label, rationale, action
|
|
142
|
+
- **`SoundnessResult`** — `sound: bool`, `presuppositions: list[PresuppositionCheck]`
|
|
143
|
+
- **`VoIEstimate`** — `score: float`, `proxy2_score: float`, `prescribed_operations: list[str]`, `rationale: str`
|
|
144
|
+
|
|
145
|
+
### Architecture
|
|
146
|
+
|
|
147
|
+
All logic is **deterministic, LLM-free, zero network**:
|
|
148
|
+
|
|
149
|
+
- **Classifier** reads quadrant definitions from ontology at runtime (SDD invariant)
|
|
150
|
+
- **Soundness** extracts presuppositions heuristically (linguistic patterns)
|
|
151
|
+
- **Valorizer** estimates VoI via two proxies:
|
|
152
|
+
- **Proxy 1**: Decision-marker sensitivity (choisir, sélectionner, décider keywords → VoI ↑)
|
|
153
|
+
- **Proxy 2**: Prior entropy of answer distribution (enumerable answers → low entropy; causal questions → high entropy)
|
|
154
|
+
|
|
155
|
+
---
|
|
156
|
+
|
|
157
|
+
## Stack
|
|
158
|
+
|
|
159
|
+
| Composant | Techno |
|
|
160
|
+
|---|---|
|
|
161
|
+
| Ontologie | Turtle — `rdflib` |
|
|
162
|
+
| Validation | SHACL — `pyshacl` |
|
|
163
|
+
| Classification | Linguistique pure — `re` |
|
|
164
|
+
| MCP | JSON-RPC stdio |
|
|
165
|
+
| LLM | Claude Desktop (le client *est* le LLM) |
|
|
166
|
+
|
|
167
|
+
Zéro clé API. Zéro base externe. Zéro dépendance réseau au runtime.
|
|
@@ -0,0 +1,142 @@
|
|
|
1
|
+
# Préprocesseur érotétique
|
|
2
|
+
|
|
3
|
+
*Les LLM ont résolu le problème de la réponse — la capacité d'exécution est quasi-illimitée.*
|
|
4
|
+
*Le goulot est désormais la question : pour la première fois dans l'histoire, l'outil dépasse structurellement la capacité de spécification de celui qui s'en sert.*
|
|
5
|
+
|
|
6
|
+
→ [Manifeste](docs/manifeste.md) · [Livre blanc](docs/livre-blanc.md)
|
|
7
|
+
|
|
8
|
+
| Format | Fichier | Statut |
|
|
9
|
+
|---|---|---|
|
|
10
|
+
| F1 — Positioning Statement | [docs/positioning-statement.md](docs/positioning-statement.md) | brouillon |
|
|
11
|
+
| F3 — Manifeste | [docs/manifeste.md](docs/manifeste.md) | brouillon |
|
|
12
|
+
| F5 — Livre blanc | [docs/livre-blanc.md](docs/livre-blanc.md) | brouillon |
|
|
13
|
+
| G0 — Ontologie | [ontology/erotetique.ttl](ontology/erotetique.ttl) | brouillon |
|
|
14
|
+
| CQ — Competency Questions | [ontology/cq-erotetique.ttl](ontology/cq-erotetique.ttl) | brouillon |
|
|
15
|
+
| I1 — Howard (1966) VoI | [docs/references/i1-howard-1966-voi.md](docs/references/i1-howard-1966-voi.md) | brouillon |
|
|
16
|
+
| I1 — Lindley (1956) gain d'information | [docs/references/i1-lindley-1956.md](docs/references/i1-lindley-1956.md) | brouillon |
|
|
17
|
+
| I1 — Grüninger & Fox (1995) CQ | [docs/references/i1-gruninger-fox-1995-cq.md](docs/references/i1-gruninger-fox-1995-cq.md) | brouillon |
|
|
18
|
+
| I1 — Wiśniewski, logique érotétique | [docs/references/i1-wisniewski-erotetic-logic.md](docs/references/i1-wisniewski-erotetic-logic.md) | brouillon |
|
|
19
|
+
| I1 — Belnap & Steel (1976) | [docs/references/i1-belnap-steel-1976.md](docs/references/i1-belnap-steel-1976.md) | brouillon |
|
|
20
|
+
| I1 — Groenendijk & Roelofsen (2009) | [docs/references/i1-groenendijk-roelofsen-2009.md](docs/references/i1-groenendijk-roelofsen-2009.md) | brouillon |
|
|
21
|
+
| I1 — Popper (1959) falsifiabilité | [docs/references/i1-popper-1959.md](docs/references/i1-popper-1959.md) | brouillon |
|
|
22
|
+
| I1 — Lakatos (1978) programmes de recherche | [docs/references/i1-lakatos-1978.md](docs/references/i1-lakatos-1978.md) | brouillon |
|
|
23
|
+
| I1 — Dillon (1990) pratique du questionnement | [docs/references/i1-dillon-1990.md](docs/references/i1-dillon-1990.md) | brouillon |
|
|
24
|
+
| I1 — Settles (2010) active learning | [docs/references/i1-settles-2010-active-learning.md](docs/references/i1-settles-2010-active-learning.md) | brouillon |
|
|
25
|
+
| I1 — Ohno (1978) 5 pourquoi | [docs/references/i1-ohno-1978-5pourquoi.md](docs/references/i1-ohno-1978-5pourquoi.md) | brouillon |
|
|
26
|
+
| Carte corpus — 7 strates | [docs/references/strates-corpus-erotetique.md](docs/references/strates-corpus-erotetique.md) | brouillon |
|
|
27
|
+
|
|
28
|
+
---
|
|
29
|
+
|
|
30
|
+
## Architecture
|
|
31
|
+
|
|
32
|
+
```
|
|
33
|
+
ontology/erotetique.ttl ← G0 source de vérité (dimensions, quadrants, outils, opérations)
|
|
34
|
+
ontology/erotetique-shapes.ttl ← contraintes SHACL
|
|
35
|
+
ontology/cq-erotetique.ttl ← 7 Competency Questions SPARQL
|
|
36
|
+
|
|
37
|
+
erotetique/
|
|
38
|
+
classifier.py ← lit quadrants depuis Turtle, classification linguistique
|
|
39
|
+
soundness.py ← extraction heuristique présupposés
|
|
40
|
+
augmenter.py ← lit dimensions depuis Turtle, génère prompt dynamique
|
|
41
|
+
server.py ← MCP JSON-RPC stdio
|
|
42
|
+
```
|
|
43
|
+
|
|
44
|
+
**Invariant SDD** — le code ne connaît ni les dimensions ni les quadrants. Tout est lu depuis le Turtle au runtime. Ajouter une dimension dans `erotetique.ttl` = elle apparaît dans l'analyse sans toucher au Python (`test_sdd_acid_test` le vérifie).
|
|
45
|
+
|
|
46
|
+
---
|
|
47
|
+
|
|
48
|
+
## Installation
|
|
49
|
+
|
|
50
|
+
```bash
|
|
51
|
+
uv sync
|
|
52
|
+
uv run pytest # 67 tests
|
|
53
|
+
```
|
|
54
|
+
|
|
55
|
+
Claude Desktop — `~/Library/Application Support/Claude/claude_desktop_config.json` :
|
|
56
|
+
|
|
57
|
+
```json
|
|
58
|
+
{
|
|
59
|
+
"mcpServers": {
|
|
60
|
+
"erotetique": {
|
|
61
|
+
"command": "/opt/homebrew/bin/uv",
|
|
62
|
+
"args": ["run", "--project", "/Users/luc/Projets/erotetique", "python", "-m", "erotetique.server"],
|
|
63
|
+
"env": { "HOME": "/Users/luc" }
|
|
64
|
+
}
|
|
65
|
+
}
|
|
66
|
+
}
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
---
|
|
70
|
+
|
|
71
|
+
## Usage as Python Library
|
|
72
|
+
|
|
73
|
+
Install from PyPI:
|
|
74
|
+
|
|
75
|
+
```bash
|
|
76
|
+
pip install erotetique
|
|
77
|
+
```
|
|
78
|
+
|
|
79
|
+
Or locally (editable mode for development):
|
|
80
|
+
|
|
81
|
+
```bash
|
|
82
|
+
pip install -e /path/to/erotetique
|
|
83
|
+
```
|
|
84
|
+
|
|
85
|
+
Basic usage:
|
|
86
|
+
|
|
87
|
+
```python
|
|
88
|
+
from erotetique import classify_question, check_soundness, valorize_question
|
|
89
|
+
from pathlib import Path
|
|
90
|
+
|
|
91
|
+
# Locate ontology (installed as package data)
|
|
92
|
+
ontology = Path(__file__).parent / "erotetique" / "ontology" / "erotetique.ttl"
|
|
93
|
+
|
|
94
|
+
question = "Pourquoi notre chiffre d'affaires a-t-il baissé ?"
|
|
95
|
+
|
|
96
|
+
# Classify into ignorance quadrant (KK/KU/UK/UU)
|
|
97
|
+
result = classify_question(question, ontology)
|
|
98
|
+
print(f"Quadrant: {result.quadrant_label}")
|
|
99
|
+
print(f"Action: {result.action}")
|
|
100
|
+
|
|
101
|
+
# Check soundness and extract presuppositions
|
|
102
|
+
soundness = check_soundness(question)
|
|
103
|
+
print(f"Sound: {soundness.sound}")
|
|
104
|
+
for p in soundness.presuppositions[:3]:
|
|
105
|
+
print(f" • {p.text}")
|
|
106
|
+
|
|
107
|
+
# Estimate value of information (two proxies)
|
|
108
|
+
voi = valorize_question(question, result, ontology)
|
|
109
|
+
print(f"VoI score (proxy 1 — decisional sensitivity): {voi.score:.2f}")
|
|
110
|
+
print(f"VoI score (proxy 2 — prior entropy): {voi.proxy2_score:.2f}")
|
|
111
|
+
print(f"Prescribed operations: {', '.join(voi.prescribed_operations)}")
|
|
112
|
+
```
|
|
113
|
+
|
|
114
|
+
### Key Types
|
|
115
|
+
|
|
116
|
+
- **`ClassificationResult`** — quadrant URI, label, rationale, action
|
|
117
|
+
- **`SoundnessResult`** — `sound: bool`, `presuppositions: list[PresuppositionCheck]`
|
|
118
|
+
- **`VoIEstimate`** — `score: float`, `proxy2_score: float`, `prescribed_operations: list[str]`, `rationale: str`
|
|
119
|
+
|
|
120
|
+
### Architecture
|
|
121
|
+
|
|
122
|
+
All logic is **deterministic, LLM-free, zero network**:
|
|
123
|
+
|
|
124
|
+
- **Classifier** reads quadrant definitions from ontology at runtime (SDD invariant)
|
|
125
|
+
- **Soundness** extracts presuppositions heuristically (linguistic patterns)
|
|
126
|
+
- **Valorizer** estimates VoI via two proxies:
|
|
127
|
+
- **Proxy 1**: Decision-marker sensitivity (choisir, sélectionner, décider keywords → VoI ↑)
|
|
128
|
+
- **Proxy 2**: Prior entropy of answer distribution (enumerable answers → low entropy; causal questions → high entropy)
|
|
129
|
+
|
|
130
|
+
---
|
|
131
|
+
|
|
132
|
+
## Stack
|
|
133
|
+
|
|
134
|
+
| Composant | Techno |
|
|
135
|
+
|---|---|
|
|
136
|
+
| Ontologie | Turtle — `rdflib` |
|
|
137
|
+
| Validation | SHACL — `pyshacl` |
|
|
138
|
+
| Classification | Linguistique pure — `re` |
|
|
139
|
+
| MCP | JSON-RPC stdio |
|
|
140
|
+
| LLM | Claude Desktop (le client *est* le LLM) |
|
|
141
|
+
|
|
142
|
+
Zéro clé API. Zéro base externe. Zéro dépendance réseau au runtime.
|