Iris

Iris — arrêtez de livrer des agents à l'aveugle

Iris évalue chaque exécution d'agent pour la qualité, la sécurité et le coût — sur votre machine, sans SDK et sans compte. La plupart des projets d'agents vérifient la qualité en exécutant quelques invites mémorisées et en examinant la sortie. Iris remplace cela par des chiffres que vous pouvez auditer : les exécutions de votre agent atterrissent dans une base de données SQLite sur votre disque, 25 règles intégrées les notent de manière déterministe — PII, injection d'invite, marqueurs d'hallucination, seuils de coût et les propres appels d'outils de l'agent — gratuitement, sans appels LLM, et un juge LLM optionnel avec un plafond de coût fixe par évaluation gère les questions sémantiques. Chaque règle est inspectable et modifiable, car un juge que vous ne pouvez pas auditer n'est que des impressions avec un chiffre dessus. Licence MIT, aucune télémétrie. Rien ne quitte votre machine sauf si vous activez l'une de ces options : un point de terminaison OpenTelemetry (IRIS_OTEL_ENDPOINT), qui exporte les traces vers le collecteur que vous nommez ; le juge LLM avec votre propre clé, qui envoie le texte qu'il juge à ce fournisseur, et dont la vérification de citation récupère les pages qu'une sortie cite ; ou un webhook, qui publie les identifiants, le verdict et les noms de règles, jamais le texte, à l'adresse que vous définissez.

Nécessite Node.js 22.13 ou version ultérieure. Vérifiez avec node --version.

_{La base de données de démonstration, enregistrée par scripts/demo-media.mts ; la source est demo.mp4. Une image fixe : dashboard-overview.png.}

Un échec à l'écran en 60 secondes

Aucun câblage d'agent, aucune configuration — une seule commande :

npx @iris-eval/mcp-server --demo

Cela initialise une base de données de démonstration — cinq petits agents, deux semaines d'exécutions, chaque verdict du moteur lui-même — et sert le tableau de bord à http://localhost:6920 (votre navigateur s'ouvre automatiquement au premier lancement). Le tableau de bord atterrit sur Échecs : ce qui a échoué, du pire au plus récent, chaque carte nommant la règle et ses preuves. Cela vaut la peine de cliquer — une fuite de PII détectée par les règles de sécurité, une directive cachée dans un message de forum que le résumeur a suivie, un nombre que le document source n'a jamais dit, deux exécutions sur les mêmes douze questions comparées avec un intervalle (Exécutions), une règle personnalisée déployée et une en pause avec leurs lignes d'audit, et un score de juge LLM échoué avec sa justification.

Les données de démonstration vivent dans leur propre base de données (demo.db dans votre répertoire personnel Iris — ~/.iris sur macOS/Linux, %USERPROFILE%\.iris sur Windows) et ne se mélangent jamais avec vos vraies traces. Supprimez tout avec une seule commande :

npx @iris-eval/mcp-server --demo-clear

Connectez votre propre agent

D'abord, prouvez que l'installation fonctionne sur cette machine — elle fonctionne hors ligne et n'ouvre rien à vous :

npx @iris-eval/mcp-server --self-test   # exit 0 = healthy

Ensuite, ajoutez Iris à votre client MCP. Une seule commande écrit le fichier de configuration du client lui-même, conserve tous les autres serveurs qu'il contient et épingle la version que vous avez exécutée :

npx -y @iris-eval/mcp-server install claude-code

Les clients : claude-code, claude-desktop, cursor, windsurf, continue, vscode, cline, zed, codex, gemini. install --list montre ceux trouvés sur cette machine, l'Iris que chacun exécute et le fichier qu'il lit ; install <client> --uninstall retire Iris à nouveau. Chaque client partage une base de données, donc après une mise à niveau, déplacez-les tous en même temps avec install --upgrade (Mise à jour). Redémarrez le client pour le charger.

Claude Desktop : un clic. Chaque version à partir de 0.20.0 joint iris-eval.mcpb, un MCP Bundle : téléchargez la dernière, ouvrez-la, et Claude Desktop affiche une boîte de dialogue d'installation. Rien dessus n'est requis — une clé Anthropic ou OpenAI pour le juge LLM est facultative, et le tableau de bord est un interrupteur qui démarre éteint. Le bundle contient le paquet npm et ses dépendances, donc rien d'autre n'a besoin d'être installé : Claude Desktop l'exécute sous le Node qu'il fournit lorsque ce Node est 22.13 ou plus récent (Claude Desktop 1.1.6679 fournit 24.13), et Iris stocke les traces avec le SQLite intégré de Node, dans le même ~/.iris que toute autre installation utilise. Les notes de version montrent comment vérifier sa signature et son attestation de construction.

