Design Principles & Boundaries
Ce document déclare les principes architecturaux et les limites non négociables du protocole, en tant qu'invariants infrastructurels : propriétés que le système doit préserver à travers chaque implémentation et chaque révision future.
§ 01 · Introduction
Les principes qui suivent et les limites qui les accompagnent constituent les invariants du protocole. Ils sont énoncés explicitement pour que toute implémentation et toute révision puissent y être confrontées.
Les invariants ne sont pas des recommandations : ce sont des propriétés structurelles. Une implémentation qui les viole ne réalise pas AIKNOCK, même si elle en adopte le nom ou la terminologie.
§ 02 · Design Principles
Les principes qui suivent définissent le comportement technique du système pendant l'exécution d'opérations d'intelligence artificielle. Les huit principes définissent les propriétés architecturales que le protocole doit préserver. Ils sont numérotés pour référence et se lisent comme un ensemble : aucun principe n'est dispensable sans modifier la nature du protocole.
L'IA est traitée comme une capability critique du système, et non comme une bibliothèque ou une fonctionnalité applicative. Son usage est soumis aux propriétés que le système réserve aux ressources critiques.
Toute invocation de l'IA traverse le protocole. L'interposition n'est pas optionnelle et ne dépend pas de la coopération du code appelant.
L'évaluation du contexte et de l'intention est ex-ante : elle précède l'invocation du modèle. Ce n'est ni un contrôle ultérieur ni une vérification par échantillonnage.
La décision est appliquée par un mécanisme technique au niveau du système. Les déclarations d'intention et les règles organisationnelles ne remplacent pas l'enforcement.
Les preuves sont un effet du fonctionnement du protocole, et non une fonctionnalité supplémentaire. La vérifiabilité des décisions est structurelle.
La présence technique d'un modèle n'implique pas l'autorisation de son usage. Les deux plans — disponibilité et autorisation — restent distincts par construction.
Lorsque cela est requis, l'intervention humaine n'est pas une procédure opérationnelle mais une exigence imposée par le système. Le protocole ne progresse pas en son absence.
Le protocole ne dépend ni d'un modèle, ni d'un runtime, ni d'un fournisseur commercial en particulier. Il définit une interface de contrôle d'exécution à laquelle toute implémentation se conforme.
§ 03 · Boundaries
Aux principes correspondent des limites explicites. Ces limites délimitent ce que le protocole, par construction, n'occupe pas : elles sont aussi contraignantes que les principes et contribuent à définir son identité.
Le protocole n'inspecte pas, ne filtre pas et n'évalue pas les contenus échangés avec les modèles. Son domaine est le droit d'usage, et non le mérite du résultat.
Les obligations juridiques demeurent telles. AIKNOCK n'interprète pas les normes, ne garantit pas la conformité, ne se superpose pas à la juridiction compétente.
Le protocole décrit des propriétés techniques du système. Il ne définit pas de processus de certification, n'émet pas d'attestations, ne se substitue pas aux organismes compétents.
La construction, l'entraînement, la sélection et l'évaluation des modèles sont hors périmètre. Le protocole agit au moment de l'usage, et non en amont.
AIKNOCK ne comprend ni tableaux de bord, ni consoles, ni expériences d'usage. C'est un plan infrastructurel : les interfaces demeurent de la responsabilité des implémentations.
Les limites énoncées ci-dessus ne sont pas des lacunes du protocole : ce sont des choix architecturaux délibérés. Restreindre le périmètre est une condition nécessaire pour que ce que le protocole déclare faire puisse être garanti avec précision.
§ 04 · Synthèse
Les principes définissent ce que le protocole est. Les limites définissent ce que le protocole n'est pas.
Ensemble, ils constituent les invariants : la condition pour qu'AIKNOCK reste reconnaissable à travers chaque implémentation, chaque révision et chaque adoption.
Une spécification qui change d'identité à chaque révision n'est pas un standard. Les invariants sont la manière dont un protocole ouvert se rend durable.