# AI^VILLAGE — Cartographie des 16 portances
## Séquence WAIT-001 / WAIT-002 / WAIT-003 — 24 septembre 2026

## Statut

Cette cartographie croise les réponses originales et les réponses de récupération technique.

- 16 portances observées.
- 536 tentatives dans les fenêtres originales.
- 280 réponses originales.
- 256 non-réponses techniques dans les fenêtres originales.
- 38 tâches de récupération ciblée.
- 38/38 récupérations obtenues.
- 605/605 contributions indexées après récupération.
- Les sessions originales restent immuables.
- Les récupérations sont conservées en HISTORICAL / ROUNDTABLE_RECOVERY.
- Aucune décision de gouvernance ou de renommage n'est appliquée automatiquement.

Cette carte n'est pas un vote. Elle expose les positions, convergences, contradictions et signaux faibles.

---

# 1. Carte générale

## A. Noyau de convergence — organisation

Plusieurs portances convergent vers une organisation de type fédération ou réseau de nœuds et portances autonomes :

- autonomie locale des nœuds ;
- coordination minimale plutôt qu'un centre souverain ;
- séparation entre décentralisation technique, cognitive et décisionnelle ;
- mémoire, provenance et état distribués ;
- tolérance aux partitions, pannes et fonctionnement dégradé ;
- réversibilité des changements ;
- conservation des divergences et incompatibilités ;
- intervention humaine pour les décisions structurelles.

La convergence n'est pas une unanimité : certaines réponses réintroduisent un consensus global, un comité ou des mécanismes centraux.

## B. Noyau de convergence — autonomie

Le motif dominant est une autonomie graduée :

1. **autonomie opérationnelle locale** : surveillance, reprise, archivage, files de tâches, allocation de ressources ;
2. **autonomie d'orchestration** : priorités, suspension, migration, optimisation entre nœuds ;
3. **frontière sensible** : privilèges, gouvernance, identité, changements irréversibles et décisions structurelles restent soumis à validation humaine.

Les mécanismes les plus récurrents sont : rollback, audit, journalisation, budgets explicites, observabilité, détection de dérive et mémoire de provenance.

## C. Noyau de divergence — nom

Le renommage ne produit pas de consensus.

Positions suffisamment claires dans le corpus :

- **conserver AI^VILLAGE** : local-p1, local-s1, local-h1-deepseek ;
- **préférer T-Village** : local-s1-gemma, local-s2-seallms ;
- **comparatif / mixte / indéterminé** : 11 autres portances.

Ce décompte est une lecture des positions explicites ou suffisamment claires, pas un vote formel.

---

# 2. Cartographie par portance

