Feedback evaluation: offline fixture and validator ================================================ ENGLISH These are handwritten fictional examples for the three records in the feedback article. They are not responses captured from any model. Keep the expected answer key separate from model input. Nothing here sends network requests, uses a key, creates a provider job, or changes product priorities. Save these files together and use Node.js 22 or later: - feedback-expected.json: original input text, human category/review expectations, and deliberately curated supporting excerpts for each record. - feedback-output-valid.jsonl: three supported illustrative output rows. - feedback-output-missing-id.jsonl: feedback-1044 is missing. - feedback-output-duplicate-id.jsonl: feedback-1042 appears twice. - feedback-output-unsupported-quote.jsonl: a quote invents private-data exposure. - feedback-validate.mjs: dependency-free local validator. - feedback-validate.test.mjs: positive and negative regression tests. From that folder: node feedback-validate.mjs feedback-output-valid.jsonl node --test feedback-validate.test.mjs The first command should report PASS. The test suite should pass because it asserts that bad cases are rejected. Run an individual negative case with: node feedback-validate.mjs feedback-output-missing-id.jsonl node feedback-validate.mjs feedback-output-duplicate-id.jsonl node feedback-validate.mjs feedback-output-unsupported-quote.jsonl Each individual negative command must print FAIL and exit with code 1. Expected labels and review flags, joined by custom_id rather than line order: feedback-1042: defect, false feedback-1043: integration, true (SSO/security and a particular team) feedback-1044: usability, false The validator checks all expected IDs once, successful complete text responses, valid JSON with exactly six typed fields, fixture category/review flags and an exact source quote from a small human-approved list. A verbatim excerpt that omits the supporting words is also rejected. Provider errors, refusals and truncated outputs fail closed. It accepts response.choices or the response.body.choices wrapper and requires finish_reason to be stop. A pass is limited to these three fictional cases. The validator is not a general semantic judge. A different but reasonable quote outside the curated list needs human review, not automatic acceptance. The meaning of requested_outcome and affected_workflow still needs human review. No model accuracy or production release claim follows from these tests. Adapt the answer key and obtain human labels for a larger representative sample; do not weaken the review gate to make a model output pass. FRANÇAIS Ces exemples fictifs sont rédigés pour les trois retours de l’article. Ils ne proviennent d’aucune exécution de modèle. Gardez le corrigé hors de l’entrée du modèle. Le validateur lit seulement des fichiers locaux : aucun appel réseau, identifiant, envoi de fichier, lot fournisseur ou changement de priorité. Enregistrez les sept fichiers énumérés ci-dessus dans le même dossier et utilisez Node.js 22 ou ultérieur. Les deux premières commandes doivent réussir. La suite réussit précisément parce qu’elle vérifie le rejet des cas négatifs. Chacune des trois commandes négatives doit afficher FAIL et se terminer avec le code 1. Attentes par custom_id, quel que soit l’ordre des lignes : feedback-1042 : defect, false feedback-1043 : integration, true (SSO, sécurité et équipe précise) feedback-1044 : usability, false Le validateur exige chaque identifiant une seule fois, une réponse textuelle complète sans erreur, un JSON de six champs typés, la bonne catégorie, le bon indicateur de revue et une citation exacte parmi les extraits approuvés pour cet exercice. Il rejette aussi un extrait littéral qui ne contient pas les mots justifiant la catégorie, les refus et les sorties tronquées. La réussite concerne uniquement ces trois cas. Ce n’est pas un arbitre général du sens. Une autre citation pertinente mais absente de la liste exige une revue humaine. Le sens de requested_outcome et affected_workflow reste à relire par une personne. Aucun résultat ne prouve la qualité d’un modèle ou l’aptitude à la mise en production. Étiquetez un échantillon plus large et représentatif avant tout élargissement ; n’affaiblissez pas la condition de passage pour faire réussir une sortie de modèle.