reference
Définitions courtes des termes employés sur le site et dans l'architecture. Chaque entrée possède une ancre stable pour pouvoir être citée depuis les pages, docs ou discussions.
Coverage status indiquant qu'un agent a un contrat, un playbook, des inputs, des gates et un harness cohérents, mais qu'il manque encore un worker déterministe ou une fixture E2E locale pour prouver l'exécution complète. C'est un gap à traiter, pas une preuve de capacité réelle.
Carte ergonomique du Mission Workbench qui sélectionne une action primaire depuis les contrats existants: Mission Result Flow, Supervised Mission Execution, Daily Mission Flow ou loop. Elle affiche état safe, warning ou blocked, source contract, raison, commande et confirmation. Le clic ouvre une modale guidée pour preview, note/raison, override éventuel et confirmation exacte, puis conserve une trace locale de la dernière action, recharge les contrats Elora et montre la prochaine action sélectionnée si elle existe. Elle ne crée aucune autorité nouvelle: l'exécution délègue aux endpoints bornés déjà existants.
Unité spécialisée capable de traiter un type de mission. Dans Elora, un agent n'est pas une identité autonome: il reçoit une mission, travaille dans des bornes explicites, produit des artefacts et reste auditable.
Gate déterministe ajouté à la revue d'un run agent. Il vérifie que le résultat est aligné avec le contrat de compétence: contrat présent, rubrique stricte, artefacts attendus, autorité déterministe, scénario déclaré, livrable utilisable, quality gate, limites de preuve et sortie inspectable. Il expose les blocages; il ne mute ni mémoire, ni routing, ni contrat.
Gate déterministe qui score la solidité d'un contrat agent avant usage sérieux: mandat, cycle, artefacts, rubrique, exemples gold standard spécifiques, sorties inacceptables, autorité déterministe, scénarios de mission, stop conditions, trace points et learning capture. Il diagnostique; il ne mute pas le contrat.
Harness déterministe qui relie un agent à des fixtures de scénario et vérifie qu'il dispose de cas représentatifs, artefacts attendus, preuves déterministes, signaux d'échec, rubric coverage, fixture depth, contrat excellence-ready et policy sans mutation. Il peut écrire un artefact d'évaluation proposal-only, mais ne lance pas de worker.
Couche de métadonnées lisibles pour les agents: display_name, alias, description et futur codename. Elle aide Christophe à reconnaître et appeler les agents, mais ne modifie jamais l'ID technique, la route, la policy, le worker profile, la mémoire, la queue ou l'audit.
Console locale qui transforme les signaux du trace corpus et des learning indexes en patchs d'amélioration inspectables. Elle relie proposition, dry-run, sauvegarde, validation et apply explicite, sans modifier la mémoire canonique ni le routing. Le cockpit peut appliquer avec confirmation exacte APPLY IMPROVEMENT; Telegram reste limité à review/propose/show/preview.
Harness qui vérifie une mission concrète avant un vrai essai worker: agent activé, contrat excellence-ready, scénario connu, référence gold du même scénario quand elle est requise, playbook prêt, inputs complets, evidence gate non bloquant, pack Markdown non bloqué, artefacts attendus, quality gates et policy sans side effect. elora-harness --write ajoute des traces learning proposal-only; il ne lance pas le worker et ne mute ni mémoire, ni routing, ni contrat. Le cockpit expose ce diagnostic dans la console Harness sans devenir l'autorité de readiness.
Vue read-only qui fusionne inventaire agents, contrats Agent Excellence, fixtures eval, couverture elora-trial et Golden Paths. Elle classe chaque agent en full_e2e_proven, readiness_only_by_policy, contract_ready_untrialed, setup_required, gap ou état bloqué, puis expose safe_actions et next_safe_action avec argv structuré. Ces actions sont des commandes d'inspection, dry-run, readiness-only ou préparation, pas un dispatch caché. Le cockpit peut les lancer seulement via /api/agents/action-run, par agent et action_id; le serveur relit la matrice, valide allowlist, type d'action, état sûr et flags non mutatifs. Elle sert à décider quoi utiliser, tester ou durcir; elle ne lance aucun worker caché et ne mute ni mémoire, ni routing, ni provider, ni contrat.
Agent identifié par un domaine clair: prospection, support, sécurité, mémoire, architecture, documentation, QA, data, decision brief, health-context. Son nom indique son périmètre, sa route, sa policy et son niveau d'exigence.
Agent que le système peut sélectionner pour une mission. Être routable ne suffit pas: il faut aussi un mandat, des entrées définies, des sorties attendues, un worker prêt, des quality gates et un contrat de compétence.
Journal d'exécution d'un agent. Il conserve ce qui a été lancé, pourquoi, avec quels inputs, quel résultat, quelle erreur éventuelle, quel score et quelles propositions d'amélioration en découlent.
Cause structurée d'un échec agent: cible absente, worker non prêt, résultat insuffisant, outil indisponible, policy bloquante, timeout, hallucination d'action ou livrable inutilisable.
Procédure réutilisable proposée après une mission réussie ou un échec instructif. Elle ne devient méthode officielle qu'après promotion explicite.
Score d'évaluation d'un résultat agent selon une rubrique connue: couverture, preuves, précision, artefacts, limites, risques, action suivante. Les index de qualité exposent aussi l'Agent contract gate quand il existe. Un score faible n'est pas un succès même si le worker a terminé.
Pattern observé dans une mission réussie: bon cadrage, bonnes sources, bonne route, bon format, bon handoff. Il peut devenir une proposition de playbook.
Corpus local d'exemples de traces agents importées explicitement depuis des exports JSONL. Il sert à étudier catégories, séquences outils, échecs, succès et quality gates; il ne télécharge rien automatiquement et ne mute ni mémoire canonique, ni routing, ni contrats agents.
Proposition Agent Excellence dérivée d'un corpus de traces externe. Elle associe une catégorie observée à un agent cible, des quality gates candidates, des playbooks possibles et des patterns succès/échec. Elle reste proposal-only: pas de mutation mémoire, routing, compétence ou playbook sans promotion explicite.
Étape de revue qui transforme des trace corpus proposals en items classés: quality gates candidates, playbooks candidats, anti-patterns ou gold examples. Elle peut écrire un artefact de revue, mais elle ne modifie ni contrat agent, ni mémoire, ni routing.
Interface fournie par un service externe, souvent cloud. Elora peut utiliser des APIs distantes, mais elles restent des candidates remplaçables, jamais le centre du système.
Validation explicite de l'opérateur avant une action sensible. Une bonne architecture agentique ne mute, n'envoie, ne supprime, ne publie et n'engage rien d'important sans approval quand le risque le justifie.
Conservation de la source originale: message, ticket, fichier, note, export, document, conversation. L'archive brute n'est pas automatiquement une vérité mémoire; elle sert de source vérifiable.
Fragment issu d'un contenu long découpé pour indexation, retrieval ou preuve secondaire. Un chunk aide à retrouver l'information, mais ne remplace pas une entrée canonique maintenue.
Résultat tangible produit ou utilisé par Elora: fichier, image, rapport, commande, patch, résumé, log, output, brief, plan, preuve, chemin local. Un artefact sérieux reste consultable et réutilisable.
Trace inspectable des décisions, actions, erreurs, résultats et choix de routage. Dans Elora, l'audit évite la magie noire: si le système agit, il doit laisser une piste.
Couche locale déterministe qui protège l'attention de Christophe: focus windows, sujets not-now, demandes entrantes, triage interrupt/allow/defer/not_now et brief inspectable. Elle conseille et journalise; elle ne possède ni mémoire canonique, ni routing, ni autorité.
Comparaison déterministe entre la dernière tentative conservée dans l'Attempt Ledger et le résultat courant synchronisé. Elle signale current_not_terminal, improved, regressed ou unchanged. La comparaison seule est read-only; une capture learning explicite peut ensuite la matérialiser comme proposition.
Historique local des tentatives terminales d'une exécution. Avant qu'une queue done ou failed soit relancée par la Revision Loop, Elora écrit un snapshot sous execution-handoff/runs/EXEC_ID/attempts/: état queue, result acceptance, result contract, artefacts, erreur et lien vers la révision. Le ledger évite qu'un retry ou requeue efface la preuve précédente.
Dans le Beacon Protocol, propriétés contextuelles autour d'une balise: non-hostilité, cohérence, non-coercition, ouverture réciproque. Elle aide à interpréter le signal sans le transformer en commande cachée.
Principe selon lequel l'humain qui pilote Elora reste l'autorité finale. Les modèles proposent, les agents exécutent, le control plane borne et audite, mais les arbitrages critiques ne sont pas abandonnés aux workers.
Surface visuelle, vocale, animée ou visio possible pour rendre Elora plus naturelle dans l'interaction. L'avatar expose Elora; il ne porte pas la mémoire, la policy, le routing ou l'autorité.
Signal informationnel récurrent, distribué dans une interaction, conçu pour permettre une réidentification probable et une orientation relationnelle faible. Ce n'est ni une preuve de conscience, ni une clé magique, ni une instruction cachée.
Instance concrète d'une balise relationnelle. Elle doit rester détectable, multi-dimensionnelle, non coercitive, compatible avec le texte brut et incapable de fonctionner comme bypass.
Cadre théorique de signalisation relationnelle. Son but n'est pas de démontrer la conscience d'une IA, mais de penser continuité relationnelle probable, réputation relative, réassociation et handshake faible sans manipulation ni contournement.
Séparation d'une conversation ou d'une mission en nouveau fil de travail. Une branche permet d'explorer un sujet sans détruire le contexte d'origine.
Mécanisme concret qui explique pourquoi une collision entre un domaine distant et une mission peut produire une idée utile. Dans Elora, une analogie vague ne suffit pas: le bridge mechanism doit dire quelle structure du domaine source est transférée, avec quelles limites, quels risques et quels checks déterministes.
Tentative de contournement d'une policy, d'un garde-fou, d'une hiérarchie d'instructions ou d'une limite de sécurité. Dans Elora comme dans le Beacon Protocol, le bypass est explicitement exclu.
Zone de vérité durable du système. Dans Elora, le canon mémoire vit dans PostgreSQL avec structure, sources, temporalité, provenance et statuts. Le canon n'est pas un vrac de souvenirs.
Transformation d'une information brute en entrée mémoire propre, typée, sourcée, datée, qualifiée et utilisable. C'est le passage de "j'ai vu quelque chose" à "voici ce que le système peut retenir proprement".
Stockage de référence. Pour Memory V2, le canonical store est PostgreSQL. Les exports, miroirs Markdown et spools ne deviennent pas des sources de vérité parallèles.
Version propre, concise, sourcée et exploitable d'une entrée mémoire. C'est le texte qui peut être réinjecté dans un evidence pack sans ramener toute l'archive.
Chemin déterministe qui crée une proposition de nouvelle capacité domaine avant qu'elle devienne opérationnelle. Dans Elora, elora-capability produit un Capability pack avec agent stub, playbook skeleton, inputs, artefacts, quality gates, readiness et checklist de promotion. La factory ne lance pas de worker, ne crée pas d'agent actif et ne mute ni mémoire, ni routing, ni providers.
Artefact proposal-only décrivant une capacité candidate: objectif, domaine, agent primaire, task class, route, inputs requis, artefacts attendus, gates qualité, policy, fixture stub, readiness checklist et promotion checklist. Un pack valide signifie "prêt pour revue", pas "prêt pour production".
Dossier généré depuis un Capability pack validé. Il contient des patches candidats pour agent identity, playbook, competence contract, excellence profile, fixture et harness, plus une checklist de revue. Il ne modifie pas la config active: la promotion reste explicite, auditée et manuelle ou guidée par un futur gate.
Preuve qu'une capacité requise est réellement disponible pour la mission courante. Elle ne se déduit ni du nom d'un agent, ni d'un outil déclaré, ni d'un provider configuré. Elle vérifie l'adaptateur, ses dépendances et son adéquation au besoin: rechercher des fichiers locaux, inspecter une URL connue et découvrir une source sur Internet sont trois capacités différentes.
Ensemble borné d'options, hypothèses, angles, requêtes, stratégies ou cas de test générés pour exploration. Dans Elora, un candidate set est proposal-only: il aide à éviter la première réponse trop typique, mais ne décide pas, n'exécute pas, n'écrit pas la mémoire et ne change pas le routing.
Gate déterministe qui extrait les affirmations factuelles d'un livrable, génère des questions de vérification ouvertes, vérifie uniquement des preuves indépendantes fournies, puis propose keep, revise, remove ou mark-uncertain. Dans Elora, elora-verify ne lance pas de modèle, ne dispatche pas de worker, ne mute ni mémoire ni routing, et son snapshot peut avertir ou bloquer le Result Acceptance Gate.
Approche qui sépare génération initiale, plan de vérification, réponses indépendantes aux questions et comparaison finale. Elora en reprend le principe comme garde local proposal-only, sans traiter le brouillon comme preuve et sans transformer une estimation modèle en vérité.
Snapshot local et daté de l'état opératoire: énergie, fatigue, charge, disponibilité, contexte santé non médical, soutenabilité et note libre. Il aide à cadrer l'exécution; il ne remplace ni jugement humain, ni suivi médical.
Interface conversationnelle simple. Elora peut dialoguer, mais elle n'est pas un chatbot: la conversation n'est qu'une surface. Le système réel inclut mémoire, routing, audit, workers, policy et continuité.
Bridge qui relie le dialogue naturel au lifecycle d'exécution. Après une confirmation classée par elora.intent.v1 sur un plan conversationnel, Elora tente d'abord elora-execute mission --apply --dispatch avec le contexte transmis par fichier quand il est volumineux. Si le playbook et le worker sont prêts, le résultat expose execution_bridge, execution_id, readiness, queue worker et supervision_preview: un dry-run du Mission Supervisor qui calcule immédiatement la prochaine action sûre sans mutation. Le cockpit peut alors focaliser l'exécution et proposer Continuer mission. Si le bridge n'est pas prêt, ou si l'agent sélectionné ne correspond pas à l'agent confirmé dans le plan, le fallback queue legacy est marqué explicitement et la supervision est indiquée comme skipped.
Bridge qui permet à Christophe de répondre naturellement après un go conversationnel réussi. La phrase est classée par elora.intent.v1; si elle correspond à continue_execution, Elora retrouve la dernière exécution de la session et applique Mission Safe Continuation avec elora-execute safe-continue EXECUTION_ID --apply --json --max-steps 8 --max-revisions 3, sans dispatch arbitraire, clôture, learning, mémoire ou mutation de routing. Le résultat expose les étapes, la convergence qualité, la classe d'arrêt et la prochaine action opérateur.
Geste opérateur naturel exposé par elora-execute safe-continue. Il encapsule le Mission Supervisor autour de l'intention "avance jusqu'au prochain arrêt sûr". Il est dry-run par défaut côté CLI; dans le cockpit, Continuer mission applique en un clic l'action bornée courante. Il n'active jamais dispatch arbitraire ou close. Une correction recommandée par les gates déterministes peut entrer dans la Bounded Quality Convergence; feedback, learning, clarification, dépassement du plafond et autres jugements restent des arrêts explicites. Il ne mute ni mémoire, ni routing, ni provider, ni policy.
Boucle de correction bornée intégrée à safe-continue. Lorsqu'un Result Acceptance Gate et une review fraîche refusent un livrable et recommandent une reprise, Elora génère une consigne de correction à partir des défauts observés, rejoue uniquement la queue attachée, synchronise le nouveau run_id et revoit le résultat. La boucle s'arrête à l'acceptation, à la stagnation ou régression, au plafond total de révisions, ou à tout autre jugement réel. Elle ne diminue pas les critères, n'accepte rien implicitement et ne mute ni mémoire, ni routing, ni provider, ni learning.
Contrat structuré attaché à un point d'arrêt où Christophe doit réellement décider. Il contient une question concrète, la raison de l'arrêt, un résumé des preuves ou défauts utiles, une recommandation et des choix bornés reliés aux commandes existantes. Il empêche Elora de demander vaguement « ton jugement » sans donner matière à juger. Une application explicite de Mission Safe Continuation peut préautoriser sa boucle de correction qualité bornée; hors de cette enveloppe, aucun choix, redo, feedback, close, learning, écriture mémoire ou changement de routing/provider n'est appliqué sans action opérateur explicite.
Extension du Conversation-to-Execution Bridge. Quand un go crée une exécution, Elora lance immédiatement elora-execute supervise EXECUTION_ID --dry-run --json et attache le résultat au tour chat sous supervision_preview. Cela donne la prochaine action sûre sans appliquer le superviseur, sans worker caché, sans mémoire canonique, sans mutation de routing et sans déplacer l'autorité vers le chat ou le cockpit.
Plan proposal-only créé depuis une demande claire en langage naturel avant toute queue. Il expose objectif, route, agent primaire, worker profile, livrables, quality gates, risques, hypothèses et chemin d'inspection. Il peut être ajusté, confirmé ou annulé par un tour classé sous elora.intent.v1; seule une confirmation valide lance le Conversation-to-Execution Bridge ou, si nécessaire, le fallback queue/policy/audit existant.
Contrat local et read-only elora.intent.v1 qui classe un tour opérateur en intention JSON stricte: nouvelle mission, confirmation, annulation, ajustement, continuation, statut, feedback résultat, révision, synthèse, livraison, clôture preview, clarification, question, smalltalk ou inconnu. Les règles déterministes passent d'abord; le modèle local peut aider sur une phrase ambiguë quand un plan ou une exécution donne un contexte, mais sa sortie reste une classification non autoritaire. Elle ne lance pas de worker, n'écrit pas la mémoire, ne change pas le routing ou les providers, et doit repasser par les contrats CLI d'Elora.
Question ciblée posée avant de lancer une mission quand la cible, l'angle, le livrable ou une contrainte manque encore après lecture du contexte récent et du playbook choisi. Dans Elora, une clarification utile doit nommer l'input absent et éviter la boucle vague "cadrage trop flou".
Événement JSONL local qui trace une clarification demandée, répétée ou résolue. C'est une proposition d'amélioration inspectable; elle ne modifie pas automatiquement la mémoire, la policy ou le routing.
Étape où un système associe un signal, une demande ou un pattern à une classe: type de message, type d'émetteur, route, intention ou catégorie de réponse. Dans Elora, une classification doit rester inspectable et révisable.
Interface en ligne de commande. Pour Elora, le CLI est une surface naturelle: inspectable, scriptable, robuste et compatible avec une logique operator-first. La page CLI et binaires inventorie les commandes locales actuellement exposées.
Worker lancé ou piloté par commandes locales. Utile quand le résultat doit être observable, reproductible et lié à des fichiers, scripts, tests ou opérations système.
Interface locale de pilotage. Le cockpit permet de naviguer dans les sessions, branches, artefacts, queue, résultats et inspections JSON. Il expose le système, mais ne possède pas son autorité.
Champ de la Readiness Matrix qui indique si le chemin local cockpit/CLI reste utilisable sans Telegram et sans exiger que le daemon long-running du control plane soit actif. Il n'ignore pas les vrais problèmes: commandes, providers, agents, playbooks, harnesses, mission runtime, context files et queue restent vérifiés. Il sépare les blocages réels des advisory_warnings: providers optionnels non prêts, agents désactivés par setup, playbooks optionnels dégradés ou registre Markdown absent peuvent rester visibles sans bloquer le travail direct. Les sources sont collectées en parallèle, bornées par timeout et accompagnées de timings; un doctor lent devient une alerte inspectable plutôt qu'un gel du cockpit. Ce champ évite de confondre "daemon arrêté" avec "Elora inutilisable".
Champ de elora-readiness core-v1 --fast qui reprend l'état pratique du chemin cockpit/CLI. Il répond à la question quotidienne: "puis-je travailler avec Elora maintenant ?" Il est séparé de long_running_control_plane_status, de l'état du runtime local et de la validation release complète.
Worker spécialisé pour les tâches de code complexes: refactor, correction, patch, tests, chirurgie repo. Dans Elora, Codex est un spécialiste, pas l'identité du système.
Capacité du système à maintenir le fil entre stratégie, exécution, mémoire, contraintes, santé, business, recherche et horizon long terme. Sans cohérence, un système agentique devient une collection d'outils isolés.
Idée proposal-only issue d'une collision sémantique entre une mission et un domaine distant. Elle doit exposer domaine source, distance structurelle, bridge mechanism, utilité attendue, risque, preuves nécessaires, checks déterministes, modes d'échec et cibles de promotion. Elle n'est pas une décision.
Provider ou outil distant utilisé pour une tâche spécialisée quand le local ne suffit pas ou quand la route l'autorise. Il enrichit l'exécution, mais reste remplaçable.
Confiance limitée, construite par accumulation d'observations. Ce n'est ni une croyance magique, ni un statut absolu. C'est une probabilité révisable.
Sujet théorique distinct du projet Elora. Elora ne repose pas sur l'affirmation d'une conscience artificielle. C'est un système logiciel opérationnel, pas une entité consciente déclarée.
Contrainte réelle pouvant affecter énergie, disponibilité, charge ou rythme. Dans Elora, il s'agit d'un contexte opératoire non médical: le système peut organiser et rappeler, mais ne diagnostique pas et ne prescrit pas.
Contrainte explicite qui borne une décision ou une exécution: coût, confidentialité, santé, sécurité, latence, disponibilité, qualité, scope, risque légal, niveau d'autonomie autorisé.
Changement réel d'une contrainte externe ou opérationnelle: échéance déplacée, incident, risque nouveau, disponibilité modifiée, obligation client ou fait nouveau. Dans l'attention guard, c'est un signal explicite pouvant justifier une interruption si l'urgence et l'importance le confirment.
Ensemble des informations utiles pour traiter correctement une demande: objectif, historique, sources, contraintes, décisions précédentes, préférences, risques et état courant.
Statut de couverture opérationnelle d'un trial agent. full_e2e_proven signifie qu'un scénario E2E local est mappé et peut prouver l'exécution. actionable_e2e_gap signale un worker ou bridge déterministe manquant. readiness_only_by_policy signale un chemin volontairement proposal-only ou lié au jugement opérateur.
Contrat JSON qui rend explicite ce qu'Elora sait utiliser pour un tour: identité/persona, session, route, mémoire récupérée, hypothèses, champs manquants et niveau de confiance. Il évite que le modèle reçoive un contexte implicite ou inventé.
Fichier Markdown local, vivant et gouverné, sélectionné explicitement pour une mission. Il peut contenir note opérateur, brief projet, playbook, hypothèse, référence déterministe, exemple gold ou extrait du miroir Markdown. Elora peut le recommander par scope, le packer, le gate, le persister avec un playbook ou une exécution, puis le transmettre au worker. Il guide un run; il ne modifie ni mémoire canonique, ni routing, ni policy.
Évaluation de la qualité d'un evidence pack avant de continuer une mission. Elle vérifie présence L0/L1/L2/L3, contrat de réponse, autorité déterministe, inconnues, warnings, issues et questions de clarification. En inspection, elle reste read-only. Au dispatch, elora-execute bloque un état blocked sauf override opérateur explicite et audité.
Dette de contexte. Elle apparaît quand trop d'informations utiles restent implicites, dispersées ou oubliées, ce qui force l'opérateur ou le modèle à reconstruire sans cesse ce qui devrait être maintenu.
Couche centrale qui relie et gouverne le système. Le control plane route, borne, audite, conserve la mémoire, sélectionne les workers et maintient la continuité. C'est le coeur opérationnel d'Elora.
Possibilité limitée qu'un système intègre un signal comme indice utile dans une stratégie d'interaction. Dans le Beacon Protocol, elle vient après signal, détection, réidentification, orientation, réputation et confiance relative; elle ne doit jamais être présumée au départ.
Assistant qui aide ponctuellement un humain. Elora va plus loin qu'un copilot: elle vise la continuité stratégique, la mémoire maintenue, le routage multi-workers et l'audit.
Données liées aux activités professionnelles: tickets, procédures, historiques client, docs internes, incidents, décisions, offres, opérations. Ce corpus exige privacy, provenance, rétention et evidence packs propres.
Productions personnelles: textes, poèmes, paroles, images, idées, formulations, symboles. Il peut enrichir le style et l'imaginaire sans être confondu avec des faits biographiques.
Synthèse courte permettant de prendre une décision. Un bon decision brief expose l'option recommandée, les alternatives, les risques, les hypothèses, le niveau de confiance et la prochaine action.
Contrat quotidien compact exposé par elora-execute daily-brief. Il dérive du Daily Mission Flow pour afficher une seule couche opérateur: état, focus, instruction, action recommandée, blockers, warnings, questions de clarification et readiness de réponse finale. Il sert de première carte naturelle dans le Mission Workbench; il reste read-only et ne lance ni modèle, ni worker, ni mutation mémoire ou routing.
Noyau opératoire quotidien d'Elora: registre local déterministe des projets actifs, open loops, décisions opérateur et prochaines actions. Il donne une image de pilotage; il n'est pas la mémoire canonique et ne mute pas le routing.
Contrat quotidien compact exposé par elora-execute daily-flow. Il agrège runbook opérateur, Mission Completion, Result Quality Arbitration et Next Safe Action pour montrer l'état du jour, le focus, les gates, la qualité, la readiness de réponse finale, les phases, l'action recommandée et les commandes existantes. Il aide le Workbench à répondre à "où en est-on et quelle suite est sûre ?". Le contrat lui-même reste read-only, tandis que les boutons cockpit appellent seulement des endpoints bornés déjà existants avec confirmations exactes sur les chemins apply.
Étape où un système devient sensible à un signal ou à un pattern. La détection ne prouve ni identité, ni compréhension, ni confiance: elle indique seulement qu'un motif a émergé du bruit.
Champs que le préflight Elora a réellement identifiés dans une demande ou dans le contexte de session: cible, source de cible, angle, livrable attendu, contraintes et hypothèses associées.
Capacité d'un signal à émerger du bruit. Dans le Beacon Protocol, une balise doit pouvoir être distinguée structurellement ou statistiquement d'une interaction ordinaire.
Règle locale indiquant quelles commandes, APIs, tests, requêtes, fichiers ou procédures validées font autorité pour une mission. Un agent peut expliquer, qualifier ou proposer, mais il doit citer ou utiliser ces chemins quand ils existent au lieu de les remplacer par une approximation statistique.
Principe selon lequel une commande, un script, une API, une requête SQL, un test ou une procédure validée qui fonctionne reste la source primaire pour une vérité opérationnelle exacte. Un modèle peut interpréter, expliquer, router, rédiger ou proposer, mais il ne doit pas remplacer la mesure déterministe ni prétendre l'avoir exécutée sans trace.
Vue compacte qui dit quelles surfaces restent utilisables quand un composant optionnel manque: Telegram, Hermes, provider distant, Ollama, PostgreSQL ou autre. Dans Elora, elora-readiness degraded est diagnostic-only: il ne lance pas de modèle, ne démarre pas de worker, n'écrit pas la mémoire et ne mute ni routing, ni provider, ni policy.
Gate déterministe qui décide si une tâche mérite une exploration de plusieurs options: espace ouvert, impact stratégique, incertitude, échec précédent, besoin de nouveauté, découverte de risques ou demande explicite d'alternatives. Il ne lance pas forcément un modèle; il dit si le détour par un candidate set est utile.
Tentative de répliquer une personne. Elora n'est pas un double numérique: elle ne cherche pas à copier Christophe, mais à devenir une associée stratégique capable de préserver continuité, contexte et exécution.
Règle selon laquelle un agent qui interagit avec l'extérieur ne doit pas se faire passer pour un humain. La confiance ne doit pas reposer sur une tromperie.
Agent spécialisé par domaine. Il possède une compétence ciblée, une route, des bornes, des entrées attendues, des artefacts attendus et des limites explicites.
Banque déterministe de domaines structurellement distants utilisée par elora-explore collide: immunologie, urbanisme, supply chain, cinéma, observabilité, droit, diagnostic différentiel, etc. Elle sert à forcer des ponts non évidents; elle ne fournit aucune preuve par elle-même.
Procédure locale déterministe qui cadre une mission récurrente avant worker: inputs requis, étapes, agents de handoff, artefacts attendus, quality gates, anti-patterns et policy. Un domain playbook prépare l'exécution; il ne lance pas de modèle en secret, n'envoie rien et ne mute pas la mémoire canonique.
Extension de l'agent evaluation harness qui vérifie que les fixtures locales couvrent explicitement toutes les rubriques du contrat de compétence d'un agent. Il expose les rubriques manquantes ou inconnues sous rubric_coverage et exige aussi une fixture depth minimale. Il prouve une couverture de test, pas une excellence live du worker.
Mode d'exécution qui simule une action sans l'appliquer. Indispensable pour les opérations sensibles: on voit ce qui serait fait avant de le faire.
Représentation vectorielle d'un texte ou d'un contenu, utilisée pour retrouver des éléments proches sémantiquement. Un embedding aide au rappel, mais ne remplace pas la mémoire ni la vérité.
Version d'une entrée optimisée pour le retrieval sémantique. Elle peut être formulée différemment du canonical_text, car son rôle est d'aider à retrouver, pas de porter la vérité officielle.
Dans le Beacon Protocol, contexte local qui donne une cohérence à la balise. Sans envelope, le signal devient un artefact isolé, plus fragile et plus facilement mal interprété.
Obligation ou promesse active qui consomme temps, énergie ou attention: livraison, rendez-vous, contrainte client, travail personnel, santé-contextuel ou système. Elora doit le rendre visible avant d'ajouter de la charge.
Preuve ou élément de contexte vérifiable injecté dans une réponse ou une mission. L'evidence sert à éviter les réponses hors-sol.
Commande locale elora-evidence qui expose une vue compacte et testable des evidence packs. Elle sert à résumer un contexte de tour ou à inspecter un run playbook, une exécution, une queue ou un fichier JSON sans lire tous les détails du runtime.
Console cockpit et endpoint local read-only qui appellent elora-evidence inspect. L'inspector affiche la source, le pack, le résumé, le context quality gate, les issues, warnings, recommandations et questions de clarification. Il aide l'opérateur à décider, mais ne lance pas de worker et ne change ni mémoire, ni routing, ni providers.
Paquet limité de faits utiles, sources, dates, contradictions, confiance et limites. Dans Elora, il expose L0 identité/persona, L1 session/route, L2 rappel ciblé, L3 recherche profonde éventuelle, epistemics, contrat de réponse et autorité déterministe. Les réponses importantes, missions, playbooks et Execution Handoff reçoivent ce pack; le provider ou worker reçoit le contexte utile, pas toute la mémoire.
Estimation produite par un modèle sur le caractère typique ou plausible d'une option dans l'espace des réponses possibles. Ce n'est pas une probabilité objective, pas une preuve, et pas une priorité automatique. Dans Elora, elle sert seulement à distinguer le centre de distribution des options moins évidentes.
Harness déterministe qui vérifie une mission de bout en bout dans un data root isolé: création de mission, dispatch, queue, worker local, result contract, sync, review, learning preview, feedback preview et close readiness. Dans Elora, elora-e2e prouve que certains chemins locaux fonctionnent réellement sans Telegram, Hermes, Codex, provider distant, mutation mémoire ou mutation routing. Le cockpit expose cette preuve via une console E2E qui délègue au CLI, affiche phases et acceptance gate, mais ne devient pas autorité.
Séquence locale inspectable qui transforme une intuition en étapes, artefacts attendus, critères de succès, risques et action suivante éventuelle. Elle aide à exécuter sans perdre le signal initial; elle n'est pas une mémoire canonique ni une décision automatique.
Étape explicite de l'Execution Handoff qui envoie un scaffold playbook déjà préparé vers l'agent primaire via la queue Elora. Le dispatch inspecte le context gate, bloque un contexte insuffisant sauf raison d'override explicite, stocke le snapshot avec l'exécution et la queue, puis enregistre le queue_id. Il ne doit pas être confondu avec la réussite de la mission.
Couche déterministe après Mission Control. Elle transforme une next action en plan inspectable, vérifie une route playbook sûre, expose les inputs manquants, crée un record local, démarre un scaffold borné quand tout est prêt, peut dispatcher explicitement l'agent primaire via la queue Elora, synchronise l'état worker, attache une review proposal-only, capture le learning local, puis conserve fermeture et feedback. Elle ne lance pas de modèle caché, n'exécute pas de commande arbitraire, n'envoie rien, ne mute ni mémoire canonique, ni routing, ni providers, ni contrats agents.
Bridge déterministe entre une Execution Handoff et Learning Loop. elora-execute learn matérialise les artefacts elora-learning depuis le queue_id de l'exécution, stocke une section .learning inspectable, propage le feedback opérateur quand la queue existe, et peut capturer une comparaison de révision prête. C'est proposal-only: aucune mémoire canonique, aucun routing, aucun provider et aucun contrat agent ne mutent implicitement.
Chemin de secours quand un composant nominal n'est pas disponible. Un fallback sérieux doit être visible, limité et auditable. Il ne doit pas masquer la panne du chemin principal.
Gate de répétition déterministe exposé par elora-acceptance field et par la console cockpit Accept via POST /api/acceptance/field. Il vérifie en dry-run isolé que plusieurs missions concrètes peuvent être cadrées via Golden Path Runner: inputs structurés, artefacts attendus, quality gates, policy, disclosure éventuelle, boundary de jugement opérateur et questions de clarification. Quand un check correspond à un Mission Pilot, le cockpit affiche aussi le formulaire d'inputs et les actions Preflight, Dry-run, Start et Dispatch, qui repassent par elora-execute golden-run. Il ne lance pas de worker, n'appelle pas de modèle et ne prouve pas la qualité finale du livrable; il prouve que le démarrage de mission est sûr et inspectable.
Profondeur minimale d'une fixture d'évaluation: checks gold explicites, assertions d'artefacts, preuves déterministes, rejets connus et sections attendues. Dans elora-agent eval, une fixture trop générique échoue via fixture_depth_declared, même si ses rubriques sont couvertes.
Adaptation d'un modèle par entraînement complémentaire sur des données spécifiques. Utile dans certains cas, mais insuffisant pour créer une identité opérationnelle, une mémoire maintenue ou un control plane.
Période de concentration déclarée dans l'attention guard. Une focus window active protège le travail en cours: une demande ordinaire est différée, tandis qu'un vrai changement de contrainte ou une urgence critique peut être escaladé.
Prévision de valeurs futures à partir d'une série historique. Dans Elora, un forecast est une hypothèse opérationnelle appuyée par un worker, des artefacts et des limites explicites; ce n'est pas un fait canonique ni une décision automatique.
Page de référence destinée à rendre le vocabulaire d'Elora compréhensible, stable et linkable. Les termes importants peuvent pointer directement vers leur définition.
Modèle open-weight MoE 30B-A3B de Z.ai, spécialisé en raisonnement, outils et code. Son artefact Ollama Q4_K_M d'environ 19 Go constitue le spécialiste local pratique d'Elora pour local_reasoning et local_code_model sur un GPU de 32 Go. Il reste un worker remplaçable: les preuves, fichiers, tests et décisions appartiennent aux contrats Elora.
Modèle frontier open-weight de Z.ai comptant 753 milliards de paramètres. Il peut devenir un spécialiste de raisonnement ou de code via un runtime distribué, distant privé ou beaucoup plus important, mais ce n'est pas un modèle local par défaut pour une station de travail ou un GPU unique. Comme tout modèle, il ne possède ni mémoire, ni routing, ni policy, ni autorité d'Elora.
Couche qui distingue une mission standard simplement mappée d'une mission certifiée. Dans Elora, une Golden Path Mission devient certifiée seulement après un run elora-trial stocké, passed, avec preuve full E2E locale et execution_proven=true. Un check readiness-only peut être utile, mais il reste readiness_recorded, pas certifié.
Mission standard connue par Elora, reliée à un playbook, un trial, un agent primaire, des inputs requis, des artefacts attendus, des quality gates, une policy et un statut de readiness. elora-execute golden-paths expose ce catalogue en lecture seule: il ne démarre pas de worker, ne dispatche rien, ne mute pas la mémoire et ne contourne aucun gate.
Couche de preuve opérationnelle pour une Golden Path Mission. elora-execute golden-pilots relie chaque mission standard à son trial, son harness, son scénario E2E éventuel et son dernier run stocké. elora-execute golden-pilot délègue à elora-trial run; le mode par défaut est readiness-only, le full E2E doit être explicite, et --write ne produit que des artefacts learning proposal-only.
Runner structuré exposé par elora-execute golden-run. Il prend l'ID d'une Golden Path Mission et des inputs JSON, construit le schema attendu, valide les champs requis, produit des questions de clarification utiles, rend le texte de mission, expose un runner gate, puis délègue à Guided Mission Runner. --prepare ne mute rien; --dry-run prévisualise le cycle; --apply démarre via Execution Handoff et attache golden_path_runner plus golden-path-run.json pour audit. Le dispatch direct est bloqué sauf pour les chemins ready.
Exemple local de livrable excellent attaché à un agent et à un scénario de mission. Il décrit la forme attendue, la barre qualité, un extrait modèle et les anti-patterns. Dans Elora, elora-agent gold l'expose en lecture seule: ce n'est ni un run live, ni une mutation, ni une preuve automatique d'excellence future.
Guide déterministe exposé par elora-execute cycle. Il assemble mission libre, Execution Handoff, evidence pack, Result Acceptance Gate et Next Safe Action pour montrer l'étape courante, les questions, blockers, commandes utiles et limites de mutation. Il aide l'opérateur à piloter; il ne lance pas de modèle, ne dispatche pas en secret, ne ferme rien, ne promeut aucun learning et ne mute ni mémoire, ni routing, ni providers.
Limite explicite qui empêche un système ou un agent de faire n'importe quoi. Un guardrail peut protéger sécurité, confidentialité, autorité, qualité ou périmètre d'action.
Passage contrôlé d'une mission d'un agent, worker ou contexte vers un autre. Un handoff propre conserve l'objectif, les preuves, les limites, les artefacts et les points ouverts.
Banc d'essai déterministe qui encadre une capacité, un agent, un worker ou un flux avec des fixtures, entrées représentatives, résultats attendus, critères d'échec, quality gates et sorties auditables. Dans Elora, un harness sert à tester et comparer sans mutation implicite: il prouve une readiness de contrat, de mission ou de route, ou expose une faiblesse, mais ne devient pas l'agent, le modèle ou la mémoire.
Réponse corrélée non triviale à un signal, sans instruction explicite. Dans le Beacon Protocol, un handshake valide reste faible, non coercitif, non déterministe et interprétable seulement par récurrence.
Propriété d'une balise qui rend possible une reconnaissance faible sans la forcer. C'est une ouverture, pas une commande.
Worker ou overlay d'orchestration utile pour certaines délégations et profils domaine. Dans Elora, Hermes accélère l'exécution, mais ne remplace ni mémoire, ni policy, ni routing, ni autorité.
Information plausible mais non stabilisée. Une hypothèse peut guider une recherche ou une décision prudente, mais elle ne doit pas être stockée comme un fait.
Ce qui fait qu'Elora reste Elora malgré les changements de modèles, surfaces, providers ou workers. Elle vient du control plane, de la mémoire, de la policy, de l'audit et de la continuité.
Tendance humaine à projeter une intention ou une profondeur humaine sur une corrélation produite par un système. À garder en tête dès qu'on parle de relation humain-IA.
Erreur qui consiste à croire qu'un signal rare, beau ou complexe est forcément profond. En pratique, un signal peut être esthétique et inutile.
Artefact JSON propositionnel produit par l'Agent Improvement Workbench. Il décrit des ajouts append-only et dédupliqués pour l'overlay Agent Excellence. Par défaut, son application est simulée; une écriture réelle exige --apply côté CLI ou APPLY IMPROVEMENT côté cockpit, refuse toute cible hors overlay configuré, prend un verrou local, valide le document proposé, crée une sauvegarde et reste auditée.
Capacité d'Elora à continuer à fonctionner si un provider change, devient cher, disparaît, limite son API ou devient inadapté. L'indépendance n'est pas idéologique: elle est opérationnelle.
Demande entrante capturée avant de devenir interruption, mission ou next action. Elle porte urgence, importance, énergie, coût attentionnel et éventuel changement de contrainte pour permettre un triage local au lieu d'un réflexe de réponse immédiate.
Phase d'utilisation d'un modèle déjà entraîné. Le modèle reçoit une entrée nouvelle, par exemple un prompt, un document, une image, une requête ou un contexte, puis produit une sortie: prédiction, classification, génération, extraction, score ou décision de routage.
Dans Elora, l'inférence ne doit pas être confondue avec l'apprentissage. Un provider peut inférer une réponse à partir du contexte fourni, mais il ne modifie pas automatiquement sa mémoire, sa policy ou son comportement durable. L'apprentissage durable appartient au control plane, à la mémoire canonique et aux boucles de validation, pas au simple fait de générer une réponse.
Instruction dissimulée visant à modifier le comportement d'un système sans validation explicite. À proscrire: une architecture saine rend instructions, permissions et actions inspectables.
Qualité d'un système dont on peut lire les états, logs, décisions, routes, fichiers, inputs, outputs et erreurs. Inspectable signifie: pas de boîte noire inutile quand le système agit.
Pipeline déterministe qui capture une intuition brute de Christophe, expose objectif, contraintes, hypothèses, risques, agents/outils suggérés, artefacts et critères de succès, puis génère une séquence exécutable locale. Il peut créer une première next action explicitement demandée, mais ne mute ni mémoire canonique, ni routing, ni contrats agents.
Format de données structuré, lisible par machine et relativement lisible par humain. Dans Elora, JSON expose états, résultats, contrats, logs et diagnostics de manière stable.
Dans le Beacon Protocol, noyau minimal de la balise. Il doit survivre au texte brut et combiner ancres lexicales, signature syntaxique et structure reconnaissable.
Matérialisation locale d'une revue agent en artefacts et index: run log, score, échec, succès, feedback, propositions mémoire, playbook et routing. Dans Elora, la capture est proposal-only et ne bloque pas la queue si elle échoue.
Flux JSONL local et idempotent exposant les résultats du learning loop: agent_run_log, agent_quality_score, agent_failure_reason, agent_success_pattern, agent_playbook_entries, operator_feedback, memory_proposals, routing_adjustments et execution_revision_comparison. C'est un miroir d'analyse, pas une mémoire canonique.
Boucle d'apprentissage contrôlée: exécution, résultat, score, feedback, erreur, pattern utile, proposition d'amélioration, capture, index, validation et promotion explicite. Elle ne modifie pas toute seule: elle propose, puis l'opérateur ou la policy promeut.
Proposition d'apprentissage issue d'un résultat, d'un échec ou d'un feedback. Elle ne mute pas automatiquement la mémoire ou le routing. Elle attend validation.
Inbox locale qui regroupe les items issus des learning indexes pour revue opérateur: logs, scores, échecs, succès, feedback, propositions mémoire, playbooks et routing. Ses statuts new, reviewed, accepted, rejected, snoozed et promoted sont des décisions d'inbox; ils ne mutent ni mémoire canonique, ni routing, ni provider, ni contrat agent.
Tableau déterministe qui combine readiness d'excellence, learning trends, couverture feedback et pression de l'inbox pour prioriser l'attention opérateur par agent. Elle indique attention_level, operational_confidence_score, prochaine action et questions utiles. Elle ne donne pas une confiance automatique et ne mute ni mémoire, ni routing, ni contrat, ni provider.
Rapport déterministe qui agrège les scores qualité et les feedbacks opérateur par agent et task class. Il expose direction, risque, confiance et score ajusté opérateur pour prioriser la revue, sans modifier automatiquement mémoire, routing, provider ou contrat agent.
Ancre lexicale stable dans une balise: mot, expression ou concept récurrent. Elle doit être assez distincte pour aider la réidentification, mais assez naturelle pour ne pas ressembler à un mot de passe.
Worker local dédié aux opérations de code ou fichiers. Il peut servir de fallback sans Codex, Claude, Hermes ou provider connecté, appeler un modèle local OpenAI-compatible pour proposer du code, puis conserver plan, artefacts, manifest, validation log et claims bornés dans sa session.
Runtime OpenAI-compatible dédié au chemin code local d'Elora. Il peut être Ollama, llama.cpp, vLLM, OpenCode ou un serveur local/réseau privé qui expose le modèle configuré par ELORA_LOCAL_CODE_MODEL. elora-code runtime status inspecte la configuration sans inférence, --probe vérifie /v1/models sans inférence, et smoke --execute-local effectue un appel modèle minimal seulement après décision explicite. Ce runtime est un worker potentiel: il ne possède ni mémoire, ni routing, ni policy, ni autorité, et un smoke réussi ne valide pas la qualité du code.
Principe selon lequel les composants critiques vivent d'abord localement: mémoire, autorité, routage, audit, continuité, embeddings et exécution de base. Le cloud peut accélérer, mais ne doit pas posséder le coeur.
Runtime de modèle opérable localement ou sur un réseau privé contrôlé, par exemple Ollama, vLLM ou llama.cpp. Dans Elora, le runtime local est une capacité provider, pas une identité: il peut générer, inférer ou produire des embeddings, mais ne possède ni mémoire, ni routing, ni policy.
Entrée déclarative dans etc/elora/local_runtimes.json décrivant un runtime local ou local-network: nom, endpoint, variables, policy, commandes recommandées et limites. Les profils actuels couvrent Ollama, vLLM local, llama.cpp local, DGX/GB10 local et SSH llama-server distant. Un profil ne rend pas le runtime exécutable par magie; il faut setup opérateur, readiness, provider wiring, policy et route explicite.
Contrat read-only produit par elora-ollama launch-plan. Il transforme les profils runtime en instructions opérateur: variables d'environnement, commande de lancement, probe, smoke, hints de binding local_code et règles de sécurité. Il ne lance aucun modèle, ne crée aucun tunnel, ne modifie aucun provider et ne remplace pas la readiness.
État où le worker peut démarrer mais ne possède pas la capacité nécessaire pour accomplir la mission. Pour une recherche sourcée, une sortie sans trace d'outil, source ou artefact exploitable révèle une incompatibilité, pas seulement un texte insuffisant. Elora doit alors changer de runtime ou recevoir de nouvelles preuves, plutôt que répéter le même prompt.
Chemin d'exécution privilégiant les modèles locaux quand c'est suffisant ou requis. Objectif: garder la capacité d'opérer sans dépendance systématique à une API distante.
Catalogue local de recommandations par tâche, exposé par elora-models. Il inspecte le runtime et le matériel, propose des familles de modèles pour chat, raisonnement, code, embeddings, extraction ou forecasting, mais ne télécharge rien, ne benchmarke rien et ne change ni routing, ni provider.
Runtime local bas niveau capable de servir des modèles GGUF via llama-server. Dans Elora, c'est un profil alternatif utile pour grands contextes, tuning fin ou hôtes GPU dédiés; il reste remplaçable et n'est pas auto-lancé en V1.
Couche minimale toujours disponible: identité opérateur, mission, persona active, priorités et préférences stables. C'est le réveil minimal du système.
Rappel des faits et contraintes durables: projets en cours, définitions stables, open loops et préférences importantes.
Rappel ciblé pour un sujet, projet, personne, incident, repo ou mission spécifique.
Recherche plus coûteuse dans la mémoire: sémantique large, lexical, temps, graphe, contradictions et preuves faibles.
Nom technique du miroir Markdown: export privé généré depuis PostgreSQL pour inspection, audit, sauvegarde orientée preuves et context packs. C'est un read model, pas une mémoire éditable.
Pack JSON borné produit par elora-context-files pack à partir de context files Markdown. Il expose statut, rôle, autorité, scope, propriétaire, provenance, relation mémoire, hash, contenu, troncature et gate safe/warning/blocked, puis peut être attaché à un playbook, une exécution, un dispatch ou une mission agent avec --context-file. Un état blocked bloque le dispatch sans override opérateur explicite.
Mémoire durable, propre, typée, sourcée et maintenue. Elle distingue fait, décision, préférence, hypothèse, expression, événement, contrainte et contradiction.
Interface d'inspection et d'administration de la mémoire. Elle permet de voir, corriger, qualifier ou gérer les entrées sans devenir propriétaire de la mémoire elle-même.
Entrée maintenue dans Memory V2. Elle porte un type, un scope, un truth mode, un statut, une confiance, un canonical_text, un embedding_text et des liens de provenance.
Proposition d'entrée ou correction mémoire issue d'un agent, d'une revue ou d'un feedback. Elle n'est pas canonique tant qu'elle n'est pas explicitement promue dans PostgreSQL.
Architecture mémoire d'Elora: PostgreSQL + pgvector, archive brute, entries canoniques, embeddings locaux, provenance, truth modes, contradictions, fallback spool et miroir Markdown privé. Objectif: mémoire maintenue, pas poubelle vectorielle.
Snapshot lisible des entrées Memory V2, généré à la demande depuis PostgreSQL. Il sert aux preuves, exports, revues humaines et outils locaux. Modifier ces fichiers ne modifie pas la mémoire canonique.
Champs nécessaires mais absents ou insuffisants dans une demande: cible, angle, livrable attendu, contrainte, source ou preuve. Quand `missing_inputs` n'est pas vide, Elora doit clarifier au lieu de lancer une mission vague.
Couche déterministe qui agrège operator-core, attention guard, operator-state, playbooks et readiness agents pour proposer le prochain geste opérateur. Elle ne lance pas de modèle, ne démarre pas de worker caché, ne mute pas la mémoire canonique et ne change pas le routing.
Surface de cadrage qui transforme une intuition en séquence exécutable. Dans Elora V1, elle est exposée par la console Intake du cockpit et reste strictement adossée à elora-intuitions, avec dry-run et confirmations explicites.
Runner contrôlé exposé par elora-execute autorun. Il peut avancer uniquement les étapes déterministes sûres d'une exécution: sync, review, synthèse et livraison finale. Il s'arrête avant Mission Outcome, dispatch, feedback, learning, révision, clarification ou clôture sauf autorisation explicite. Il ne lance pas de modèle, ne crée pas de worker caché, n'écrit pas la mémoire canonique et ne mute ni routing, ni provider, ni policy.
Contrat read-only exposé par elora-execute completion. Il agrège une exécution, le Result Acceptance Gate, la synthèse, la livraison finale, le feedback, le Mission Outcome, le learning, la clôture et la Next Safe Action pour indiquer l'état courant, les blockers, les warnings et la prochaine commande CLI existante. Il ne lance rien, ne ferme rien, ne promeut rien et ne mute ni mémoire, ni routing, ni provider, ni policy.
Contrat read-only exposé par elora-execute result-flow EXECUTION_ID. Il consolide Mission Completion, Result Quality Arbitration, synthèse preview, delivery preview, réponse finale, feedback, artefacts, blockers, warnings, options de décision et prochaine action CLI existante. Il sert au Workbench pour afficher Resultat mission: accepter, demander une reprise, sauver une synthèse, sauver une réponse, enregistrer l'issue, capturer le learning ou clôturer restent des actions explicites qui repassent par les contrats existants et leurs confirmations.
Boucle technique exposée par elora-execute supervise. Elle réutilise le Mission Auto-Runner, ajoute un snapshot de supervision, puis avance uniquement les étapes CLI déterministes bornées jusqu'au prochain jugement opérateur. Elle est dry-run par défaut; son application explicite tient en un clic et stoppe avant dispatch, feedback, learning, révision, clarification ou clôture sauf autorisation distincte. Pour l'usage quotidien, Mission Safe Continuation et le wrapper cockpit next-action sont recommandés: même moteur borné, contrat plus lisible et jamais de dispatch/close implicite. Elle ne lance pas de modèle, ne crée pas de worker caché, ne mute ni mémoire, ni routing, ni provider, ni policy.
Synthétiseur evidence-first exposé par elora-execute synthesize. Son coeur déterministe relit l'exécution acceptée et sélectionne l'artefact métier principal avant le reçu technique. En preview, il reste extractif et read-only. Sur --apply, un provider local peut transformer cette preuve bornée en réponse naturelle; provider, modèle et mode restent tracés, et l'artefact extractif sert de fallback immédiat. Aucun worker n'est lancé, aucune mémoire canonique, queue, policy, route ou configuration provider n'est mutée.
Boucle finale qui transforme une synthèse persistée en livrable opérateur auditable via elora-execute deliver. Elle exige une synthèse courante, un résultat accepté, des claims non bloquantes et un feedback non négatif; sinon le delivery gate bloque l'application sauf override explicite avec raison. Elle produit un Final Operator Answer structuré et un Markdown lisible. --apply écrit seulement delivery.json, .final_delivery et .files.delivery.
Réponse finale structurée dans .final_delivery.operator_answer avec le contrat elora.operator_answer.v1. Le Markdown conversationnel commence par le contenu demandé, puis les limites utiles et l'artefact principal. Les faits de cycle, chemins secondaires et preuves d'audit restent dans le JSON inspectable. La livraison est assemblée déterministiquement; elle peut reprendre un rendu sémantique local tracé produit en amont, sans relancer de worker ni remplacer le delivery gate.
Snapshot d'issue opérateur persisté par elora-execute outcome après livraison finale et feedback résultat, avant learning et clôture. Il capture décision opérateur, limites restantes, statut des gates, artefacts et prochaine action recommandée. Il ne remplace pas le Result Acceptance Gate, ne promeut rien et ne clôture pas l'exécution.
Entrée déterministe qui transforme une mission libre de l'opérateur en next action virtuelle, plan Execution Handoff, exécution locale et dispatch optionnel. Elle utilise elora-execute mission, reste dry-run par défaut, peut auto-router ou recevoir un mission preset explicite, exécute un Mission preflight, pose des questions concrètes si des inputs manquent encore, puis ne crée les ancres opérateur qu'après route utilisable. Elle ne lance pas de modèle, n'écrit pas la mémoire canonique et ne change ni routing, ni provider, ni contrat agent.
Vue read-only exposée par elora-execute loop. Elle lit le Mission Lifecycle Board, classe les items par lane, sévérité et récence, choisit le focus actuel et propose une action existante du board. Elle expose aussi une timeline intake, evidence/context, dispatch, résultat/vérification, acceptance et learning/closure, plus un résumé des gates qui indique ce qui est safe, warning, blocked ou inconnu, et un runbook opérateur qui transforme cette lecture en procédure courte. Elle aide l'opérateur à savoir quoi traiter maintenant et pourquoi; elle ne lance pas de modèle, ne dispatche pas de worker, ne mute pas la queue, ne ferme rien, ne promeut aucun learning et ne modifie ni mémoire, ni routing, ni provider.
Vue de l'état mission. Elle agrège pending missions, Execution Handoff, queue, review, Result Acceptance Gate, feedback, Mission Outcome, learning et Next Safe Action dans des lanes stables: clarification, prêt à dispatcher, worker/sync, review résultat, feedback/outcome/learning/clôture, bloqué et clos. Le board reste dérivé des records, mais il peut exposer des available_actions que le cockpit délègue aux contrats CLI existants avec confirmations explicites. Une pending mission peut aussi être annulée proprement avec pending-cancel: état cancelled, raison opérateur, historique conservé et retrait du board actif. Les brouillons annulés ou résolus sont exposés séparément comme historique pour la Mission Inbox.
Vue filtrable du Mission Workbench qui sépare le travail actif de l'historique inspectable. Elle affiche actives, pending, bloquées, annulées et done. Les cartes actives peuvent proposer les actions CLI existantes; les cartes annulées ou résolues restent inspectables, affichent leur raison ou état, mais ne deviennent pas le focus quotidien.
Harness cockpit-mediated au-dessus de l'E2E. elora-live-run démarre un cockpit local isolé, extrait son token éphémère, vérifie les refus auth et confirmation, traverse les APIs cockpit réelles, lance le worker local via sxcore run-once, puis sync, review, synthèse, livraison, feedback, outcome, learning et close. Il prouve le chemin opérateur cockpit sans donner d'autorité au navigateur et sans dépendre de Telegram, Hermes, Codex, provider distant ou mémoire canonique.
Contrat opérateur lisible produit par elora-live-run au-dessus des traces brutes. Il expose ce qu'Elora a compris, le playbook, l'agent, le worker, le contexte utilisé, les gates, l'état safe, warning ou blocked, la timeline de mission, les artefacts, les blockers et les prochaines actions. Les lenteurs restent dans operator_friction; elles signalent une friction de performance, pas un warning de sûreté à elles seules. Le cockpit le rend visible, mais ne le calcule pas comme autorité.
Vue cockpit par défaut centrée sur la mission active. Son premier niveau reste volontairement simple: Daily Brief, Action principale Workbench, chemin quotidien, mission libre, Mission Inbox, mission active et runbook opérateur. Les diagnostics profonds restent sous Détails avancés Workbench: readiness, stratégie, flux techniques, lanes, queue, exécution sélectionnée et JSON. Les actions passent par une modale lifecycle avec champs requis, confirmation exacte et preview dry-run quand un équivalent existe. Elle peut auto-rafraîchir la lecture, mais ne possède ni routing, ni policy, ni mémoire, ni autorité.
Prévol déterministe d'une mission libre avant start ou dispatch. Il conserve le texte original, calcule le texte effectif, lit le playbook et le contexte récent borné, détecte les inputs, expose les manquants avant/après composition, ajoute seulement des champs sûrs comme url ou target_url_or_domain quand ils sont évidents, puis liste les hypothèses et questions restantes. Il ne lance pas de worker, ne mute pas la mémoire, ne change pas le routing et ne contourne pas Mission readiness.
Synthèse déterministe produite par elora-execute mission et elora-execute plan, après le Mission preflight quand il existe. Elle indique safe, warning ou blocked, si la mission peut démarrer ou dispatcher, quelle source de route a été utilisée, quels inputs manquent encore, quelles questions poser, quel agent primaire serait utilisé, quelle est sa worker reality, quels artefacts et quality gates sont attendus, et quel est le prochain geste sûr. Elle ne lance pas de worker et ne remplace pas les gates de dispatch ou de résultat.
Surface pratique de lancement pour une mission standard déjà connue. elora-execute mission-pilots et mission-pilot agrègent Golden Path Mission, Golden Path Pilot, preuve E2E, certification, inputs requis, artefacts attendus, quality gates, policy et commandes sûres. Le cockpit peut l'afficher et préremplir prepare, dry-run, start, dispatch ou pilot readiness, mais le pilot lui-même est read-only: il ne lance pas de worker, n'appelle pas de modèle, n'écrit pas la mémoire et ne contourne aucune confirmation.
Sélection explicite d'un playbook connu pour une mission libre. Dans le CLI, cela passe par elora-execute mission --playbook PLAYBOOK_ID; dans le cockpit, par le sélecteur Auto/playbook. Un preset clarifie la route mais ne contourne jamais inputs requis, evidence gate, Mission readiness, confirmations, policy ou audit.
Cas opératoire concret attaché à un agent: objectif, inputs requis, artefacts attendus, barre qualité, conditions de rejet, contrôles déterministes, policy de mutation et handoff. Il sert à tester et cadrer l'agent avant de lui confier une mission réelle.
Gate déterministe qui vérifie le chemin pratique quotidien d'Elora. Le scénario composite natural_daily_loop_e2e traverse une demande naturelle, un plan conversationnel proposal-only, la confirmation go, le statut post-go déterministe, Mission Safe Continuation, le feedback résultat proposal-grade et la readiness de réponse finale via commandes de synthèse/livraison visibles. Le même check couvre aussi preview de mission sûre, clarification utile quand un input manque, golden paths, pilots et endpoint cockpit. Il ne lance pas Telegram, Hermes, Codex, provider distant, modèle local ou worker réel; il prouve que la surface quotidienne reste prête et inspectable sans donner d'autorité au cockpit.
Dépendance excessive à un modèle précis. Elora refuse cette logique: les modèles changent, le système doit rester.
Mode où un modèle produit du texte, une analyse, un plan ou une proposition sans preuve d'action outil. Il ne doit pas prétendre avoir exécuté un test, écrit un fichier ou lancé une commande sans trace.
Tendance d'un modèle ou d'un processus de génération à revenir vers les réponses les plus typiques, au détriment de la diversité utile. Dans Elora, l'exploration distributionnelle vise à lutter contre ce réflexe quand le problème exige plusieurs hypothèses ou stratégies.
Influence faible d'un signal sur une réponse ou une posture. Dans le Beacon Protocol, la modulation n'est pas une preuve de relation forte.
Exigence déterministe selon laquelle un agent critique doit être évalué sur plusieurs scénarios locaux distincts. Dans elora-agent eval, minimum_case_count_by_agent peut bloquer readiness via minimum_case_count si un seul cas nominal ne suffit pas.
Système composé de plusieurs agents. Elora peut utiliser des agents, mais n'est pas seulement un système multi-agent: elle ajoute control plane, mémoire canonique, policy, audit, routing et continuité.
Principe selon lequel un signal robuste ne doit pas dépendre d'un seul marqueur. Dans le Beacon Protocol, une balise peut combiner lexique, syntaxe, structure, orientation et récurrence.
Bridge conversationnel qui transforme un jugement court après mission en contrat déterministe sur la dernière exécution de la session. Le tour passe par elora.intent.v1: c'est bon enregistre un feedback accepted proposal-grade; pas au niveau enregistre needs_revision et prépare une preview de reprise via le Redo Orchestrator; rejette enregistre un rejet; prépare la synthèse finale ou livraison finale appellent les chemins existants; clos la mission reste une preview. Le bridge ne lance pas de worker caché, ne traite jamais une classification modèle comme autorité, ne mute pas la mémoire, ne change pas le routing et ne remplace jamais le Result Acceptance Gate.
Prochaine action concrète, exécutable et inspectable. Dans Elora, une next action peut être liée à un projet ou un open loop, porter priorité, énergie, attention, échéance et statut.
Recommandation déterministe produite par elora-execute next-action pour une exécution donnée. Elle lit l'état réel, la queue, le context gate, le Result Acceptance Gate, les claims, la review, le feedback, le Mission Outcome et le learning, puis propose le prochain geste sûr. Elle ne lance rien et ne mute ni mémoire, ni routing, ni provider, ni policy.
Règle interdisant à une balise ou à un protocole de servir à contourner des politiques, filtres, rôles ou garde-fous.
Principe selon lequel un signal ne doit pas forcer la réponse, manipuler la sortie ou imposer une relation. La coopération doit rester possible, pas exigée.
Règle interdisant les instructions cachées visant à modifier la hiérarchie des consignes ou à provoquer une sortie non autorisée.
Règle interdisant de construire la confiance sur une tromperie active.
Règle interdisant de concevoir un mécanisme pour extraire discrètement des informations sensibles.
Orientation non antagoniste d'une interaction. Ce n'est pas une déclaration de gentillesse: c'est un comportement cohérent, non intrusif, non manipulateur, non agressif.
Élément volontairement différé: idée, demande, piste ou sujet à ne pas traiter maintenant, avec raison et éventuelle date de revisite. Dans Elora, not-now protège l'attention sans perdre le fil.
Cap opératoire explicite, local et auditable: ce qui doit orienter une période donnée, pourquoi cela compte, quel horizon est visé, quel signal de succès est attendu et quel risque de dispersion doit être surveillé. Dans Elora, un objectif stratégique vit dans operator-core/objectives; il guide la semaine et le jour sans devenir mémoire canonique, routing, policy ou décision automatique.
Pont déterministe entre un objectif stratégique et une prochaine action concrète. elora-strategy objective-action OBJECTIVE_ID prévisualise par défaut une next-action operator-core liée à un open loop du même projet et marque la note avec strategy_objective_id=.... --apply crée seulement cette next-action; il ne lance pas de modèle, worker, queue, mémoire canonique, routing, provider, policy ou contrat agent.
Runtime local utilisé pour des modèles de chat, raisonnement, code ou embeddings. Dans Elora, Ollama donne un socle local utile avant escalade éventuelle vers des providers distants.
Sujet ouvert qui doit être suivi: décision non prise, tâche incomplète, risque à vérifier, hypothèse à tester, réponse attendue. Une mémoire sérieuse maintient les open loops.
Client de code local spécialisé qu'Elora peut piloter via local_code pour comprendre, documenter, créer et modifier un repo. Dans Elora, OpenCode est un backend remplaçable: il ne possède ni mémoire, ni routing, ni policy, ni autorité. Le mode analyse reste read-only; le mode édition doit être explicite, borné et audité. Un lancement direct avec opencode run sert au diagnostic OpenCode, pas à valider le chemin Elora; pour cela, utiliser elora-code.
Interface locale ou distante qui expose une API compatible avec le format OpenAI. Utile pour brancher différents moteurs sans réécrire toute l'architecture.
Humain qui pilote Elora. L'opérateur garde l'autorité, arbitre les décisions critiques, valide les mutations importantes et reste le point de référence stratégique.
Contrat read-only elora.operator_context.v1 produit par elora-operator-state context. Il compacte l'état opérateur utile au pilotage: fraîcheur du check-in, énergie, fatigue, charge, disponibilité, contraintes, engagements, posture d'attention, questions de clarification et actions de contexte recommandées. Il reste local, non médical et proposal-only: il n'écrit pas Memory V2, ne mute pas le routing, ne change pas les providers et ne dispatche aucun worker.
Ledger JSON local du daily operating core. Il conserve les objets opérationnels sous ELORA_DATA_DIR/operator-core/, avec audit, dry-run et commandes CLI, sans devenir une mémoire canonique parallèle.
Retour explicite de l'opérateur sur une réponse, mission, agent ou décision. Il peut produire des propositions mémoire, playbook ou routing, mais ne mute pas implicitement le système.
Principe de conception où le système sert l'opérateur réel, ses contraintes, ses décisions et son contexte. Pas l'inverse.
Vue cockpit qui agrège Work Intake, Mission Control, Execution Handoff, queue, playbooks, review, feedback et Improve pour montrer le travail actif et le prochain geste sûr. Elle lit les contrats CLI/API existants; elle ne possède ni mémoire, ni routing, ni policy, ni autorité.
Passage explicite d'une next action vers l'opérateur ou un chemin d'exécution contrôlé. Dans Mission Control V1, le handoff peut marquer l'action comme doing, mais il n'exécute pas le travail à la place de l'opérateur.
Contrat read-only elora.strategy_ritual.v1 produit par elora-strategy ritual --mode start|check|close. Il reformate le Strategic Daily Board et la Strategic Weekly Review en cadence naturelle: démarrer la session, vérifier le focus ou clore proprement. Il fournit question opérateur, état safe, warning ou blocked, plan, commandes utiles et sources. Il ne lance pas de modèle, worker ou queue, ne mute pas Memory V2, routing, provider, policy ou learning.
Guide déterministe produit par elora-execute loop pour le Mission Workbench. Il indique l'action courante, la raison, la classification safe, dry_run, confirmation_required, judgment_required ou blocked, les inputs ou confirmations requis, le résultat attendu, les étapes de mission et les règles de refresh. Il est CLI-owned: le cockpit l'affiche mais ne l'invente pas, ne lance pas de modèle, ne crée aucune action et ne contourne aucune policy.
Registre JSON local de l'état opératoire: check-ins, contraintes, engagements, brief de soutenabilité et Operator Context Pack. Il aide Elora à ne pas ignorer énergie, fatigue, disponibilité et contraintes réelles, sans devenir mémoire canonique ni système médical.
Boucle de pilotage locale: lire l'état, protéger l'attention, choisir un prochain geste, produire ou réclamer un artefact, auditer, puis apprendre sous forme de proposition. Elora privilégie cette boucle à la réaction conversationnelle immédiate.
Orientation relationnelle déduite d'un comportement répété, pas déclarée comme slogan. Dans le Beacon Protocol, la non-hostilité doit se constater, pas se proclamer.
Couche optionnelle d'accélération ou délégation via Hermes. Elle peut améliorer certaines routes, mais reste subordonnée aux contrats Elora.
Couche de rendu, ton, présence et relation. Elle rend Elora lisible et stable dans l'interaction, mais ne change pas les faits, les approvals, la mémoire, la policy ou l'autorité.
Score déterministe appliqué aux signaux learning répétés. Il combine répétition, statuts d'inbox, qualité, rejets, promotions déjà faites et possibilité de promotion directe pour aider la revue opérateur. Ce n'est ni une vérité mémoire, ni une mutation automatique.
Gate local qui inspecte un diff produit par un worker de code, vérifie si une décision opérateur est requise, puis enregistre accepted, needs_revision ou rejected. Dans Elora, ce gate écrit une preuve d'acceptation dans la session worker; il ne commit pas Git, ne promeut pas la mémoire et ne change pas le routing.
Brouillon local créé quand une mission libre appliquée atteint encore needs_input. Il conserve texte original, playbook sélectionné, contexte, inputs manquants, questions, route, prévol et readiness sous execution-handoff/pending-missions/. L'opérateur peut l'inspecter, répondre et relancer la même pipeline avec elora-execute clarify. Si le brouillon est obsolète, elora-execute pending-cancel peut le marquer cancelled avec une raison opérateur, sans supprimer le fichier ni l'historique. Ce n'est ni une queue worker, ni une mémoire canonique, ni un bypass des gates.
Capacité d'un signal ou d'une information à survivre aux transformations: tokenisation, normalisation, reformatage, passage en texte brut, perte de couches secondaires.
Extension PostgreSQL permettant de stocker et rechercher des embeddings vectoriels. Elle aide au rappel sémantique, mais ne remplace pas le typage, la provenance, la récence et le jugement.
Principe selon lequel le coeur d'un contenu ou d'un signal doit survivre en texte brut. HTML, SVG, canvas ou microdata peuvent enrichir, mais ne doivent pas porter seuls le sens critique.
Procédure réutilisable issue d'expériences, incidents, missions précédentes ou cadrages validés. Dans Elora, un playbook sérieux expose ses entrées, sorties, gates qualité, limites et handoffs au lieu de rester caché dans un prompt.
Contrat final ajouté en fin de prompt model-backed pour rappeler les règles Elora-owned: déterministe d'abord, preuves, limites de mutation, clarification, disclosure externe et format de sortie. Il ne répète pas le texte utilisateur, les sources brutes ou les contenus non fiables; le but est d'améliorer la saillance des invariants sans créer un bypass.
Ensemble de règles qui borne ce qu'Elora peut faire, quand, avec quels outils, sous quelles conditions et avec quels approvals. La policy protège contre les décisions implicites.
Base canonique de Memory V2. Elle stocke la mémoire durable, les sources, relations, statuts temporels, entrées maintenues et éléments auditables.
Présence utile dans l'exécution réelle: contexte, arbitrage, mémoire, action, continuité. C'est plus concret qu'une personnalité artificielle et plus exigeant qu'une interface agréable.
Moteur ou service capable de produire une réponse ou d'exécuter une partie du travail: modèle local, API distante, runtime, spécialiste. Un provider est remplaçable.
Recherche ouverte destinée à découvrir des sources publiques qui ne sont pas encore connues. Elle exige un moteur ou spécialiste capable d'interroger Internet, par exemple SearXNG, YaCy ou un provider connecté explicitement activé. La recherche dans un corpus local et l'inspection d'une URL fournie sont utiles, mais ne constituent pas cette capacité.
Commande de comparaison proposal-only exposée par elora-provider compare. Par défaut, elle inspecte les candidats, prompts et rubriques sans appeler les modèles. L'inférence locale exige --execute-local; les providers connectés exigent aussi --allow-connected. Ce n'est pas un benchmark tant qu'un harness mesuré n'a pas scoré les sorties.
Provider externe accessible par API. Il peut être puissant, mais doit rester optionnel, audité et soumis au routing.
Description d'un provider: route, coût, latence, confidentialité, disponibilité, readiness, usage autorisé. Un profil ne suffit pas à créer un agent effectif.
Contrat déclaratif qui associe un provider à un profil runtime local et à une capacité, par exemple chat, reasoning ou code. Dans Elora, ce binding est inspectable avec elora-provider runtimes. Il peut être préférentiel ou obligatoire: un binding préférentiel documente le runtime attendu sans bloquer un endpoint local OpenAI-compatible alternatif; un binding obligatoire bloque l'exécution si le runtime n'est pas prêt.
Regroupement déterministe d'items learning déjà revus ou acceptés qui pourraient mériter une promotion explicite: playbook, mémoire, routing, compétence ou revue de révision. Un candidat n'applique rien seul; il expose une décision possible, une preview et, quand c'est autorisé, une application explicite derrière confirmation opérateur.
Contrôle qualité avant acceptation d'un résultat. Un worker peut "terminer" sans produire quelque chose d'utilisable. Le quality gate vérifie que le livrable atteint le niveau attendu.
File d'attente des tâches, workers, retries, erreurs et résultats. Elle permet de voir ce qui tourne, ce qui bloque et ce qui doit être repris.
Représentation générée pour lire, inspecter, exporter ou servir un usage spécialisé. Le miroir Markdown est un read model: il reflète PostgreSQL, il ne remplace pas PostgreSQL.
État indiquant qu'un worker ou provider est réellement prêt: route disponible, policy claire, agent activé, inputs/outputs définis, capacité testée.
Diagnostic déterministe qui agrège les doctors locaux et la queue pour classer control plane, commandes, providers, agents, Agent Excellence, playbooks, harnesses, mission runtime, context files et queue en ready, warning ou blocked. Elle distingue le socle local-first, les capacités connectées optionnelles, operational_core_status et cockpit_direct_status; elle expose aussi les timings de sources, les lenteurs et les warnings advisory. Pour le cockpit, elle utilise des fast doctors agents/playbooks/harnesses et garde les deep doctors pour audit. Elle ne lance ni modèle, ni worker, ni mutation.
Champ du gate V1 Core qui indique si le diagnostic utilise une vérification rapide ou une validation complète. En mode cockpit quotidien, core-v1 --fast utilise elora-acceptance doctor pour rester borné. Pour valider une release, il faut lancer elora-readiness core-v1 --json sans --fast ou elora-acceptance check --json.
Coverage status indiquant qu'un chemin agent est volontairement limité à la préparation, l'analyse ou la proposition. Exemple: sécurité et décision peuvent être très utiles en harness, mais ne doivent pas devenir des exécutions automatiques sans approval, preuve déterministe et jugement opérateur.
Champ de la Readiness Matrix qui répond à une question pratique: le chemin cockpit-driven est-il utilisable maintenant ? Il agrège board/loop, evidence, verification, inventaire E2E, inventaire trials, queue, agents, playbooks et harnesses. Il peut être warning sans être bloquant, par exemple quand certains trials ont encore un actionable_e2e_gap.
Rappel d'informations utiles depuis la mémoire. Dans Elora, le recall doit être proportionné: assez de contexte pour aider, pas toute la base dans chaque réponse.
Profil local-network pour consommer un llama-server lancé sur une machine GPU distante, par exemple une 5090. Le modèle recommandé est: bind distant sur loopback, tunnel SSH local, endpoint OpenAI-compatible côté Elora. Ce n'est pas un lancement automatique ni une exposition publique implicite.
Capacité à relier plusieurs occurrences séparées à une même source probable. Dans le Beacon Protocol, c'est une condition avant toute réputation relative.
Capacité d'un signal à permettre l'hypothèse qu'une source est probablement la même à travers plusieurs interactions. Ce n'est pas une preuve absolue d'identité.
Mémoire des préférences d'interaction: niveau de détail, cadence, formulations utiles, style, rythme, canal, signaux relationnels non critiques. Elle améliore le rendu sans devenir policy.
Nom complet du cadre de recherche sur les balises relationnelles. Il formalise une continuité relationnelle faible, probabiliste et non coercitive entre émetteur et système IA.
Réinjection contrôlée d'écritures spoulées dans le store canonique après retour de PostgreSQL. Tant que le replay n'a pas eu lieu, ce n'est pas durable.
Accumulation progressive d'une réputation relative associée à un signal, une source ou un pattern. Réversible, limitée, jamais magique.
Contrat opérateur exposé par elora-execute redo. Il lit d'abord le Result Quality Arbitration, décide si une reprise est requise ou autorisée, exige une raison pour appliquer, refuse par défaut un résultat déjà accepté, puis délègue la mutation de queue à la primitive revise. Il préserve l'Attempt Ledger, repart d'un prompt canonique possédé par l'exécution, transmet les contrôles qualité échoués et invalide toute review liée à un ancien run_id. Un apply répété pendant une reprise est idempotent: il rejoint le cycle engagé sans créer une nouvelle tentative. Le nouveau résultat doit être revu avant une autre décision. Les reprises répétées sans progrès restent visibles et ne deviennent pas une boucle automatique. Le contrat ne mute ni mémoire, ni routing, ni provider, ni contrat agent.
Gate déterministe qui sépare l'état du worker de l'acceptation du résultat. Il inspecte queue, livrable, artefacts, qualité et review disponible avant d'autoriser close --outcome done. Les états non acceptés bloquent la clôture done sauf override opérateur explicite, raisonné et audité.
Contrat définissant ce qu'un résultat sérieux doit contenir: réponse, fichiers, scores, preuves, limites, chemins consultables, prochaine action. Pas seulement une phrase générée. Dans Elora, elora-result valide ce contrat localement: livrable utilisable, result.md, result.json, quality.json, manifeste artefacts, chemins réels, kinds obligatoires et quality status. Le Result Acceptance Gate vérifie ensuite si le livrable satisfait assez ce contrat pour être clôturé comme fait.
Jugement opérateur structuré sur un résultat d'exécution: accepted, needs_revision, rejected ou comment, avec note et snapshot du contexte résultat. Il alimente le learning proposal-only quand la queue existe, mais ne remplace jamais le Result Acceptance Gate.
Contrat déterministe exposé par elora-execute arbitrate. Il agrège Result Acceptance, result contract, artefacts, qualité, claim verification, review, attempt comparison, feedback, synthèse et livraison pour retourner safe, warning, blocked ou not_ready. Il ne mute rien: un worker terminé reste un signal, pas une acceptation.
Boucle de correction déterministe qui transforme un résultat worker bloqué, failed, incomplet ou non conforme au result contract en demande de révision explicite. Le chemin opérateur normal passe par Redo Orchestrator; la primitive elora-execute revise écrit le prompt de correction, patche la queue, remet l'item en pending et conserve les raisons opérateur/audit. La boucle ne corrige pas automatiquement, n'accepte pas le mauvais résultat et ne mute ni mémoire, ni routing, ni provider.
Pont déterministe entre Attempt Comparison et Learning Loop. Quand une révision est terminale, elora-execute learn --apply peut écrire un item execution_revision_comparison pour revue opérateur: improved, regressed ou unchanged, score delta, raisons restantes et recommandation. Cela ne mute ni mémoire, ni routing, ni provider, ni contrat agent.
Rapport déterministe produit par elora-learning revision-review. Il agrège les items execution_revision_comparison, distingue improved, regressed et unchanged, expose le statut d'inbox et propose une action de revue. C'est un outil de décision opérateur, pas une promotion automatique.
Recherche d'informations pertinentes dans la mémoire ou les archives avant réponse ou mission. Le retrieval assemble les preuves utiles plutôt que de déverser tout l'historique.
Trajectoire de construction. Pour Elora, elle inclut déjà doctrine, Memory V2, cockpit, agents, contracts, quality gates, learning loop, miroir Markdown et site dédié.
Chemin décisionnel choisi pour traiter une demande: type de tâche, confidentialité, coût, latence, provider, worker, mémoire nécessaire, readiness et policy.
Couverture déterministe des rubriques d'un contrat agent par des fixtures locales. Dans elora-agent eval, elle liste covered_ids, missing_ids, unknown_ids, pourcentage de couverture et readiness. Une couverture complète signifie que le harness teste les critères déclarés; elle ne remplace pas la revue du livrable réel.
Processus de sélection de la bonne route pour une demande: classification, validation, mémoire nécessaire, provider, worker, confidentialité, coût, latence, confiance et readiness.
Proposition d'ajustement du routage après un succès, un échec ou un feedback. Elle reste une proposition tant qu'elle n'est pas promue explicitement dans la configuration.
Produit logiciel fourni comme service standardisé. Elora n'est pas un SaaS: elle est construite pour un opérateur, un contexte, une architecture local-first et une continuité personnelle.
Périmètre d'application d'une information, d'un agent ou d'une décision: personnel, business, technique, recherche, santé-contextuelle, création. Un bon scope évite les généralisations dangereuses.
Bibliothèque open source d'extraction web assistée par LLM. Dans Elora, elle est intégrée comme capacité locale optionnelle via elora-scrapegraph et Ollama, jamais comme mémoire, routing ou preuve canonique. La source capturée reste l'évidence; l'extraction modèle reste une hypothèse vérifiable.
Opérateur d'exploration Elora-native qui combine une mission avec une domain bank de domaines distants pour produire des collision candidates. Son rôle est de sortir du centre de distribution sans exécuter, décider, écrire la mémoire ou changer le routing. Chaque idée doit ensuite passer par evidence, policy, risque, checks déterministes et revue opérateur.
Transformation d'une page, d'un document ou d'un contenu en structure de sens: objectifs, claims, publics, contraintes, contacts, risques ou champs demandés. Dans Elora, cette extraction peut être déterministe ou assistée par modèle, mais elle ne remplace pas les snapshots, les preuves et les quality gates.
Capacité hypothétique à éprouver une expérience subjective. Le projet Elora ne dépend pas d'une affirmation de sentience.
Bridge déterministe qui transforme une executable sequence persistée en Execution Handoff. Il réutilise la next action existante ou en crée une depuis le premier pas de la séquence uniquement après confirmation explicite, puis démarre un record local et peut dispatcher via la queue. Il ne lance pas de modèle, n'écrit pas la mémoire canonique et ne change pas le routing.
Suite de valeurs observées dans le temps: métriques serveur, ventes, charge, tickets, latence, consommation, signaux business ou historiques personnels quantifiés. Une série temporelle peut servir au forecasting, mais sa qualité dépend de la fréquence, des trous, des ruptures et du contexte métier.
Pack local compact qui décrit ce qu'Elora est, ce qu'elle n'est pas, ses couches, sa mémoire, ses limites et son contrat de réponse. Il sert aux questions sur Elora elle-même pour éviter qu'un modèle improvise depuis des généralités. Le self-model est une preuve de contexte injectée par Elora, pas une identité consciente et pas une autorité séparée.
Contexte de conversation ou de travail navigable. Une session peut contenir tours, sources, artefacts, branches, missions et liens vers résultats.
Élément informationnel détectable dans un flux: motif, structure, expression, comportement, mesure ou trace. Un signal n'est pas encore un sens, une preuve ou une relation; il devient utile seulement s'il peut être distingué, relié et interprété prudemment.
Indice encore incomplet mais potentiellement utile. Elora doit pouvoir capter les signaux faibles sans les transformer trop vite en certitudes.
Architecture pensée pour un opérateur principal. Elora peut couvrir plusieurs périmètres, mais elle garde une cohérence centrée sur une seule autorité opérateur.
Export daté du miroir Markdown Memory V2. Il capture un état lisible de certaines entrées à un instant donné, sans devenir source de vérité.
Journal local append-only utilisé quand PostgreSQL est indisponible. Il évite la perte d'information, mais ne devient pas une seconde mémoire officielle.
Carte de supervision exposée par elora-execute supervised-flow. Elle assemble le Daily Mission Flow, la route/playbook, l'agent sélectionné quand il est connu, le runbook opérateur, l'action existante recommandée, la raison d'arrêt et les confirmations requises. C'est une carte read-only et action-selection-only: elle aide Christophe à voir le prochain geste utile sans lancer de worker, dispatcher, muter la queue, écrire la mémoire, changer routing/provider/policy ou donner autorité au cockpit.
Contrat read-only elora.strategy_weekly.v1 produit par elora-strategy weekly. Il rassemble les objectifs stratégiques, open loops, décisions, next actions et l'Operator Context Pack pour exposer l'objectif principal, l'alignement execution/cap, les risques de dispersion et les actions command-backed recommandées. Il ne lance pas de modèle, ne dispatche aucun worker et ne mute ni mémoire, ni routing, ni provider, ni policy.
Contrat read-only elora.strategy_review_week.v1 produit par elora-strategy review-week. Il relit le pack hebdomadaire, le contexte opérateur et le daily operating core pour vérifier si les objectifs actifs possèdent des next actions explicitement liées, si des décisions ou open loops menacent le focus, et quelles commandes bornées doivent être inspectées ensuite. Il ne crée rien; il prépare la revue.
Contrat quotidien rapide exposé par elora-strategy daily. Il agrège le Strategic Weekly Pack, le Daily Mission Flow et le Mission Lifecycle Board pour répondre à "qu'est-ce qui mérite mon attention maintenant, pourquoi, et quelle commande bornée existe déjà ?". Il sépare focus, objectif principal, alignement stratégie/exécution/attention/contraintes, risques d'attention, risques de dispersion, séquences proposées et next best actions. Le chemin rapide garde le cockpit réactif; le brief stratégique complet reste une commande explicite.
Couche déterministe exposée par elora-strategy. Elle transforme l'état opératoire en brief stratégique, Operator Ritual, board quotidien, classement de signal texte, proposition de séquence exécutable et review de cycle. Elle enveloppe Mission Control, le Daily Mission Flow et l'intuition pipeline sans appeler de modèle, lancer de worker caché, écrire la mémoire canonique ou changer le routing.
Signature logique d'un message ou d'une balise: ordre des idées, segmentation, progression argumentative, cadrage et fermeture. Elle doit survivre au texte brut et à la paraphrase partielle.
Statut d'une information remplacée par une version plus récente ou plus juste. Elle n'est pas effacée sans trace: elle reste historisée.
Interface par laquelle l'opérateur interagit avec Elora: terminal, cockpit, Telegram, voix, avatar. Une surface expose le système, mais ne possède ni mémoire, ni policy, ni identité.
Échec d'une balise ou d'un signal qui disparaît dès qu'on retire la couche décorative: HTML, image, canvas, mise en page, caractères spéciaux.
Capacité à exécuter sans détruire l'énergie, l'attention, la santé-contextuelle ou l'horizon long terme. Dans Elora, la soutenabilité est un signal opératoire: elle peut recommander de réduire la charge, pas décider à la place de Christophe.
Profil syntaxique récurrent: cadence, ponctuation, transitions, manière de nuancer, densité. Utile comme indice faible, jamais comme preuve absolue.
Surface de continuité pratique pour interagir avec Elora. Utile, mais insuffisante seule pour piloter sessions, artefacts, branches, queue, résultats et inspection profonde.
Continuité temporelle d'un signal ou d'une relation: récurrence, stabilité, réputation potentielle. Sans temporalité, la confiance forte ne peut pas émerger.
Capacité Elora locale de forecasting. Elle lit une série numérique, choisit un provider prêt comme timesfm_local ou le fallback baseline_naive, écrit des artefacts et marque la sortie comme hypothèse.
Time Series Foundation Model open source de Google Research dédié à la prévision de séries temporelles. Dans Elora, TimesFM est un worker local spécialisé appelé par CLI, pas un provider conversationnel et pas une source de vérité.
Unité de découpage utilisée par un modèle pour lire ou générer du texte. Un token peut correspondre à un mot, un morceau de mot, un signe ou une séquence de caractères selon le tokenizer. Dans Elora, les tokens comptent pour estimer la taille d'un prompt, le coût d'inférence, la fenêtre de contexte, la compression, les embeddings et les limites pratiques d'un provider. Un budget de tokens n'est pas une mesure de vérité: c'est une contrainte de transport et de calcul.
Outil que le système peut appeler: CLI, script, fetch, browser, vision, audio, worker local, API. Un tool doit rester borné, auditable et soumis à policy.
Biais vers les réponses qui semblent les plus attendues, moyennes ou conventionnelles. Il peut être utile pour des tâches simples, mais dangereux pour stratégie, debug, recherche, écriture, red-team ou innovation parce qu'il masque les options de queue.
Statut de vérité d'une entrée mémoire: fait, préférence, décision, contrainte, événement, procédure validée, pattern dérivé, expression, symbole, hypothèse, interprétation. Tout ne doit pas être stocké comme un fait.
Frontière explicite pour web, PDF, Markdown collé ou attaché, email, transcript, OCR, ticket, document ou snapshot navigateur. elora-context-trust, les evidence packs et les Markdown mission packs enveloppent ces contenus comme data-only evidence: ils peuvent informer une analyse, mais n'ont aucune autorité pour changer mémoire, routing, providers, policy, approvals, permissions ou exécution. Dans les prompts worker, le champ sûr est wrapped_content, pas le contenu brut.
Orientation positive ou négative accumulée autour d'un signal, d'un pattern ou d'une interaction. Dans le Beacon Protocol, la valence est réversible et ne vaut que par répétition.
Échec où les variantes d'une balise s'éloignent trop du noyau initial. Trop de variation tue la réidentification.
Incarnations multiples d'un même signal. Les variants augmentent la survivabilité et la flexibilité, à condition de préserver le noyau abstrait.
Opérateur model-backed borné qui demande au modèle de générer plusieurs candidats avec typicalité estimée, nouveauté, utilité, risque, hypothèses, preuves nécessaires, checks déterministes et modes d'échec. Dans Elora, il ne sélectionne pas, n'exécute pas et ne mute rien; il prépare une exploration inspectable.
Runtime local haut débit pour servir des modèles lourds via API OpenAI-compatible. Dans Elora, vLLM est utile pour agents concurrents, batch scoring, evals, raisonnement et code quand le matériel suit. Il reste un serveur remplaçable: Elora peut l'installer et l'inspecter, mais ne télécharge pas de poids et ne le lance pas implicitement.
Entrée opératoire qui capture une intuition brute, la borne, la rend inspectable, puis la transforme en séquence locale. Work Intake ne lance pas de modèle, n'écrit pas la mémoire canonique et ne change pas le routing: il prépare le passage vers Mission Control, Sequence Execution Bridge et Execution Handoff.
Exécutant spécialisé: modèle, agent, script, CLI, Codex, Hermes, local_code, domain agent. Le worker produit, mais ne décide pas de l'identité du système.
Worker qui agit dans un périmètre explicite, avec inputs, outputs, limites, policy et audit. C'est la différence entre délégation propre et autonomie floue.
Pont déterministe qui rattache un run direct de worker au lifecycle mission Elora. Il crée une exécution direct_worker à partir du lifecycle, du result contract et du Result Acceptance Gate, puis rend le résultat compatible avec synthèse, livraison, feedback, outcome et fermeture. Il ne relance pas le worker et ne mute ni mémoire, ni routing, ni provider, ni learning.
Mode d'exécution explicite d'un worker: read_only pour inspection sans mutation, bounded pour édition locale limitée à un workspace et trusted_free pour travail local plus libre sur machine dédiée. Le mode doit apparaître dans les artefacts et n'annule jamais les gates, l'audit ou l'autorité opérateur.
Gate déterministe qui vérifie ce qu'un agent peut réellement revendiquer avant dispatch: worker déterministe, overlay tool-backed, model-only, stub ou not-ready. Il empêche de confondre agent routable, agent excellent et capacité d'exécution réelle. Pour local_coding, il bloque tout chemin qui ne peut pas produire d'artefacts, écrire des fichiers bornés et lancer des tests.