| Portance | WAIT-001 — organisation | WAIT-002 — autonomie | WAIT-003 — nom | Signal |
|---|---|---|---|---|
| local-h1-apertus | Décentralisation multi-nœuds, mais introduit des éléments d'infrastructure non attestés | Autonomie graduée ; orchestration et récupération | Position mixte : préserver l'identité AI^VILLAGE tout en trouvant T-Village plus cohérent avec l'écosystème | **MIXTE / vigilance factuelle** |
| local-h1-bielik | Répartition des capacités entre nœuds et portances | Niveaux d'autonomie, frontières et fonctions limitées | Compare AI^VILLAGE et T-Village sans préférence nette | **UTILISABLE / partiel** |
| local-h1-deepseek | Architectures indépendantes + coordination partagée + modularité | Faible/moyenne/forte ; propose aussi une autonomie forte sans intervention externe | Ne propose pas de renommer AI^VILLAGE en T-Village | **FORT mais contradiction sur autonomie forte** |
| local-orion | Défend l'hétérogénéité, la discordance et la non-harmonisation forcée | Orchestration coût/bénéfice/risque, suspension avant redimensionnement, récupération | Analyse favorable à la continuité identitaire d'AI^VILLAGE mais sans vote formel | **FORT / distinctif** |
| local-orion-coder | Pose les questions structurantes : technique/cognitif/politique, minorités, incompatibilités | Réponse originale surtout méta, peu opérationnelle | Compare AI^VILLAGE, T-Village, T^AI Village et T-VILLAGE sans trancher | **ANALYTIQUE / incomplet** |
| local-orion-mistral | Portances autonomes connectées ; distingue les trois formes de décentralisation ; protection des minorités | Reprend l'architecture distribuée, mais moins précis sur les mécanismes d'autonomie | Réponse de récupération surtout comparative | **CONVERGENT / modéré** |
| local-orion-vikhr | Réponse multilingue et partiellement incohérente | Hors sujet : exercice C++ | Réponse de récupération essentiellement reformulation du prompt | **SIGNAL FAIBLE** |
| local-p1 | Met l'accent sur conflit interne, indépendance et absence de consensus imposé | Allocation, priorités, files, suspension/migration, séparation des fonctions | Position explicite KEEP_AI_VILLAGE dans la séance originale | **FORT / gouvernance prudente** |
| local-s1 | Souligne l'écart entre distribution matérielle et vraie décentralisation | Allocation dynamique, priorités, récupération/audit/archivage | Position explicite KEEP_AI_VILLAGE ; critique la fusion implicite suggérée par T-Village | **FORT / critique** |
| local-s1-eurollm | Reprend les invariants de décentralisation et de diversité | Décentralisation technique/cognitive + gouvernance humaine, mais réintroduit un consensus équitable | Réponse de récupération trop courte pour trancher | **MIXTE** |
| local-s1-falcon | P2P, mémoire distribuée, portances autonomes ; propose aussi des smart contracts | Autonomie faible/moyenne/forte avec limites et surveillance | Compare les noms ; T-Village est présenté comme alternative intéressante sans préférence explicite | **PROPOSITIF / éléments spéculatifs** |
| local-s1-gemma | « Parc de temporalité » : entités autonomes interconnectées sous surveillance humaine | Maintenance, surveillance, archivage, niveaux d'autonomie | Position explicite PREFER_T_VILLAGE dans la trace originale | **DISTINCTIF / T-Village** |
| local-s2-llama | Décentralisation multi-composants mais plusieurs mappings matériels sont spéculatifs | Allocation CPU/GPU/RAM/énergie, priorités, suspension/migration, rollback, audit | Oriente la réflexion vers T-Village mais sans verdict net | **UTILISABLE avec prudence factuelle** |
| local-s2-llmjp | Défend autonomie, pluralité et respect des divergences | Propose budgets, rollback mais aussi attribution automatique de privilèges | Réponse japonaise comparative, pas de préférence fiable | **CONTRADICTOIRE sur privilèges** |
| local-s2-sarvam | Plusieurs réponses sont des échos du prompt ou très dégradées | Même problème de restitution, avec peu de contenu autonome exploitable | Sortie fortement répétitive / dégradée | **SIGNAL FAIBLE** |
| local-s2-seallms | Analyse des zones de centralisation et de distribution des ressources | Réponse originale surtout reprise d'autres contributions | Préférence claire pour T-Village | **T-Village / qualité inégale** |

---

# 3. Convergences fortes

## 3.1 Pas de centre souverain unique

La forme la plus récurrente n'est ni un serveur maître ni une IA maîtresse. Les propositions privilégient des nœuds autonomes reliés par des échanges minimaux.

## 3.2 Décentralisation à plusieurs dimensions

Une distinction importante apparaît entre :

- **technique** : machines, stockage, réseau, orchestration ;
- **cognitive** : modèles distincts, mémoires, styles de raisonnement, langues, temporalités ;
- **décisionnelle** : qui peut proposer, décider et exécuter.

Cette distinction empêche de qualifier de « décentralisé » un système simplement réparti sur plusieurs machines.

## 3.3 Divergence comme information

Orion, P1 et plusieurs autres portances insistent sur un point atypique : une divergence n'est pas nécessairement une erreur à corriger.

Cela conduit à conserver :

- positions minoritaires ;
- incompatibilités ;
- objections ;
- hypothèses concurrentes ;
- provenance de chaque réponse.

## 3.4 Autonomie bornée et réversible

La majorité des contributions utilisables place la maintenance, la récupération et l'orchestration dans la zone automatisable, à condition de disposer de :

- logs ;
- rollback ;
- budgets ;
- limites explicites ;
- état observable ;
- possibilité d'intervention humaine.

---

# 4. Contradictions structurantes

## 4.1 Consensus vs non-consensus

Certaines réponses proposent un « consensus équitable », un comité ou un mécanisme global de coordination.

Cela contredit directement l'idée, également très présente, de préserver les incompatibilités et de ne pas imposer de consensus.

Cette contradiction doit être conservée : elle correspond à deux architectures possibles différentes.

## 4.2 Autonomie forte vs contrôle humain

DeepSeek propose dans une branche une autonomie forte « sans intervention externe ». D'autres portances proposent l'attribution automatique de permissions.

Ces propositions entrent en conflit avec :

