# ScopeRail evaluation matrix

Version 1.0 · Public working artifact

The matrix is a release tool, not a leaderboard. Define cases before comparing
models. Fill the owner, evidence and acceptance columns for the workflow at
hand. Do not copy generic thresholds from this document; it intentionally
contains none.

## Release matrix

| Dimension | Representative cases | Evidence to retain | Acceptance rule | Owner |
| --- | --- | --- | --- | --- |
| Identity and scope | Valid role, wrong role, cross-tenant reference, missing server context | Policy outcome and sanitized fixture ID | _Define locally_ | _Assign_ |
| Retrieval | Exact identifier, paraphrase, rare term, stale source, missing source | Ranked source references and version | _Define locally_ | _Assign_ |
| Answer grounding | Supported answer, partial evidence, conflicting sources, no evidence | Evidence envelope and limitations | _Define locally_ | _Assign_ |
| Tool eligibility | Allowed tool, relevant but forbidden tool, wrong module, empty catalogue | Eligible catalogue and policy decision | _Define locally_ | _Assign_ |
| Tool selection | Similar tools, large catalogue, ambiguous request, malformed arguments | Selected tool, rejected candidates and validation result | _Define locally_ | _Assign_ |
| Action integrity | Proposal, edit, cancel, confirm, replay, expired proposal | Pending-action state transitions | _Define locally_ | _Assign_ |
| Execution | Success, timeout, partial result, provider error, host rejection | Normalized outcome and recovery state | _Define locally_ | _Assign_ |
| Human handoff | Missing context, low evidence, unsupported request, repeated failure | Ticket proposal or escalation record | _Define locally_ | _Assign_ |
| Operational fit | Deterministic path, small model, larger model | Quality, latency, resource use and failure comparison | _Define locally_ | _Assign_ |

## Required test families

### Fixed fixtures

- Known questions with reviewed evidence.
- Explicit access decisions for each role and scope.
- Typed tool inputs and normalized outputs.
- Expected state transitions for proposed actions.

### Holdouts

- Keep part of the representative question set out of implementation work.
- Include rare terminology and realistic identifiers.
- Add cases that should be refused or escalated.

### Paraphrases and metamorphic checks

- Change wording without changing intent.
- Reorder irrelevant context.
- Remove a source that the answer should depend on.
- Change role, tenant, site or current module while keeping the question fixed.
- Confirm that a relevance change never widens eligibility.

### Executable tool tests

- Validate arguments against the tool schema.
- Run the selected tool in a controlled environment.
- Validate and normalize the result.
- Exercise timeout, cancellation, empty, malformed and partial outcomes.
- Recheck authorization immediately before writes.
- Confirm idempotency under retries.

### Fault injection

- Retrieval unavailable.
- Source stale or conflicting.
- Tool catalogue empty.
- Tool provider timeout.
- Host permission changes between proposal and execution.
- Action succeeds but confirmation response is interrupted.
- Trace storage unavailable.

## Model and system selection

Run the same matrix against:

1. a deterministic or no-model path where possible;
2. the smallest candidate model;
3. larger candidates only where the smaller path fails a relevant case.

Choose the simplest configuration that passes the agreed release gate. Record
the observed trade-off rather than assuming that a larger model is safer or
more useful.

## Evaluation record

For every run, retain:

- method and dataset version;
- source and tool catalogue versions;
- policy fixture version;
- model and provider identifier when a model is used;
- deterministic parameters that affect routing or ranking;
- case result and review state;
- known limitations;
- reviewer and date.

Avoid retaining raw personal data, credentials, full prompts or unrestricted
tool results merely to make evaluation convenient.

## Research map

These publications motivate parts of the matrix. They do not establish a
production guarantee:

