Context Nexus
Registre Contracts
Assertions vérifiables avec seuils : engineering, produit, UX et data. Les règles que les agents valident avant de proposer un merge.
Que contient Contracts ?
Chaque entrée du registre Contracts est une assertion vérifiable, associée à un seuil, qui peut être évaluée sans jugement humain. C'est ce critère — la vérifiabilité automatisable — qui définit ce qui appartient à Contracts plutôt qu'à Intent ou Knowledge.
Quality gates · Mutation scoring rules · Taux de couverture · Definition of Done · Politiques de sécurité · SLAs de performance · Règles de review & merge
Critères d'acceptance liés aux specs · Seuils de métriques produit (conversion, rétention) · Seuils de significativité A/B · Règles de feature flag
Conformité design system (tokens, composants) · Standards d'accessibilité (niveau WCAG cible) · Core Web Vitals thresholds · Critères de validation utilisateur
Complétude (taux de données manquantes acceptables) · Fraîcheur (SLA de latence des pipelines) · Exactitude (règles de validation schéma) · Traçabilité
L'invariante fondamentale
Humains vs Agents IA
Définit les contrats par domaine, fait évoluer les seuils selon la maturité du produit, arbitre les exceptions.
Valide son propre output avant de proposer un merge, s'auto-corrige quand un contrat n'est pas atteint, exécute les outils de vérification.
Asymétrie : définition vs conformité.
Modes de consommation
L'ensemble des assertions vérifiables (toujours applicables) vont dans le system prompt.
Les outils de vérification (run tests, check accessibilité, valider schéma) sont exposés comme MCP Skills.
Extension vs exception vs override
Trois situations possibles quand un contract de niveau inférieur touche au même périmètre qu'un contract parent :
Extension : ajoute des assertions sur un périmètre non couvert par le parent. Toujours autorisée, pas de validation requise.
Exception : dévie explicitement d'une assertion parente, avec exception-to renseigné et exception-approved-by validé par l'owner du niveau parent.
Override non déclaré : contredit une assertion parente sans champ exception-to. Détecté par le Context Assembler, bloqué et signalé.
Structure d'un artefact Contracts
---
register: contracts
level: team
owner: tech-lead
status: active
consumption-mode: system-prompt
last-validated: 2026-06-03
exception-to: null
exception-approved-by: null
---
# Contract — Search Indexation SLA
## Performance
- P95 results page (standard query): ≤ 200ms
- P95 bulk writer (Elasticsearch flush): ≤ 80ms
- Kafka consumer lag: alert threshold 5,000 messages
## Quality gate
- Mutation score ≥ 80% on indexation pipeline
- No synchronous catalogue write to Elasticsearch (see Intent/directives/event-driven)
## Verification tools
- performance-test.mcp: run load test, return P95 metrics
- mutation-score.mcp: run mutation testing, return scoreArtefact avec exception déclarée
---
register: contracts
level: team
owner: tech-lead
status: active
exception-to: org/contracts/performance.md
exception-approved-by: bu-digital-quality-lead
exception-approved-date: 2026-05-28
---
# Contract — Search Boosting Exception
## Scope
Multi-criteria boosting queries only (relevance score computation > 3 factors).
## Exception
P95 threshold for boosted queries: ≤ 350ms (vs 200ms org standard).
## Justification
Relevance precision > 0.75 drives 3.4x higher conversion.
Accepted trade-off: latency for relevance on complex queries.