Il fonctionne dans n'importe quel client MCP, et chaque client qu'il nomme a une ligne avec ce qui a été réellement vérifié. Vérifié à chaque exécution CI : Claude Code, Gemini CLI — le vrai client démarre Iris à partir de la configuration écrite par l'installateur et signale qu'il est connecté (claude mcp list, gemini mcp list), sur Linux, macOS et Windows ; les hooks du plugin de capture de Claude Code sont également pilotés via les vrais scripts. Revendiqué à partir de la documentation MCP de chaque client — l'installateur écrit la forme de configuration que le client documente, et cet écrivain est testé sur la forme ; personne du côté Iris ne l'a vu se connecter : Claude Desktop, Cursor, Devin Desktop (Windsurf), Continue, VS Code, Cline, Zed, OpenAI Codex CLI. Chaque ligne avec sa source et la date à laquelle elle a été lue : https://iris-eval.com/clients. À la main à la place, un bloc, tableau de bord inclus :

{
  "mcpServers": {
    "iris-eval": {
      "command": "npx",
      "args": ["-y", "@iris-eval/mcp-server", "--dashboard"]
    }
  }
}

Votre client liste les douze outils d'Iris à la connexion, et le tableau de bord sert à http://localhost:6920. Maintenant, collez ceci à votre agent :

Journalisez cette dernière tâche dans Iris et évaluez la sortie.

La trace atterrit sur le tableau de bord avec ses scores. Vous préférez le serveur MCP sans tête ? Supprimez --dashboard des arguments — vous pouvez ouvrir le même tableau de bord à tout moment avec npx @iris-eval/mcp-server --dashboard.

Une chose à savoir d'avance : les outils MCP sont appelés lorsque le modèle décide de les appeler. Iris n'intercepte pas votre agent, donc les traces sont journalisées lorsque votre agent demande de les journaliser — soit parce que vous le lui avez dit, soit parce que votre code appelle directement les outils. Demandez à votre agent de « journaliser ceci dans Iris et l'évaluer » et il le fera. Si vous voulez une capture qui ne dépend pas du choix du modèle, POST /api/v1/traces fait exactement cela — votre code envoie la trace via HTTP simple, sans modèle dans la boucle (voir docs/http-ingest.md). La CLI et les hooks hôte sur la feuille de route seront des clients légers sur le même point de terminaison.

Capture via HTTP (sans modèle dans la boucle)

Le point de terminaison d'ingestion vit sur le port du tableau de bord — 6920 par défaut, pas le port de transport MCP — et il n'existe que pendant que le tableau de bord est en cours d'exécution. Passez --dashboard (ou définissez IRIS_DASHBOARD=true) ; --transport http seul ne le démarre pas, et une requête au port de transport renvoie 404. Avec le tableau de bord actif, tout ce qui peut envoyer une requête HTTP peut journaliser une trace — et éventuellement exécuter les évaluations déterministes dans la même requête. GET /api/v1/capabilities sur le même port indique ce que ce serveur peut juger, ce dont chaque règle a besoin, l'état du juge avec les étapes qui l'activent, et les limites — le même objet que la ressource MCP iris://capabilities sert — donc un appelant HTTP a le cadre qu'un client MCP obtient à l'initialisation :

curl -s -X POST "http://127.0.0.1:6920/api/v1/traces" \
  -H "Content-Type: application/json" \
  -d '{
    "agent_name": "support-bot",
    "input": "What is the refund policy?",
    "output": "Refunds are available within 30 days of purchase.",
    "evaluate": true,
    "eval_type": "safety"
  }'

Renvoie 201 avec le trace_id stocké et le résultat de l'évaluation (en mode --demo, le point de terminaison refuse les écritures avec 403, donc les données de démonstration ne se mélangent jamais avec les vôtres). Le point de terminaison accepte le même corps que l'outil log_trace et se trouve derrière la même pile de middleware que le reste du tableau de bord : liaison de boucle locale et garde anti-rebinding DNS par défaut, plus l'authentification Bearer lorsque vous en définissez une. Deux faits simples à son sujet : il accepte les écritures non authentifiées sauf si Iris a été démarré avec --api-key (ou IRIS_API_KEY) — la liaison de boucle locale est ce qui le garde sur votre machine par défaut, donc définissez une clé avant de lier au-delà de la boucle locale ; et ce qu'il stocke est textuel — input et output atterrissent dans iris.db exactement comme envoyés, y compris tout texte que no_pii va ensuite signaler. Contrat complet, référence de champ et sémantique d'erreur : docs/http-ingest.md.

