Trust Center
Ce que KOREV documente, ce qui est partiellement documenté, ce qui reste à publier — et les limites connues. La transparence fait partie du produit.
Publication technique · v1.0.2
Protocole, modèle de menace, scénarios hostiles, résultats expérimentaux et limites documentés. La vérification porte sur l'intégrité et la continuité au sein de frontières déclarées ; elle ne prouve ni la vérité, ni la conformité réglementaire.
Evidence / Contrôles de confiance
Sources, incertitudes, publication et sécurité : chaque mécanisme a un périmètre. Les badges décrivent des contrôles et des technologies, pas des certifications ni un état de surveillance en temps réel.
Analyse disponible / Validation distincte
Comprendre un blocage fait partie du résultat.
Une analyse peut expliquer les risques, les informations manquantes et les prochaines vérifications tout en conservant un statut de décision non validée. Le statut effectif du dossier reste déterminant.
Mesures décrites dans la documentation technique communiquée. Leur activation et leur portée sont à confirmer pour votre déploiement ; cette présentation ne constitue pas un audit indépendant de l'infrastructure.
Un dossier peut indiquer « consensus non exécuté » ou « intégrité cryptographique non calculée ». Ces états doivent rester visibles et ne valent jamais contrôle réussi. Une preuve d'intégrité ne prouve pas l'exactitude du contenu.
KOREV documente une propriété bornée de continuité après admission sur des frontières déclarées et instrumentées : une admission reconnue par le témoin doit rester représentée et être réconciliée avant qu'une population puisse être classée VERIFIED.
Limites publiées : frontières instrumentées seulement, pas de complétude globale, pas de vérité sémantique, pas de certification, pas encore de reproduction tierce indépendante.
Lire la note techniqueKOREV Evidence est exploité comme un produit déployable : releases de production, procédure unique de mise en production, contrôles CI bloquants, health checks, versioning du commit déployé et procédures de rollback/diagnostic.
Nous ne publions pas de TRL produit tant qu'une requalification formelle de l'ensemble intégré n'a pas été menée ; l'ancienne évaluation TRL du composant PRISM est archivée.
Trois couches, Atlas (moteur de raisonnement d'entreprise), Evidence (espace de travail des agents) et PRISM (contrôle des traitements critiques), placées entre le processus métier et l'infrastructure client, avec cinq mécanismes transverses : supervision humaine, piste d'audit, gouvernance, sécurité, contrôle des données.
Contrôles techniques : chiffrement, isolation, gestion des accès, journalisation, dans l'environnement de déploiement choisi.
Certifications de sécurité (ISO 27001, HDS, SecNumCloud…) : aucune certification n'est revendiquée sur le site actuel ; publication au fur et à mesure des démarches effectives.
Page SécuritéMécanismes intégrés à l'architecture : identification des modèles, traces, sources, validation humaine, règles, divergences, historique, revue, permissions, responsabilités.
Atlas, l'Enterprise LLM de KOREV AI, spécialisé sur vos connaissances d'entreprise et géré avec registre des versions.
Formalisation de la liste publique des modèles supportés par version et politique de mise à jour.
AtlasLocalisation, circulation et traitement des données définis par l'organisation ; KOREV n'utilise pas les données client pour entraîner des modèles publics.
Architecture pensée pour faciliter le respect des exigences de supervision, de traçabilité et de gouvernance applicables selon les usages. Pas une certification de conformité.
Points de validation définis processus par processus ; escalade automatique quand les règles ne sont pas satisfaites ; validations tracées et attribuées.
Couche de contrôle : confrontation multi-modèles, détection des divergences, consensus configurable, seuils, règles, fail-closed, supervision humaine.
KOREV publie déjà des résultats ciblés sur Decision Evidence et maintient des campagnes de validation métier ; les benchmarks Atlas et les mesures de performance bout-en-bout restent à consolider avant publication.
Benchmarks Atlas, latence, coût et charge à publier lorsqu'ils seront rejoués sur un protocole public stable.
Comment un processus est qualifié, piloté puis industrialisé : Pulse (diagnostic), Pilote (premier cas d'usage), Industrialisation, Déploiement multi-processus.
Principes : l'humain reste responsable des étapes qui l'exigent ; aucun absolu marketing ; les limites sont documentées.
Cloud européen, hybride, on-premise ; environnement isolé selon projet.
Ingénierie & Auditabilité
Inventaire des affirmations, mesures et mécanismes d'ingénierie KOREV. Chaque signal public est relié à une méthode, un périmètre précis et une limitation méthodologique explicite.
14
14 profils actifs sous agents/ : compliance, contradictor, default, developer, finance, hacker, infrastructure, legal_drafting_guarded, legal_safe, marketing, medical, multitask, researcher, sales. Le dossier _example est exclu.
3 niveaux
Architecture CriticalityRouter (ADR-010 / ADR-011) : LEVEL 1 (requête simple : consensus bypassé par défaut, baseline sources obligatoire) ; LEVEL 2 (zone professionnelle : analyse/conseil, consensus activable par opt-in explicite utilisateur ou force_consensus caller, baseline sources) ; LEVEL 3 (décision critique, responsabilité, litige, action critique : consensus PRISM obligatoire, mode strict si domaine critique). Priorité fail-closed systématique en cas d'ambiguïté.
RSA-PSS / HMAC
Couche critical_output (ADR-010) : signature v2 liant input_hash, output_hash, consensus_result_hash, criticality_level, policy_id/version, timestamp, trace_id. Algorithme RSA-PSS-SHA256 en production, repli HMAC selon configuration.
v1.0.2
Admissions reconnues par le témoin sur le chemin configuré ; continuité d'historique, réconciliation admission→terminal, fraîcheur du checkpoint et inventaire du bundle.
Note technique v1.0.2 + protocole v2 + vérificateur + scénarios hostiles enregistrés.67 tests
Suite ciblée decision_pack / decision_capture / witness, hors ensemble complet du produit.
python -m unittest discover -s tests -p 'test_decision*.py' -v22 / 22
Étude synthétique déterministe, sans appels LLM externes ni trafic réseau externe.
Deux exécutions decision-capture-v2 ; 11 scénarios hostiles par lot.5 checks requis
Chaîne de mise en production du backend Evidence : branche main protégée, PR obligatoire, 5 checks requis, enforce_admins, garde-fous de build/deploy, drain avant redémarrage, /healthz et VERSION.json.build_commit.
Runbook d'exploitation + protection de branche + scripts deploy_prod.sh / stamp_version.py.2/3
API canonique run_consensus() : quorum 2/3 requis sur les votes valides émis par les modèles confrontés.
Spécification formelle de consensus et implémentation run_consensus().Fail-closed testé
Comportement fail-closed rejoué sur les contrats de confiance, le journal et les providers couverts par la suite de preuve (TrustContext, tests adversariaux).
Modèle de langage et capacités de raisonnement contextualisé via documents internes, référentiels, procédures et interactions contrôlées avec les agents KOREV.
La conformité réglementaire dépend du contexte, du système, de son usage et du rôle de l'organisation. KOREV fournit des capacités techniques de gouvernance ; elle ne constitue pas à elle seule une certification juridique de conformité.