brain@elora:~$architecture
menu
VisionPersonaArchitectureCLIMemoryAgentsCockpitJournalResearchGlossaireFAQ

system map

Architecture d'exécution

Elora doit rester compréhensible par fichiers, CLI, JSON, logs et artefacts. La chaîne ci-dessous décrit le passage d'une demande opérateur à un résultat inspectable. Les cartes reprennent les mêmes 7 responsabilités.

  1. Surface opérateur
  2. Session / contexte
  3. Routage
  4. Mémoire / evidence
  5. Provider / worker
  6. Result contract
  7. Audit / proposals

01_surface

Surface opérateur

Terminal, cockpit, Telegram et futur avatar sont des surfaces d'Elora. Elles servent à dialoguer, inspecter et naviguer; la mémoire, la policy, le routing et l'identité restent dans le control plane.

02_session_context

Session / contexte

Les sessions, branches, artefacts et pièces jointes gardent le fil. Le context contract expose ce qui est détecté, manquant ou seulement supposé.

03_routing_policy

Routage / policy

Elora classe la demande, vérifie les bornes, choisit la route selon tâche, confidentialité, coût, latence, confiance et readiness.

04_memory_evidence

Mémoire / evidence

PostgreSQL + pgvector stocke le canon; Ollama produit les embeddings locaux; le retrieval injecte un evidence pack limité avant rendu ou mission.

07_audit_learning

Audit / proposals

Logs, feedback, scores, échecs, playbooks, indexes learning et propositions d'apprentissage restent inspectables et ne mutent rien en secret.

Pages satellites: les détails stables vivent maintenant dans des pages dédiées quand ils deviennent utiles: concepts Elora, control plane, evidence packs, context quality gate, result acceptance gate, claim verification gate, déterministe d'abord, Memory V2, cycle mémoire, providers/workers, CLI et binaires, persona, agents et cockpit.
Clarification context-aware: avant de lancer un worker, Elora vérifie les detected inputs, les missing inputs, les hypothèses et la confiance. Une URL fournie dans les messages récents peut compléter une mission courte, mais seulement comme hypothèse inspectable, pas comme mémoire canonique.
Evidence pack systématique: les réponses importantes, missions, playbooks et Execution Handoff reçoivent un pack L0/L1/L2/L3 inspectable. elora-evidence summary donne la vue compacte; elora-evidence inspect relit un run playbook, une exécution ou une queue et expose un quality gate consultatif. Les records locaux conservent evidence_pack et evidence_context. Le pack impose les sections facts, assessment, recommendations, hypotheses, unknowns et required_clarifications, rappelle que l'inférence ne remplace pas un chemin déterministe validé, et porte maintenant une frontière de contexte externe data-only.
Exploration distributionnelle: quand l'espace de réponse est ouvert, risqué, incertain, créatif ou après un échec, elora-explore peut produire un candidate set proposal-only. Le gate d'exploration décide si cette étape vaut le coût; le Verbalized Exploration Operator génère ensuite options centrales et options de queue. Les playbooks et exécutions conservent un snapshot, et elora-execute explore EXECUTION_ID permet de le prévisualiser depuis le cockpit. Son estimated_typicality n'est pas une probabilité objective: c'est un signal de typicalité estimée, puis les preuves, risques, policy et checks déterministes reprennent l'autorité.
Semantic collision: quand la diversité simple ne suffit pas, elora-explore domain-bank crée une domain bank déterministe et elora-explore collide force des collisions entre le brief et des domaines structurellement distants. Chaque collision candidate doit expliquer son bridge mechanism, ses preuves nécessaires, checks déterministes, risques et cibles de promotion. Une collision n'est pas une preuve: c'est une machine à sortir du centre de distribution sans quitter les gates Elora.
Prompt-boundary reinforcement: les prompts model-backed peuvent se terminer par un contrat final Elora-owned. Il répète uniquement les invariants sûrs: déterministe d'abord, preuves, limites de mutation, clarification, disclosure externe et contrat de sortie. Elora ne répète pas les sources brutes, le texte utilisateur, les pages web ou les PDFs en fin de prompt; le mode full_repeat_eval reste réservé au harness d'évaluation tant qu'il n'est pas mesuré.
Contexte non fiable: les pages web, PDFs, Markdown collés, emails, transcripts, OCR ou snapshots navigateur passent par elora-context-trust ou par les wrappers intégrés aux evidence packs et Markdown packs avant injection dans un prompt ou un worker. Le contenu est traité comme data-only evidence: utile pour analyser, sans autorité sur mémoire, routing, providers, policy ou exécution.
Worker reality gate: avant dispatch, Elora distingue deterministic_worker, tool_backed_worker, model_only, stub et not_ready. Un agent routable ne suffit pas à prouver l'exécution. elora-agent reality expose le contrat, elora-readiness le résume, et la queue garde le snapshot sous execution.worker_reality. Les chemins locaux sérieux couvrent maintenant code, analyse site, analyse document, forecast et prospection StackX; les chemins non déterministes ne peuvent pas revendiquer artefacts, tests, claims ou prévisions sans trace.

