# ScopeRail integration checklist

Version 1.0 · Public working artifact

Use this checklist to frame one production workflow. It is not a security
certification, a deployment promise or a substitute for product-specific legal
and risk review.

## 1. Workflow

- [ ] Name one recurring point of friction.
- [ ] Name the person who encounters it.
- [ ] Name the decision or outcome that should improve.
- [ ] Describe the current path without assuming AI is the answer.
- [ ] Define what remains useful if no model is called.
- [ ] Assign one product owner and one technical owner.

## 2. Boundary

- [ ] Identify the host system that remains authoritative.
- [ ] Resolve identity on the server, not from a prompt or browser claim alone.
- [ ] List tenant, site, role and resource boundaries that apply.
- [ ] List operations that are always forbidden.
- [ ] List operations that require explicit human confirmation.
- [ ] Define the safe result when identity or scope cannot be resolved.

## 3. Knowledge and live state

- [ ] Inventory the source documents needed by this workflow.
- [ ] Name an owner for each authoritative source.
- [ ] Record version and freshness expectations.
- [ ] Separate stable knowledge from changing operational state.
- [ ] Apply access filters before restricted content enters model context.
- [ ] Define distinct behavior for missing, stale, unavailable and denied data.

## 4. Tools and actions

- [ ] Describe each tool with purpose, `use when` and `do not use when`.
- [ ] Give every tool typed input and normalized output schemas.
- [ ] Compute the eligible catalogue after host-side policy checks.
- [ ] Keep tool selection separate from tool eligibility.
- [ ] Validate arguments before execution.
- [ ] Recheck authorization immediately before a consequential write.
- [ ] Add idempotency, timeout, cancellation and partial-failure behavior.
- [ ] Keep proposed, confirmed, executing, completed and failed distinct.

## 5. Human path

- [ ] Show the evidence and expected outcome before confirmation.
- [ ] Let the person edit or cancel a proposal.
- [ ] Define who receives an escalation.
- [ ] Preserve the context needed for a useful handoff.
- [ ] Make recovery possible after a tool or provider failure.

## 6. Evaluation

- [ ] Collect representative questions from real work.
- [ ] Hold out questions that are not used during implementation.
- [ ] Add paraphrases and equivalent forms.
- [ ] Test cross-role and cross-scope access cases.
- [ ] Test empty, stale, malformed, denied and partial results.
- [ ] Test tool routing with eligible and ineligible tools.
- [ ] Execute tool-chain tests rather than checking text alone.
- [ ] Inject timeouts and tool errors.
- [ ] Compare a deterministic path, the smallest candidate model and larger
      candidates on the same cases.
- [ ] Record the release owner and explicit acceptance evidence.

## 7. Operation

- [ ] Log stage, policy outcome, tool identifier, result class and duration
      without logging secrets or unnecessary content.
- [ ] Define retention and access for operational traces.
- [ ] Review weak answers, denied actions, escalations and abandoned proposals.
- [ ] Feed documentation gaps back to the authoritative source.
- [ ] Re-run evaluations after source, tool, policy or model changes.
- [ ] Add another workflow only when the first has an owner and a feedback loop.

## 8. Launch gate

- [ ] The workflow is useful with JavaScript, providers or tools temporarily
      unavailable.
- [ ] No prompt grants access.
- [ ] No consequential action can skip host authorization.
- [ ] The person can tell whether an action was proposed or completed.
- [ ] Known limitations are visible.
- [ ] A human recovery route has been exercised.
- [ ] The selected model is the smallest option that passes the agreed matrix.

## References already used by the method