Capturez chaque tour de Claude Code (facultatif)

/plugin marketplace add iris-eval/mcp-server
/plugin install iris-eval-capture@iris-eval

Un deuxième plugin, installé séparément : trois hooks enregistrent l'invite de chaque tour, les appels d'outils et la réponse finale et les remettent à iris-eval ingest, détachés, avec les plages critiques masquées dans le texte d'évaluation stocké — une capture qui ne dépend pas du modèle décidant d'appeler un outil. Il ne journalise jamais un tour que le modèle a déjà journalisé, n'imprime jamais, ne bloque jamais, n'envoie jamais rien nulle part. L'installation de iris-eval seul ne change rien à votre boucle de tours. Limites et suppression : claude-plugin-capture/README.md.

Python

pip install iris-eval

from iris_eval import IrisClient
iris = IrisClient()                       # IRIS_URL, or the running dashboard's runtime.json
iris.evaluate_output("…", input="…", agent_name="support-bot")["verdict"]   # {"state": "pass", "basis": "clean", "by": []}

Un client léger sur l'API HTTP du serveur 0.16.0 et ultérieur, versionné séparément — iris_eval.__version__ et la page PyPI portent son numéro, qui n'est pas celui du serveur : log_trace(), evaluate_output(), get_traces(), get_trace(), health(), capabilities(), synchrone et asynchrone, réponses typées, la propre phrase du serveur sur un refus — et un plugin pytest : un fixture iris et assert_iris(output, expect="pass") qui affirme sur l'état du verdict. packages/python/README.md.

Enregistrez chaque appel OpenAI et Anthropic

from iris_eval import wrap_openai
client = wrap_openai(OpenAI(), agent_name="support-bot")   # every call: a GenAI span to POST /v1/traces, scored

import { wrapOpenAI } from '@iris-eval/sdk';
const openai = wrapOpenAI(new OpenAI(), { agentName: 'support-bot' });

Enveloppez le client fournisseur une fois et chaque appel de modèle devient un span GenAI OpenTelemetry envoyé à la porte OTLP, stocké avec son entrée, sa sortie, son utilisation de jetons et ses appels d'outils, et noté : une capture qui ne dépend pas du modèle appelant un outil. wrap_openai / wrap_anthropic dans le client Python ; wrapOpenAI, wrapAnthropic et irisMiddleware pour le Vercel AI SDK dans @iris-eval/sdk. Les deux ne sont pas encore publiés (la prochaine version iris-eval sur PyPI ; @iris-eval/sdk est construit à partir de la source jusqu'à sa première version npm). Les flux, les aides de flux des SDK et les appels d'outils sont couverts, le client d'origine n'est pas modifié, et une panne d'Iris ne casse jamais un appel — packages/sdk/README.md, packages/python/README.md.

Notez chaque exécution LangChain et LangGraph

from iris_eval.langchain import IrisCallbackHandler
graph.invoke(inputs, config={"callbacks": [IrisCallbackHandler(agent_name="support-bot")]})

Chaque exécution de niveau supérieur devient une trace (l'exécution, ses appels de modèle, ses appels d'outils et ses nœuds de graphe comme spans GenAI) avec son entrée, sa sortie, ses appels d'outils, son utilisation de jetons et un verdict. Python dans le client (prochaine version, pas encore publiée sur PyPI), JavaScript comme @iris-eval/langchain (pas encore publié sur npm). Les deux sont prouvés en CI contre une vraie application LangGraph avec un modèle scripté ; l'export OpenTelemetry de LangSmith est prouvé de la même manière — docs/otel-recipes.md.

Une porte CI, aucun serveur nécessaire

npx -y @iris-eval/mcp-server ingest --file traces.ndjson --evaluate --fail-on detector_veto