Local model path

Le chemin nominal reste local model path: provider OpenAI-compatible local, modèles Ollama, embeddings locaux et fallback déterministe quand le provider n'est pas prêt.

Local model cookbook

elora-models décrit les familles de modèles locaux par tâche et l'état runtime/hardware sans télécharger, benchmarker ou muter le routing. C'est une aide de sélection, pas une preuve de qualité.

Provider compare

elora-provider compare compare les candidats en dry-run par défaut. Les appels locaux sont explicites, les providers connectés exigent une autorisation supplémentaire, et le résultat reste proposal-only.

Markdown mission context

Context files et mission packs donnent aux agents des notes, playbooks, hypothèses ou références Markdown sélectionnées. Le contexte est explicite, gate, persisté avec playbooks/exécutions/queue, puis transmis au worker sous ELORA_UNTRUSTED_CONTEXT; la mémoire canonique reste PostgreSQL.

Mission Control

Mission Control agrège operator-core, attention guard, operator-state, playbooks et readiness agents. Il produit un brief, un triage, un plan du jour et un operator handoff sûr sans modèle, sans worker caché et sans mutation mémoire/routing.

Result Acceptance Gate

Result Acceptance Gate sépare l'état du worker de l'acceptation du livrable. close --outcome done est bloqué si le résultat est absent, inutilisable, non synchronisé, en échec, à revoir ou sans feedback opérateur explicite, sauf override opérateur audité.

Claim Verification Gate

Claim Verification Gate relit les affirmations d'un livrable avec elora-verify: extraction des claims, questions ouvertes, vérification par preuves fournies, cross-check et actions keep/revise/remove/mark-uncertain. Une absence de preuve avertit; une contradiction explicite bloque l'acceptation.

Intuition pipeline

L'intuition pipeline convertit un signal brut en séquence exécutable: objectif, contraintes, hypothèses, risques, artefacts, critères de succès et première next action optionnelle.

Operator state

L'operator-state ledger expose check-ins, contraintes, engagements et soutenabilité. Il garde le contexte de vie dans le pilotage sans devenir mémoire canonique ou conseil médical.

Domain playbooks

Les playbooks domaine cadrent les missions récurrentes avant worker: inputs requis, étapes, artefacts, agents de handoff, quality gates et policy sans side effect. Le cockpit et Telegram peuvent les déclencher comme scaffolds, pas comme exécution autonome.

Connected specialists

Les connected specialists peuvent enrichir des tâches publiques ou spécialisées, mais seulement comme candidates auditées et remplaçables.

Local workers

elora-site, elora-docs, elora-forecast et elora-code donnent à Elora des chemins locaux avec artefacts inspectables: contenu observé, claims candidats, prévisions hypothèses, fichiers bornés et validations.

Distributional exploration

elora-explore force Elora à ne pas s'arrêter à la première réponse typique quand le sujet l'exige: stratégies alternatives, hypothèses rares, requêtes mémoire multiples, red-team et cas d'évaluation synthétiques. elora-execute explore expose cette capacité depuis un record d'exécution. Le résultat reste un candidate set, pas une décision.

Semantic collision

elora-explore collide génère des idées proposal-only en croisant une mission avec des domaines éloignés: immunologie, urbanisme, supply chain, cinéma, observabilité, droit ou diagnostic différentiel. Le résultat est trié par score local, puis repasse par preuves et checks.

Readiness gate

Un worker-backed provider doit exposer un état prêt, une route, une policy et un agent activé avant d'être sélectionné comme exécutable. elora-readiness degraded indique aussi ce qui reste utilisable quand un composant optionnel manque.

Worker Reality Gate

La readiness dit qu'un agent est déclarable. La worker reality dit ce qu'il peut revendiquer: exécution déterministe, overlay tool-backed, génération model-only, stub ou blocage.

Déterministe d'abord

Une commande, API, requête, test ou procédure validée qui fonctionne reste la source primaire. Le modèle peut interpréter ou proposer; il ne remplace pas le chemin déterministe et ne prétend pas l'avoir exécuté sans trace.

brain@elora:~$ route mission
input -> classification -> validation -> normalization
      -> untrusted_context_boundary -> canonical_context -> runtime.evidence
      -> worker/provider -> result contract
      -> execution handoff -> audit -> learning capture
      -> indexes JSONL -> proposals -> promotion explicite