NeuralWall Rules Kit

ADR-0002 — Modèle de contenu et gouvernance

  • Statut : Accepted
  • Date : 2026-06-03
  • Contexte associé : ADR-0001, docs/control-taxonomy.md

Contexte

Au-delà du format (ADR-0001), il faut décider ce qu'est une fiche, comment garantir sa qualité, et sous quelles conditions NeuralWall (commercial) peut l'ingérer. Le portail étant ouvert, c'est aussi un risque : réputation (fiche faible mergée) et empoisonnement du RAG (mauvaises règles → mauvaises règles générées).

Décisions

1. Granularité

Une fiche = un scénario de déploiement (ex. « exposer un service web HTTPS public »), pas une app brute ni une stack entière. La composition se fait via un champ includes réservé au schéma ; les fiches de Phase 1 restent simples et auto-contenues.

2. Champs auteurés vs dérivés

mitre_attack[] et threat_model sont des champs structurés auteurés par un expert (ils ne se déduisent pas des enums). La carte RAG les rend. C'est ce qui préserve la garantie « zéro drift » de l'ADR-0001.

3. Trust tier

Frontmatter obligatoire : trust_tier ∈ {community, reviewed, verified}.

  • community : contribution non revue.
  • reviewed : revue par un mainteneur.
  • verified : validée par un éditeur/source autoritaire. NeuralWall pondère ce tier à l'ingestion (une fiche community ne pèse pas comme une verified). Premier rempart contre l'empoisonnement.

4. Garde-fous qualité

  • Schéma (structure) ET linter sécurité distincts. Le linter, minimal en Phase 1, relève les anti-patterns (allow sans profils, decryption: none sortant risqué, unknown non justifié). Extensible.
  • Bump de version (CONTRIBUTING) : patch = clarification, minor = ajout de contrôle, major = changement d'intent/structurant.

5. Licence du contenu

  • Licence : CC-BY-4.0. Permissive, autorise l'usage commercial et la dérivation (NeuralWall peut ingérer/dériver), attribution attractive pour les contributeurs.
  • Provenance des contributions : DCO (Developer Certificate of Origin, sign-off git commit -s). Standard à faible friction qui atteste que le contributeur a le droit de soumettre sous CC-BY-4.0. Pas de CLA lourd.
  • CC0 envisagé puis écarté : l'attribution CC-BY est plus mobilisatrice pour une communauté, et l'ingestion NeuralWall reste sans friction sous CC-BY.
  • ⚠️ Décision la plus douloureuse à changer rétroactivement (consentement de chaque contributeur passé). À faire valider par un juriste avant lancement public, mais ne bloque plus la construction Phase 1.

Alternatives écartées

  • Fiche = une app : trop atomique, ne capture pas les flux réels (ingress + egress + deps). Fiche = stack complète : monolithique, non réutilisable.
  • Carte RAG déduite des enums : casse « zéro drift », perd la qualité experte du threat model.
  • Pas de trust tier : laisse NeuralWall ingérer le tout-venant à poids égal → risque d'empoisonnement inacceptable.

Conséquences

  • (+) Fiches réutilisables et composables, qualité traçable, ingestion pondérée par la confiance.
  • (−) Le threat model auteuré demande de l'expertise → friction de contribution à documenter dans CONTRIBUTING (gabarit, exemples).
  • (−) CC-BY impose de tracer l'attribution → à gérer dans le rendu et la doc de contribution (le DCO couvre la provenance côté commit).