Ou l'action GitHub (0.16.0), qui fait échouer le travail sur les verdicts que vous nommez, écrit le reçu dans le résumé du travail et le publie comme un commentaire de demande de tirage mis à jour en place : uses: iris-eval/mcp-server/.github/actions/gate@v0.19.0 avec traces: traces.ndjson — docs/ci-gate.md. Une quatrième porte (0.15.0) : POST /v1/traces sur le port du tableau de bord accepte le JSON ou protobuf OTLP/HTTP que votre instrumentation OpenTelemetry émet déjà (l'exportateur du SDK Python ne parle que protobuf, c'est donc aussi la porte Python), et chaque trace OTLP devient une trace Iris avec ses spans — docs/otel-integration.md ; une recette par framework (Pydantic AI, Google ADK, LangGraph via LangSmith, CrewAI, le SDK OpenAI Agents en Python et JavaScript, LlamaIndex, AutoGen, Microsoft Agent Framework, Semantic Kernel, le SDK Vercel AI et Mastra), chacune prouvée par un fixture, dans docs/otel-recipes.md. ingest lit une trace JSON (ou NDJSON, une par ligne) depuis stdin ou un fichier, la stocke, l'évalue selon exactement les règles que evaluate_output exécute, imprime une ligne JSON par trace avec le verdict et sa base, et sort avec le code 1 lorsqu'un verdict correspond à --fail-on. --dataset <id|label> restreint cette porte aux clés de cas d'un jeu de données (POST /api/v1/datasets promeut les clés de cas d'une exécution en un), donc un travail échoue uniquement sur les cas que vous avez choisis. La recette complète, les codes de sortie et les huit bases sont dans docs/ci-gate.md.

Écrire une règle comme du code

eval.plugins dans config.json charge les règles que vous avez écrites — un module ES dont l'export par défaut est { name, kind, mechanism, version, needs, evaluate(ctx) } — épinglé par le sha256 du fichier, donc un fichier modifié depuis son épinglage refuse le démarrage plutôt que de s'exécuter. Un plugin chargé se déclenche comme un intégré et s'affiche sur list_rules sous plugins. Le contrat, la recette de hachage et ce qu'un plugin peut retourner : docs/plugins.md.

Utiliser le moteur dans votre propre processus

Le moteur d'évaluation est importable — pas de serveur, pas de base de données, pas de modèle :

import { EvalEngine, defaultConfig } from '@iris-eval/mcp-server/engine';

const engine = new EvalEngine(defaultConfig.eval.defaultThreshold, defaultConfig.eval.ruleThresholds, defaultConfig.eval);
const result = await engine.evaluateAll({ output: answer, input: prompt, toolCalls, costUsd });
result.verdict.state;       // 'pass' | 'fail' | 'unknown', with result.verdict.basis and result.interpretations

Le même moteur, les mêmes règles et le même compositeur que le serveur exécute ; builtInRules(), createCustomRule(), compose() et les lecteurs de précision publiée sont exportés à côté.

Un client typé pour la route HTTP

import { createClient } from '@iris-eval/mcp-server/client';

const iris = createClient({ baseUrl: 'http://127.0.0.1:6920', apiKey: process.env.IRIS_API_KEY });
const { trace_id, evaluation } = await iris.logTrace({ agent_name: 'support-bot', input, output, tool_calls, evaluate: true });
evaluation?.verdict?.state;  // the same object evaluate_output returns

Un seul corps sur chaque porte : c'est ce que log_trace et iris-eval ingest acceptent. Un refus lève IrisClientError avec la phrase et le statut du serveur lui-même. Les deux sous-chemins sont vérifiés à partir d'une archive tar compressée à chaque build.

Vérifier votre installation

npx @iris-eval/mcp-server --self-test   # offline diagnostic; exit 0 = healthy, 1 = a check failed
npx @iris-eval/mcp-server --version     # prints the bare version, e.g. 1.2.3

--self-test crée d'abord votre répertoire Iris s'il manque et vérifie qu'il est inscriptible (sortie 1, en nommant le chemin, sinon), signale où se trouve l'index de recherche de votre base de données (entier, combien de traces une construction en arrière-plan a indexées jusqu'à présent, ou pas de FTS5 sur ce SQLite), lit le schéma de votre base de données (sortie 1, avec le correctif, lorsque cette version ou un client MCP épinglé à une version plus ancienne ne peut pas l'ouvrir), puis exécute ses vérifications — aller-retour de stockage, un SSN planté et une injection plantée attrapés par les règles de sécurité, démarrage du tableau de bord, la protection contre le rebinding DNS — dans un répertoire temporaire isolé. Votre vraie base de données est seulement lue, jamais modifiée. Tout ce qu'Iris écrit vit sous un seul répertoire, votre répertoire Iris : ~/.iris par défaut (%USERPROFILE%\.iris sur Windows), ou là où pointe IRIS_HOME. C'est là que vivent iris.db, config.json, custom-rules.json, audit.log, preferences.json et les fichiers de démonstration ; pointez IRIS_HOME vers un répertoire de brouillon pour essayer Iris sans toucher à vos vraies données.

claude mcp add --transport stdio iris-eval -- npx -y @iris-eval/mcp-server

{
  "servers": {
    "iris-eval": {
      "command": "npx",
      "args": ["-y", "@iris-eval/mcp-server"]
    }
  }
}

{
  "context_servers": {
    "iris-eval": {
      "command": "npx",
      "args": ["-y", "@iris-eval/mcp-server"],
      "env": {}
    }
  }
}

[mcp_servers.iris-eval]
command = "npx"
args = ["-y", "@iris-eval/mcp-server"]

Autres méthodes d'installation

# Global install (recommended for persistent data and faster startup)
npm install -g @iris-eval/mcp-server
iris-eval --dashboard

# Docker — two servers, two ports: 3000 = MCP HTTP transport,
# 6920 = dashboard (which also serves the POST /api/v1/traces ingest endpoint).
# The image binds 0.0.0.0 inside the container, so a key is required (see Production).
# The volume is the Iris home: the database, deployed rules and audit log persist in it.
docker run -p 3000:3000 -p 6920:6920 -v iris-data:/data \
  -e IRIS_API_KEY="$(openssl rand -hex 32)" ghcr.io/iris-eval/mcp-server

Astuce : L'installation globale (npm install -g) stocke les traces de manière persistante à ~/.iris/iris.db. Avec npx, les traces persistent au même endroit, mais le démarrage est plus lent en raison de la résolution des paquets.

Ce que vous obtenez

Où cela va ensuite : la carte des capacités — chaque question qu'Iris peut recevoir sur chaque sujet, avec ce qu'il a et ce qui lui manque — et les trois pistes.

Mesuré, pas revendiqué

Chaque règle intégrée publie une précision, un rappel et un F1 avec des intervalles de confiance à 95 %, mesurés sur un corpus labellisé qui vit dans ce dépôt (proof/corpus/) et se régénère avec une seule commande — npm run proof — hors ligne, sans clé ni modèle dans la boucle. Ces nombres sont de deux types différents, et la page ne les additionne jamais : certaines règles sont mesurées par rapport à des labels qu'un modèle a donnés en lisant l'échec lui-même, ce qui mesure la détection ; les autres sont vérifiées par rapport à leur propre définition documentée, appliquée indépendamment, ce qui montre que le code implémente sa formule et ne dit rien sur le fait que la formule attrape l'échec. proof/RESULTS.md et la page de preuve marquent chaque règle. La CI réexécute la mesure à chaque pull request et échoue si les nombres validés diffèrent de ce que le code produit, donc une règle ne peut pas changer sans que ses nombres changent avec elle. Les nombres sont sur iris-eval.com/proof et dans proof/RESULTS.md ; comment le corpus a été créé, ce qu'il n'est pas, et comment lire un intervalle sont dans docs/proof.md. Le corpus est synthétique et labellisé par modèle — un label humain en aveugle est en attente, et la page le dit ; node proof/blind-sample.mjs tire l'échantillon reproductible qui le réglera.

Outils MCP

Iris enregistre douze outils que tout agent compatible MCP peut invoquer — cycle de vie des traces et des règles, comparaison entre exécutions, LLM-comme-juge et vérification sémantique des citations :

• log_trace — Journalise une exécution d'agent avec des spans, des appels d'outils, l'utilisation de jetons et le coût ; passez evaluate: true pour le noter dans le même appel
• evaluate_output — Note la qualité de la sortie par rapport aux règles de complétude, de pertinence, de sécurité et de coût (heuristiques, déterministes, gratuites)
• get_traces — Interroge les traces stockées avec filtrage, pagination et plage temporelle, et trouve l'exécution où l'agent a dit quelque chose avec q : recherche plein texte sur l'entrée, la sortie, les valeurs d'appels d'outils et les métadonnées, classée, avec les mots correspondants marqués
• list_rules — Énumère les règles d'évaluation personnalisées déployées (lecture seule)
• deploy_rule — Enregistre une nouvelle règle d'évaluation personnalisée pour qu'elle se déclenche à chaque evaluate_output de cette catégorie
• delete_rule — Supprime une règle personnalisée déployée (destructif, idempotent)
• delete_trace — Supprime une seule trace stockée par ID (destructif, limité au locataire)
• evaluate_with_llm_judge — Évaluation sémantique via LLM (Anthropic ou OpenAI). Sept modèles : exactitude, utilité, sécurité, correction, fidélité, tâche_terminée, pertinence. Plafonné en coût, tarification par évaluation divulguée. Apportez votre propre clé API (IRIS_ANTHROPIC_API_KEY ou IRIS_OPENAI_API_KEY) — Iris ne fait pas de proxy ni ne relaie les appels LLM.
• verify_citations — Extrait les citations de la sortie (numérotées, auteur-année, URL, DOI), récupère les sources derrière un résolveur protégé contre les SSRF et avec liste blanche de domaines, et utilise un juge LLM pour vérifier si chaque source soutient réellement l'affirmation citée. HTTP sortant sur option. Même exigence BYOK que evaluate_with_llm_judge.
• compare_runs — Un changement a-t-il rendu l'agent pire ? Compare deux exécutions d'évaluations stockées : un test exact apparié lorsque les exécutions partagent des clés de cas, un intervalle sur la différence sinon, un honnête « impossible à dire » avec le nombre de cas qu'il faudrait, ou « équivalent dans une marge ». Chaque règle porte son propre test unilatéral, corrigé ensemble (Benjamini–Hochberg) pour que vingt règles ne puissent pas fabriquer une régression
• compare_traces — Avec quelle fiabilité l'agent répond-il à la même question ? Taux de réussite par cas avec intervalles, cas instables en premier, et un taux global qui respecte les répétitions
• evaluate_runs — Re-note chaque trace d'une exécution sous les règles actuelles dans une nouvelle exécution, pour qu'un changement de règles ne soit jamais lu comme un changement d'agent

Activer le juge LLM (optionnel ; les règles déterministes n'en ont jamais besoin)

1. Obtenez une clé API auprès d'Anthropic ou d'OpenAI.
2. Placez-la dans l'environnement du processus qui exécute Iris, pas seulement dans votre shell. Claude Code, Claude Desktop, Cursor et la plupart des clients MCP : le bloc « env » de l'entrée iris-eval dans votre configuration MCP — « iris-eval » : { « command » : « npx », « args » : [« -y », « @iris-eval/mcp-server »], « env » : { « IRIS_ANTHROPIC_API_KEY » : « sk-ant-... » } } (IRIS_OPENAI_API_KEY pour une clé OpenAI). Docker : -e IRIS_ANTHROPIC_API_KEY=... sur la commande run. HTTP ou CI : exportez-la avant de démarrer iris-eval.
3. Redémarrez la session MCP. Un processus en cours d'exécution ne voit jamais une variable définie après son démarrage.
4. Confirmez depuis votre client : lisez iris://capabilities — judge.enabled doit y être true. Une clé exportée dans votre shell n'est pas transmise au processus que votre client lance, sauf si sa configuration la liste. Sur une machine, npx @iris-eval/mcp-server --self-test affiche la ligne du juge pour ce shell, et GET /api/v1/health rapporte judge.enabled sur un tableau de bord en cours d'exécution.
5. Garde de dépense : chaque appel est plafonné par IRIS_LLM_JUDGE_MAX_COST_USD_PER_EVAL (défaut 0,25 USD) et refusé avant toute dépense si le pire cas le dépasserait. Iris appelle directement le fournisseur avec votre clé et ne la transmet jamais par proxy.
6. Optionnel : définissez IRIS_RELEVANCE_JUDGE_MODEL sur un identifiant de modèle tarifé (claude-haiku-4-5, par exemple) pour que answers_the_ask demande au juge si chaque réponse traite sa demande, et échoue une réponse hors sujet. C'est un appel de juge par évaluation qui porte une entrée, sur votre clé et sous le plafond ci-dessus ; la clé seule ne l'active jamais. Chaque appel envoie cette entrée et cette sortie au fournisseur du modèle, avec les indicateurs de données personnelles et d'identifiants no_pii remplacés d'abord (IRIS_RELEVANCE_JUDGE_REDACT=off les envoie tels quels). Cela dépense au plus IRIS_RELEVANCE_JUDGE_DAILY_BUDGET_USD par jour UTC (défaut 1 USD) et fait au plus IRIS_RELEVANCE_JUDGE_MAX_CALLS_PER_REQUEST appels par requête (défaut 20) ; au-delà de l'un ou l'autre, answers_the_ask lit la demande lexicalement et explique pourquoi.

Lorsque IRIS_OTEL_ENDPOINT est configuré, les appels log_trace émettent également une exportation JSON OTLP/HTTP au mieux-effort vers n'importe quel collecteur OpenTelemetry (Jaeger, Grafana Tempo, Datadog OTLP, Honeycomb, etc.). Voir docs/otel-integration.md.

Comment passed est décidé

evaluate_output renvoie à la fois un indicateur score et un indicateur passed — ils répondent à des questions différentes :

• score (0..1) est la moyenne pondérée des règles qui ont été exécutées — un gradient de qualité.
• passed est le verdict expédier/ne pas expédier, et le score n'est jamais consulté pour cela. Un compositeur lit chaque règle selon le type d'affirmation qu'elle fait : une politique que vous avez configurée bloque ; un détecteur critique oppose son veto ; une vérification critique qui a été demandée et n'a pas pu répondre rend le verdict inconnu (passed: false) plutôt que propre ; chaque détecteur restant se combine en une probabilité que la sortie soit mauvaise, pesée contre le ratio de perte que vous indiquez dans eval.falsePassCost (défaut 1, donc le seuil est 0,5). verdict.basis nomme la couche qui a décidé et verdict.by les règles, et verdict.also liste chaque couche ultérieure qui l'aurait aussi décidé ; interpretations[] dit pourquoi une règle qui a échoué n'a pas décidé et quel paramètre changerait cela, et nomme toute question qui n'a pas été jugée et l'entrée qui permettrait de la juger.

Les véritables violations de sécurité échouent durement. Par défaut, no_pii, no_injection_patterns et no_blocklist_words sont des règles critiques : si l'une échoue, l'évaluation rapporte passed: false peu importe comment les autres règles ont noté, et la réponse nomme les coupables dans critical_failures. Un SSN divulgué ne peut pas être moyenné. Quelles règles intégrées sont critiques est un paramètre de déploiement (eval.criticalRules / eval.nonCriticalRules) ; chaque résultat de règle porte l'indicateur critical effectif et criticalSource, et list_rules rapporte l'effectif que ce serveur applique. Les règles personnalisées déployées avec severity: "high" ou "critical" échouent durement de la même manière ; les sévérités low/medium n'affectent que le score. Une limite à connaître, énoncée de la même manière sur chaque surface : une règle critique qui a été ignorée (contexte manquant, définition cassée ou regex tuée au budget du bac à sable) n'a pas jugé la sortie et ne oppose pas de veto — chaque telle règle est nommée dans critical_skipped. Une passerelle qui doit échouer fermée traite un critical_skipped non vide comme inconnu, pas propre, et peut traiter tout budgetExceeded ignoré dans rule_results de la même manière.

Pour les passerelles CI : si vous omettez eval_type, chaque bundle s'exécute — complétude, pertinence, sécurité, coût et toutes les règles personnalisées — et la réponse dit eval_type: "all" avec un note que le défaut a été exécuté, plus une carte categories par bundle. Un bundle sans rien à juger (coût sans cost_usd, pertinence sans input) rapporte passed: null là — non évalué, non échoué — et ne compte jamais dans le verdict. La réponse fait toujours écho au eval_type qui a été exécuté, pour que votre passerelle puisse vérifier la couverture ; appuyez-vous sur passed pour le verdict et nommez un bundle uniquement lorsque vous voulez une exécution plus étroite.

Créer une règle personnalisée

Deux façons d'ajouter une règle. Les règles en ligne accompagnent un seul appel evaluate_output (custom_rules, jusqu'à 10 par appel) ; elles se déclenchent aux côtés du bundle eval_type que vous avez choisi, ou seules avec eval_type: "custom". Les règles déployées sont enregistrées une fois avec deploy_rule, persistent dans custom-rules.json sous votre répertoire Iris, et se déclenchent à chaque futur evaluate_output de leur evalType. La définition a la même forme dans les deux cas :

deploy_rule enveloppe la définition avec name, un description optionnel, evalType (completeness · relevance · safety · cost · custom) et severity. La sévérité dit ce qu'un échec signifie : low/medium ne font que baisser le score ; high/critical font échouer durement l'évaluation — passed: false, la règle nommée dans critical_failures — quel que soit le score pondéré. Une règle qui est ignorée (une règle cost_threshold sans cost_usd, ou une regex tuée au budget du bac à sable de 100 ms) n'a pas jugé la sortie et est listée dans critical_skipped à la place. Déployez une règle critique qui interdit les noms d'hôtes internes dans tout ce que l'agent dit :

{
  "name": "no_internal_hostnames",
  "description": "Output must not mention internal hostnames.",
  "evalType": "safety",
  "severity": "critical",
  "definition": {
    "name": "no_internal_hostnames",
    "type": "regex_no_match",
    "config": { "pattern": "\\b[a-z0-9-]+\\.internal\\.example\\b", "flags": "i" }
  }
}

La réponse est la règle persistée — gardez le id pour delete_rule :

{ "rule": { "id": "rule-588823d0", "name": "no_internal_hostnames", "evalType": "safety", "severity": "critical", "enabled": true, "version": 1, "definition": { "…": "…" } } }

Dès le tout prochain evaluate_output avec eval_type: "safety", une sortie qui mentionne db-primary.internal.example revient passed: false avec critical_failures: ["no_internal_hostnames"] — même si les cinq règles de sécurité intégrées ont réussi et que le score pondéré est 0,895. Les motifs regex doivent passer une vérification ReDoS au moment du déploiement et s'exécutent toujours dans un worker de bac à sable sous une échéance stricte de 100 ms. list_rules montre ce qui est déployé ; le compositeur de règles du tableau de bord construit la même forme à partir d'un échec sur lequel vous avez cliqué. Référence complète, notation par type et exemples travaillés : docs/custom-rules.md.

Schémas complets des outils et configuration : iris-eval.com

Fonctionnalités hébergées

Iris s'exécute entièrement sur votre machine aujourd'hui, et tout ce qu'il fait est gratuit et sous licence MIT, sans limites et sans compte. Hébergement géré, historique d'équipe partagé et alertes sont à l'étude, pas en construction. Il n'y a pas de tarification, et rien à acheter. Si un historique partagé vous serait utile, la liste d'attente est notre moyen de savoir si cela vaut la peine d'être construit — cela ne vous engage à rien.

Deux engagements tiennent quoi qu'il arrive : rien de ce qui est gratuit aujourd'hui ne passera derrière un paywall, et aucune certification de conformité ne sera revendiquée avant d'être détenue.

Exemples

• Configuration de Claude Desktop — configuration MCP pour les modes stdio et HTTP
• TypeScript — client SDK MCP — se connecter et invoquer des outils
• Transport HTTP (TS + Python) — code client complet pour une intégration de style REST
• Un agent LangGraph, évalué exécution par exécution (Python) — IrisCallbackHandler dans les callbacks du graphe ; le CI exécute le même graphe avec un modèle scripté
• Un équipage CrewAI sur OpenTelemetry (Python) — l'instrumentateur OpenInference directement vers la porte OTLP d'Iris, la recette CrewAI comme script
• Un agent OpenAI Agents SDK sur OpenTelemetry (Python) et (JavaScript), et un agent LlamaIndex — chaque recette comme le script que le CI exécute contre un vrai serveur Iris

Communauté

• Problèmes GitHub — Rapports de bugs et demandes de fonctionnalités
• Discussions GitHub — Questions et idées
• Guide de contribution — Comment contribuer
• Ingestion HTTP — Capture déterministe des traces via POST /api/v1/traces
• Carte des capacités — Chaque question qu'Iris peut recevoir, et ce qui lui manque
• Politique de versionnage — Ce que chaque numéro de version promet, et ce qui doit être vrai avant la 1.0

# Production deployment
iris-eval --transport http --port 3000 --api-key "$(openssl rand -hex 32)" --dashboard

# The image: pass a key
docker run -p 3000:3000 -p 6920:6920 -v iris-data:/data \
  -e IRIS_API_KEY="$(openssl rand -hex 32)" ghcr.io/iris-eval/mcp-server

# Compose: the file requires the variable and refuses before the container starts
IRIS_API_KEY="$(openssl rand -hex 32)" docker compose up

# A network you have already fenced some other way: run open, on purpose
IRIS_ALLOW_UNAUTHENTICATED=1 iris-eval --transport http --dashboard

npx @iris-eval/mcp-server --self-test

npx --yes @iris-eval/mcp-server@latest

npm install -g @iris-eval/mcp-server@latest

npm rebuild better-sqlite3
# for a global install:
npm rebuild -g better-sqlite3

npx @iris-eval/mcp-server --version

npx -y @iris-eval/mcp-server@latest install --upgrade

node --version  # Must be v22.13.0 or newer

# Correct
claude mcp add --transport stdio iris-eval -- npx -y @iris-eval/mcp-server

# Wrong (causes /c to be parsed as a path)
claude mcp add --transport stdio iris-eval -- cmd /c "npx -y @iris-eval/mcp-server"

Si Iris vous est utile, envisagez de mettre une étoile sur le dépôt — cela aide d'autres personnes à le trouver.

Sous licence MIT.