brain@elora:~$architecture
menu
VisionPersonaArchitectureMemoryAgentsCockpitJournalResearchFAQ

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, séparent les projets et évitent que le contexte utile soit perdu.

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.

05_worker_provider

Provider / worker

Ollama local, Codex, Hermes, local_code, CLI workers et domain agents exécutent dans leurs bornes. Ils sont remplaçables et ne deviennent pas Elora.

06_result_contract

Result contract

Un résultat sérieux produit réponse, fichiers, scores, preuves, limites, chemins consultables et prochaine action, pas seulement une phrase générée.

07_audit_learning

Audit / proposals

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

Pages satellites: les détails stables doivent vivre dans des pages dédiées quand ils deviennent utiles: Memory V2, cycle mémoire, providers/workers, persona, agents, cockpit, puis plus tard routing/policy et result contracts.

Local model path

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

Connected specialists

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

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.

brain@elora:~$ route mission
input -> classification -> validation -> normalization
      -> canonical_context -> runtime.evidence
      -> worker/provider -> result contract
      -> audit -> learning proposals