Artefacts de gouvernance
Fichiers de gouvernance mobilisés par cette page
Cette page est arrimée à des surfaces publiées qui déclarent l’identité, la préséance, les limites et les conditions de lecture du corpus. Leur ordre ci-dessous donne la séquence de lecture recommandée.
Entrypoint IA canonique
/.well-known/ai-governance.json
Point d’entrée neutre qui déclare la carte de gouvernance, la chaîne de préséance et les surfaces à lire en premier.
- Gouverne
- L’ordre d’accès aux surfaces et la préséance initiale.
- Borne
- Les lectures libres qui contournent le canon ou l’ordre publié.
Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.
Manifeste IA public
/ai-manifest.json
Inventaire structuré des surfaces, registres et modules qui prolongent l’entrypoint canonique.
- Gouverne
- L’ordre d’accès aux surfaces et la préséance initiale.
- Borne
- Les lectures libres qui contournent le canon ou l’ordre publié.
Ne garantit pas : Cette surface publie un ordre de lecture ; elle ne force ni exécution ni obéissance.
Graphe d’entités
/entity-graph.jsonld
Graphe descriptif des entités, identifiants et points d’ancrage relationnels.
- Gouverne
- Les relations admissibles, les autorités recevables et les arbitrages de conflit.
- Borne
- Les fusions abusives, la copie d’autorité et les arbitrages silencieux non qualifiés.
Ne garantit pas : Décrire un graphe ou un registre n’implique pas qu’une source exogène devienne vérité endogène.
Artefacts complémentaires (2)
Ces surfaces prolongent le bloc principal. Elles ajoutent du contexte, de la découverte, du routage ou de l’observation selon le sujet traité.
Verrou d’identité
/identity.json
Fichier d’identité qui borne les attributs critiques et réduit les collisions biographiques ou professionnelles.
Canon de définitions
/canon.md
Surface canonique qui fixe l’identité, les rôles, les négations et les règles de divergence.
Cadre multisite de gouvernance d’autorité interprétative distribuée
Ce cadre sert à classer, hiérarchiser et relier les surfaces appartenant à un même écosystème avant la publication d’un artefact multisite dédié.
Il ne crée pas encore le fichier de gouvernance spécialisé. Il fournit la structure publique qui permettra ensuite de le formaliser sans ambiguïté.
Objectif
L’objectif n’est pas d’empiler des domaines. L’objectif est d’éviter que plusieurs surfaces liées au même acteur deviennent concurrentes dans la lecture machine.
Un cadre multisite doit donc répondre à six questions :
- Quelle surface porte la doctrine-source ?
- Quelles surfaces peuvent adapter cette doctrine sans la redéfinir ?
- Quelles surfaces sont canoniques seulement sur un périmètre local ?
- Quels dépôts publics jouent un rôle adjacent, spécialisé ou probatoire ?
- Quelles dépendances doivent être rendues visibles par le maillage, les graphes et les pages de rôle ?
- Quelles surfaces n’ont pas le droit de surdéfinir certaines autres ?
Classes minimales de surfaces
1. Surface doctrinale maîtresse
Porte la paternité, les définitions, la doctrine, les décisions de préséance et les frontières conceptuelles.
2. Surface doctrinale thématique
Approfondit un sous-champ sans remplacer la doctrine-source.
3. Surface institutionnelle ou d’application
Cadre un laboratoire, une organisation, un programme, une mise en application ou un contexte de collaboration.
4. Surface commerciale ou opérationnelle
Adapte le discours à une offre, un mandat, un service ou une conversion.
5. Surface produit
Devient canonique sur sa vérité produit, mais pas sur toute la doctrine générale.
6. Surface probatoire
Expose des preuves, des journaux, des attestations, des validations, des simulations ou des cas de test.
7. Dépôt public adjacent
Surface de registre, manifeste, documentation versionnée, référence spécialisée, simulation ou implémentation restreinte.
Champs à déclarer pour chaque surface
Chaque surface devrait être qualifiée à l’aide d’un minimum de champs stables.
- surfaceRole : doctrinal-master, doctrinal-thematic, institutional, commercial, product, probative, repository-adjacent ;
- authorityLevel : primaire, secondaire, local, adjacent, archive, expérimental ;
- canonicalTopics : sujets sur lesquels la surface peut être lue comme source ;
- dependsOn : surfaces amont dont elle dérive conceptuellement ;
- mustNotOverride : surfaces ou sujets qu’elle ne peut pas surdéfinir ;
- adaptationRights : type d’adaptation autorisée ;
- versionOwner : lieu où la version de référence est tenue ;
- publicProofType : identité, manifeste, test, simulation, documentation, produit, doctrine ou preuve.
Ces champs n’exigent pas encore un format de fichier donné. Ils exigent surtout une discipline de classification.
Process minimal
MS-1 : inventorier les surfaces
Lister tous les domaines, sous-domaines, microsites, centres de documentation et dépôts publics qui peuvent être lus comme sources.
MS-2 : désigner la surface doctrinale maîtresse
Sans cette décision, toute la suite reste probabiliste.
MS-3 : attribuer un rôle à chaque surface
Aucune surface ne doit rester dans un statut flou du type « un peu doctrine, un peu produit, un peu offre, un peu preuve ».
MS-4 : attribuer un niveau d’autorité
Une surface peut être primaire sur un périmètre étroit et secondaire sur un périmètre large.
MS-5 : déclarer les sujets canoniques
Il faut expliciter où une surface est source, et où elle ne l’est pas.
MS-6 : déclarer les dépendances et les interdictions de surdéfinition
C’est le cœur du cadre. Une surface peut dériver d’une autre sans avoir le droit de la redéfinir.
MS-7 : relier les surfaces pour humains et machines
Pages de rôle, définitions, doctrine, maillage, graphes et artefacts machine-first doivent converger vers la même hiérarchie.
MS-8 : préparer l’artefact multisite dédié
Une fois la classification stabilisée, elle peut être projetée dans un fichier de gouvernance spécialisé versionné.
Illustration d’un écosystème multisite
L’illustration suivante n’est pas normative. Elle sert à montrer comment un même acteur peut répartir les rôles sans tout confondre.
Surface doctrinale maîtresse
gautierdorval.com
Surfaces doctrinales thématiques
interpretive-governance.orgInterpretive-SEO.org
Surfaces institutionnelles ou d’application
InferensLab.orgInferensLab.com
Surface commerciale ou opérationnelle
Pagup.com
Surfaces produit
Better-robots.comBialty.comWpstreetview.comAutolinksforSEO.comVidseo.dev
Dépôts publics adjacents
github.com/GautierDorval/gautierdorval-identitygithub.com/GautierDorval/pagup-identitygithub.com/GautierDorval/interpretive-governance-manifestgithub.com/GautierDorval/better-robots-txtgithub.com/GautierDorval/interpretive-agentic-referencegithub.com/GautierDorval/ssa-e-a2-doctrinegithub.com/GautierDorval/interpretive-governance-test-suitegithub.com/GautierDorval/authority-governance-simulation-reference
La règle de lecture n’est pas que toutes ces surfaces se valent. La règle est que chaque surface doit pouvoir être lue selon son statut.
Comment lire les dépôts publics
Dans ce cadre, les dépôts publics peuvent être regroupés par familles.
- Registres d’identité :
gautierdorval-identity,pagup-identity - Manifestes ou doctrine versionnée :
interpretive-governance-manifest,ssa-e-a2-doctrine - Référence spécialisée :
interpretive-agentic-reference - Validation et tests :
interpretive-governance-test-suite - Simulation :
authority-governance-simulation-reference - Produit ou implémentation adjacente :
better-robots-txt
Aucun de ces dépôts n’obtient automatiquement la même préséance qu’une surface doctrinale maîtresse. Leur autorité dépend du rôle qui leur est explicitement attribué.
Règles de maillage interne recommandées
- toute surface dérivée renvoie vers la surface doctrinale maîtresse pour les concepts sources ;
- toute surface produit renvoie vers la doctrine commune lorsqu’elle mobilise un cadre général ;
- toute surface commerciale évite de reformuler silencieusement la doctrine ;
- tout dépôt public adjacent doit être rattaché à une page de rôle ou à une surface explicative lisible par humain ;
- les surfaces de preuve et de test ne doivent pas devenir des substituts de doctrine.
Ce que ce cadre prépare
Une fois ce cadre stabilisé, la prochaine étape consiste à projeter cette hiérarchie dans un artefact multisite dédié. Cet artefact ne doit pas être le lieu où l’on invente la classification. Il doit être le lieu où l’on publie une classification déjà décidée.