Context Nexus
Le Framework
Context Nexus organisé en quatre registres, liés par l'héritage et consommés par les agents IA selon quatre modes distincts.
Qu'est-ce que le Context Nexus ?
Il se distingue d'une documentation classique sur deux points. D'abord, il est orienté vers le futur autant que vers le passé : il capture l'intention (ce qu'on veut construire) autant que la mémoire (ce qui a été décidé). Ensuite, il n'est pas figé : il se cultive et s'affine à chaque itération, nourri par les contributions humaines et les observations des agents en run, en test et en discovery.
Deux acteurs, deux modes d'interaction
Conceptualisent et alimentent par l'intention : specs, décisions d'architecture, contrats de qualité, procédures. Intent et Contracts sont toujours définis par des humains.
Exploitent et enrichissent par l'observation : ils consomment le contexte pour produire, remontent leurs observations pour affiner les registres.
Les quatre registres
Cliquez sur un registre pour l'explorer en profondeur.
Domain knowledge, architecture, décisions passées, conventions. La mémoire dans laquelle les agents s'ancrent pour ne pas halluciner et produire du code cohérent.
Specs, Decision Directives, roadmap, hypothèses produit. Les instructions précises que les agents exécutent pour générer du code, des tests et des composants.
Assertions vérifiables avec seuils : quality gates, SLAs de performance, standards d'accessibilité, règles data. Les agents valident leur propre output avant de proposer.
Runbooks, playbooks, procédures de déploiement, protocoles d'incident. Les workflows que les agents exécutent de façon autonome quand les conditions sont réunies.
Les registres se nourrissent mutuellement.
Les quatre registres ne sont pas indépendants : ils se nourrissent mutuellement selon une logique circulaire :
Knowledge → Intent : la connaissance du domaine contraint et précise les intentions avant même qu'un agent commence à produire.
Intent → Contracts : les specs et hypothèses produit déterminent le contrat de qualité : les critères d'acceptance deviennent des assertions vérifiables, les SLAs se précisent à mesure que les intentions s'affinent.
Contracts → Operations : les contrats produisent des runbooks, des playbooks d'incident et des protocoles qui opérationnalisent les exigences.
Operations → Knowledge : chaque incident résolu, chaque procédure exécutée devient de la connaissance collective capitalisée dans le registre Knowledge.
Boucles de feedback IA
Au-delà des boucles entre registres, les agents IA enrichissent le Context Nexus en continu par leurs observations, en test, en run et en discovery :
En test (Ship) : l'agent observe les résultats du mutation scoring. Un score insuffisant remonte dans Contracts et dans Knowledge.
En run (Sync) : l'agent observe les métriques de production : latence, anomalies, patterns d'usage. Ces observations alimentent Knowledge, Operations et Contracts.
En discovery (Shape) : l'agent analyse les feedbacks utilisateurs et les données d'usage. Ces signaux alimentent Intent : les specs et hypothèses produit se mettent à jour en fonction de ce que la réalité apprend à l'équipe.
Quatre façons de consommer la connaissance.
Injecté à l'initialisation de l'agent. Toujours actif, toujours vrai. Faible volume, haute densité, zéro ambiguïté. Ce que l'agent doit savoir avant de commencer à travailler.
Récupéré à la demande par similarité sémantique. Le bon mode pour les grandes bases de connaissance où seule une fraction est pertinente à chaque tâche. Exige un chunking soigné et des métadonnées riches.
Assemblé et passé explicitement pour une tâche spécifique. Ni trop tôt (system prompt), ni à la demande (RAG), c'est le contexte de mission : la spec en cours, les Decision Directives applicables à ce ticket.
Des procédures appelables. L'agent ne lit pas un runbook — il l'exécute. Le quality gate n'est pas seulement une règle connue, c'est une fonction qui retourne pass/fail.
Register × Mode mapping
| Register | System | RAG | Context | Skills |
|---|---|---|---|---|
| Knowledge | Conventions, anti-patterns | Domain knowledge, Decision Contexts | — | — |
| Intent | Universal Decision Directives | — | Spec, task-specific directives | — |
| Contracts | All assertions | — | — | Verification tools |
| Operations | — | Incident search | — | Runbooks, playbooks |
N niveaux, une logique d'héritage.
Une two pizza team n'opère jamais directement sous une organisation. Elle s'inscrit dans une BU, un programme, un contexte produit particulier. Le Context Nexus reflète cette réalité avec un modèle d'héritage à N niveaux configurables.
La structure par défaut à trois niveaux : Nexus Org (racine : non-négociables) → Nexus Intermédiaire (BU / Tribe / Programme, optionnel) → Nexus Team (nœud feuille, là où Intent vit exclusivement).
Chaque niveau hérite de son parent et peut l'étendre. Il ne peut jamais le remplacer. Une team ne peut pas remplacer un contract intermédiaire ou org : elle peut seulement l'étendre ou, sous conditions explicites, y déclarer une exception.
Nexus Org (root)
└── Nexus Intermediate (BU / Tribe / Programme / Value Stream)
└── Nexus Team (two pizza team)Mécanisme d'enforcement
Chaque contract porte un champ exception-to optionnel. Sans ce champ : extension pure (toujours autorisée). Avec ce champ : exception déclarée, exigeant un champ exception-approved-by validé par l'owner du niveau parent. Le Context Assembler bloque tout bypass silencieux.
---
register: contracts
level: team
exception-to: null # pure extension — always allowed
exception-approved-by: null
---
---
register: contracts
level: team
exception-to: org/contracts/security.md # declared exception
exception-approved-by: security-guild # validated by org owner
---La mise à jour comme chemin de moindre résistance.
Toute base de connaissance meurt de la même façon : les contributions deviennent volontaires, les owners changent de poste, le contenu dérive silencieusement. La gouvernance du Context Nexus est conçue pour que la mise à jour soit le chemin de moindre résistance, pas une discipline supplémentaire.
Chaque artefact porte des métadonnées de cycle de vie : draft → active → stale → deprecated / superseded. Un artefact au statut stale est signalé mais pas supprimé : il est exclu du system prompt et du RAG au-delà d'un seuil configurable.
draft → active → stale → deprecated / superseded Démarrez dès le jour un.
Quelques fichiers rules.md et contracts.md. Pas de RAG, pas de MCP. Le contexte est passé manuellement dans les prompts. Suffisant pour structurer les premières intentions et conventions.
La knowledge est indexée. Les agents récupèrent les Decision Contexts automatiquement. Les specs dans Intent sont structurées en task briefs. Le Context Assembler est une fonction simple.
Les runbooks répétables sont encapsulés en MCP tools. Les quality gates sont exécutables (pas seulement connus). Le registre org des skills est alimenté.
Le Context Assembler est lui-même un agent. Les agent cards (protocole A2A) permettent la découverte dynamique des skills. Les boucles de feedback IA (ship, sync, discovery) alimentent les registres automatiquement.