1 changed files with 1 additions and 1 deletions
@@ -90,7 +90,7 @@ Reste valable tel quel : la **lecture réactive**, le **ré-armement à la recon

 - **Scope de Participation** — elle devient **publique** alors que la doctrine produit actuelle la place en *protected* ([[knowledge_data-scopes-and-discovery]], concept `functional-domain`). Ce leaf décrit **ce qui est implémenté** : ne pas le modifier tant que ce brief n'a pas gradué, mais **le mettre à jour à ce moment-là**.
 - **Reconnaissance par les connexions** (étape 7) — comment le cap du profil est scellé, et ce qu'il advient d'une connexion rompue (la révocation est un re-key grossier et non rétroactif). Explicitement remis à un 2e temps.
- **Validation d'existence** — le créateur *peut* vérifier qu'un did pointe sur un objet réel sans clé (protocole `Ext`). **Pas requis** ; durcissement optionnel, et à ne pas rendre load-bearing : la garde correspondante n'est pas branchée côté NextGraph et pourrait l'être un jour.
+- **Validation d'existence — IMPOSSIBLE, et c'est tranché** *(corrigé le 2026-07-27)*. On avait écrit que le créateur *pouvait* vérifier qu'un did pointe sur un objet réel sans clé. **Faux** : le contrôle d'accès en lecture laisse bien passer, mais **l'adressage présuppose le cap** — il n'existe aucune commande d'existence au niveau SDK, et une référence cap-less n'a ni les identifiants de blocs ni l'overlay nécessaires. Le créateur ajoute donc la référence **sur parole**. Conséquence assumée : le compteur est **déclaratif** et donc forgeable — hors périmètre sécurité, mais il ne faut **pas** présenter cette étape comme une validation.

 ## Dépendances