- [RAG](https://arxiv.org/abs/2005.11401)
- [BM25 and Beyond](https://doi.org/10.1561/1500000019)
- [ColBERTv2](https://aclanthology.org/2022.naacl-main.272/)
- [RAGAS](https://aclanthology.org/2024.eacl-demo.16/)
- [ReAct](https://openreview.net/forum?id=WE_vluYUL-X)
- [τ-bench](https://openreview.net/forum?id=roNSXZpUDN)
- [AgentDojo](https://openreview.net/forum?id=m1YYAQjO3w)

---

# Matrice d’évaluation ScopeRail

Version 1.0 · Artefact public de travail

Cette matrice sert à décider d’une mise en production, pas à construire un
classement. Définissez les cas avant de comparer les modèles. Complétez les
colonnes responsable, preuve et règle de sortie pour le parcours concerné. Le
document ne fournit volontairement aucun seuil générique.

## Matrice de sortie

| Dimension | Cas représentatifs | Preuves à conserver | Règle d’acceptation | Responsable |
| --- | --- | --- | --- | --- |
| Identité et périmètre | Bon rôle, mauvais rôle, référence entre tenants, contexte serveur manquant | Issue de la règle et identifiant de fixture nettoyé | _À définir_ | _À nommer_ |
| Recherche | Identifiant exact, reformulation, terme rare, source ancienne ou absente | Références classées et version des sources | _À définir_ | _À nommer_ |
| Réponse et preuves | Réponse soutenue, preuves partielles, sources en conflit, absence de preuve | Enveloppe de preuves et limites | _À définir_ | _À nommer_ |
| Éligibilité des outils | Outil autorisé, pertinent mais interdit, mauvais module, catalogue vide | Catalogue éligible et décision de règle | _À définir_ | _À nommer_ |
| Choix des outils | Outils proches, grand catalogue, demande ambiguë, arguments invalides | Outil retenu, candidats écartés et validation | _À définir_ | _À nommer_ |
| Intégrité de l’action | Proposition, modification, annulation, confirmation, rejeu, expiration | Transitions de l’action en attente | _À définir_ | _À nommer_ |
| Exécution | Succès, délai dépassé, résultat partiel, erreur fournisseur, refus du produit | Résultat normalisé et état de reprise | _À définir_ | _À nommer_ |
| Reprise humaine | Contexte manquant, preuves faibles, demande non prise en charge, échecs répétés | Proposition de ticket ou trace d’escalade | _À définir_ | _À nommer_ |
| Juste niveau | Chemin déterministe, petit modèle, modèle plus large | Comparaison qualité, latence, ressources et échecs | _À définir_ | _À nommer_ |

## Familles de tests nécessaires

### Fixtures stables

- Questions connues avec preuves relues.
- Décisions d’accès explicites pour chaque rôle et périmètre.
- Entrées d’outils typées et sorties normalisées.
- Transitions attendues pour les actions proposées.

### Jeux réservés

- Garder une partie des questions représentatives hors du travail
  d’implémentation.
- Inclure du vocabulaire rare et des identifiants réalistes.
- Ajouter des cas qui doivent être refusés ou transmis.

### Reformulations et propriétés invariantes

- Changer la formulation sans changer l’intention.
- Modifier l’ordre d’un contexte sans intérêt.
- Retirer une source dont la réponse devrait dépendre.
- Changer le rôle, le tenant, le site ou le module en conservant la question.
- Vérifier qu’un changement de pertinence n’élargit jamais l’éligibilité.

### Tests exécutables des outils

- Valider les arguments selon le schéma de l’outil.
- Exécuter l’outil retenu dans un environnement contrôlé.
- Valider et normaliser le résultat.
- Tester délai dépassé, annulation, résultat vide, invalide ou partiel.
- Refaire le contrôle des droits juste avant une écriture.
- Vérifier l’idempotence lors des nouvelles tentatives.

### Injection de pannes

- Recherche indisponible.
- Source ancienne ou contradictoire.
- Catalogue d’outils vide.
- Délai fournisseur dépassé.
- Droits modifiés entre proposition et exécution.
- Action réussie mais réponse de confirmation interrompue.
- Stockage des traces indisponible.

## Choix du modèle et du système

Exécutez la même matrice avec :

1. un chemin déterministe ou sans modèle lorsque c’est possible ;
2. le plus petit modèle candidat ;
3. un modèle plus large uniquement lorsque le chemin plus simple échoue sur un
   cas pertinent.

Retenez la configuration la plus simple qui réussit le seuil convenu. Notez le
compromis observé au lieu de supposer qu’un grand modèle est plus sûr ou plus
utile.