- [NIST AI Risk Management Framework](https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10)
- [Guidelines for Human-AI Interaction](https://www.microsoft.com/en-us/research/wp-content/uploads/2019/01/Guidelines-for-Human-AI-Interaction-camera-ready.pdf)
- [Model Context Protocol specification](https://modelcontextprotocol.io/specification/2025-11-25)
- [MCP Security Best Practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices)
- [τ-bench](https://openreview.net/forum?id=roNSXZpUDN)
- [AgentDojo](https://openreview.net/forum?id=m1YYAQjO3w)

---

# Checklist d’intégration ScopeRail

Version 1.0 · Artefact public de travail

Cette liste sert à cadrer un premier parcours en production. Elle ne constitue
ni une certification de sécurité, ni une promesse de déploiement, ni un
remplacement de la revue juridique et du modèle de risque propres au produit.

## 1. Parcours

- [ ] Nommer un point de friction récurrent.
- [ ] Identifier la personne qui le rencontre.
- [ ] Préciser la décision ou le résultat à améliorer.
- [ ] Décrire le chemin actuel sans partir du principe que l’IA est la réponse.
- [ ] Définir ce qui reste utile sans appeler de modèle.
- [ ] Désigner un responsable produit et un responsable technique.

## 2. Périmètre

- [ ] Identifier le système hôte qui reste l’autorité.
- [ ] Établir l’identité côté serveur, jamais depuis un prompt ou une simple
      affirmation du navigateur.
- [ ] Lister les limites de tenant, de site, de rôle et de ressource.
- [ ] Lister les opérations toujours interdites.
- [ ] Lister les opérations qui demandent une confirmation humaine explicite.
- [ ] Définir le résultat sûr lorsque l’identité ou le périmètre restent
      indéterminés.

## 3. Connaissances et état réel

- [ ] Inventorier les documents nécessaires au parcours.
- [ ] Donner un responsable à chaque source de référence.
- [ ] Noter les attentes de version et de fraîcheur.
- [ ] Séparer les connaissances stables de l’état opérationnel changeant.
- [ ] Appliquer les droits avant l’entrée d’un contenu restreint dans le contexte
      du modèle.
- [ ] Distinguer les données manquantes, anciennes, indisponibles et refusées.

## 4. Outils et actions

- [ ] Décrire chaque outil par son objectif, ses bons usages et ses contre-usages.
- [ ] Définir des schémas typés pour ses entrées et sa sortie normalisée.
- [ ] Construire le catalogue éligible après les contrôles du produit hôte.
- [ ] Séparer la sélection d’un outil de son éligibilité.
- [ ] Valider les arguments avant exécution.
- [ ] Refaire le contrôle des droits juste avant toute écriture importante.
- [ ] Prévoir idempotence, délai maximal, annulation et échec partiel.
- [ ] Distinguer proposé, confirmé, en cours, terminé et en échec.

## 5. Reprise humaine

- [ ] Montrer les preuves et le résultat attendu avant confirmation.
- [ ] Permettre la modification ou l’annulation d’une proposition.
- [ ] Définir la personne ou l’équipe qui reçoit l’escalade.
- [ ] Conserver le contexte nécessaire à une transmission utile.
- [ ] Prévoir une reprise après l’échec d’un outil ou d’un fournisseur.

## 6. Évaluation

- [ ] Réunir des questions représentatives du travail réel.
- [ ] Réserver des questions qui ne servent pas pendant l’implémentation.
- [ ] Ajouter des reformulations et des variantes équivalentes.
- [ ] Tester les changements de rôle et de périmètre.
- [ ] Tester les résultats vides, anciens, invalides, refusés et partiels.
- [ ] Tester le routage avec des outils éligibles et non éligibles.
- [ ] Exécuter les chaînes d’outils au lieu d’évaluer uniquement le texte.
- [ ] Injecter des délais dépassés et des erreurs d’outil.
- [ ] Comparer le chemin déterministe, le plus petit modèle candidat et les
      modèles plus larges sur les mêmes cas.
- [ ] Nommer le responsable de sortie et les preuves attendues.

## 7. Exploitation

- [ ] Journaliser l’étape, l’issue de la règle, l’identifiant d’outil, la classe
      de résultat et la durée sans conserver de secret ni de contenu inutile.
- [ ] Définir la durée de conservation et l’accès aux traces.
- [ ] Revoir les réponses faibles, les refus, les escalades et les propositions
      abandonnées.
- [ ] Reporter les lacunes documentaires dans les sources de référence.
- [ ] Relancer les évaluations après un changement de source, d’outil, de règle
      ou de modèle.
- [ ] N’ajouter un parcours que lorsque le précédent a un responsable et une
      boucle de retour.

## 8. Feu vert

- [ ] Le parcours reste compréhensible si JavaScript, un fournisseur ou un outil
      devient temporairement indisponible.
- [ ] Aucun prompt ne donne de droit.
- [ ] Aucune action importante ne contourne les autorisations du produit.
- [ ] La personne distingue une proposition d’une action terminée.
- [ ] Les limites connues sont visibles.
- [ ] Le chemin de reprise humaine a été exercé.
- [ ] Le modèle retenu est le plus petit qui réussit la matrice convenue.