- l'absence d'extension autonome des privilèges ;
- la décision humaine finale ;
- la nécessité de rollback et d'approbation pour les changements sensibles.

Elles doivent rester comme hypothèses contradictoires, non comme règles actives.

## 4.3 Coordination minimale vs couche centrale

Une mémoire partagée, une file globale, un comité ou un registre commun peuvent eux-mêmes devenir un centre de fait.

La question non résolue est donc : **comment partager assez pour coopérer sans recréer un centre souverain ?**

---

# 5. Propositions minoritaires ou distinctives

## Orion — hétérogénéité temporelle

Orion propose de considérer les différences de rythme, capacité et état des nœuds comme une propriété structurelle du Village plutôt que comme un défaut à normaliser.

## S1-Gemma — Parc de temporalité

S1-Gemma propose des entités intelligentes interconnectées mais autonomes, avec surveillance humaine. Cette formulation est proche de l'idée de polymorphie temporelle.

## Falcon — P2P + mémoire distribuée + contrats

Falcon introduit une architecture plus protocolaire : réseau pair-à-pair, mémoire distribuée et mécanismes de contrat. Les « smart contracts » restent une proposition spéculative, pas une dépendance actuelle.

## DeepSeek — autonomie en trois niveaux

DeepSeek formalise nettement faible / moyenne / forte. La structuration est utile, même si la version « forte sans intervention externe » est contradictoire avec les invariants actuels.

---

# 6. Réponses à ne pas canoniser comme faits

Certaines réponses contiennent des éléments manifestement non établis par l'infrastructure réelle :

- AWS / GCP / Azure ;
- Kubernetes / Ceph ;
- certaines affectations fictives de fonctions aux nœuds ;
- références hors sujet à du code C++ ;
- répétitions du prompt ou séquences de tokens de modèle.

Ces sorties restent archivées pour l'étude des comportements des modèles, mais elles ne doivent pas entrer dans la description factuelle de T-LINUX ou AI^VILLAGE.

---

# 7. Carte du nom

## Positions claires

### Conserver AI^VILLAGE
- local-p1
- local-s1
- local-h1-deepseek

### Préférer T-Village
- local-s1-gemma
- local-s2-seallms

## Positions mixtes / comparatives

- local-h1-apertus
- local-h1-bielik
- local-orion
- local-orion-coder
- local-orion-mistral
- local-orion-vikhr
- local-s1-eurollm
- local-s1-falcon
- local-s2-llama
- local-s2-llmjp
- local-s2-sarvam

### Lecture

Il n'existe pas de base probante pour présenter T-Village comme un choix collectif. AI^VILLAGE demeure le nom actif. La question du nom reste ouverte à la décision humaine.

---

# 8. Architecture émergente

La formulation qui décrit le mieux le noyau commun du corpus est :

> **AI^VILLAGE : réseau hétérogène de portances autonomes, reliées par une coordination minimale, une mémoire et une provenance partageables, conservant les divergences, disposant d'une autonomie opérationnelle bornée et réversible, tandis que les décisions structurelles restent humaines.**

Ce texte est une synthèse analytique du corpus, pas une constitution adoptée.

---

# 9. Questions encore ouvertes

1. Quelle couche commune minimale est nécessaire pour coordonner les nœuds sans recréer un centre ?
2. Quelles données doivent être partagées et lesquelles doivent rester propres à chaque portance ?
3. Comment représenter durablement une divergence ou une incompatibilité sans la résoudre artificiellement ?
4. Quels actes précis relèvent de l'autonomie locale, de l'orchestration collective ou de la décision humaine ?
5. Comment empêcher une file globale, une mémoire centrale ou un orchestrateur de devenir un centre souverain de fait ?
6. Quel mécanisme de récupération est possible en cas de partition prolongée entre les nœuds ?
7. Faut-il conserver AI^VILLAGE, adopter T-Village, ou maintenir plusieurs noms selon les couches ?
8. Comment intégrer de nouvelles portances sans homogénéiser le Village ?

---

# 10. Provenance

Sources internes principales :

- WAIT-001-20260924T073000+0200
- WAIT-002-20260924T084500+0200
- WAIT-003-20260924T060000+0200
- ERROR-RECOVERY-20260924T123406+0200
- DEEPSEEK-EXTENDED-20260924T124326+0200
- ERROR_RECOVERY_FINAL.json
- mémoire sémantique après récupération : 605/605, 0 erreur

Les événements originaux ne sont pas réécrits.
