Políticas de execução
Retry · timeout · cancelamento
Orion Core · Arquitetura
A arquitetura por trás do Orion Core.
O Orion Core é um produto desenvolvido pela Orion Impact para compor e operar capacidades de IA sob fronteiras explícitas. Sua arquitetura local-first separa contratos, orquestração, integração com providers e controle de execução para que o sistema possa evoluir sem ficar amarrado a um modelo, serviço ou topologia de deployment específica.
O Core já possui runtime operacional, ingestão, retrieval, RAG, memória conversacional, observabilidade e composição substituível de capacidades. Está em pré-lançamento: algumas fundações estão consolidadas, enquanto retrieval e RAG permanecem em evolução ativa.
Estado público do Orion Core
- ORION CORE
- Pré-lançamento
- Versão atual
- 0.1.0
- Arquitetura
- Local-first · Ports & Adapters
- Licença
- Apache-2.0
01 — O que é
Infraestrutura operacional local-first.
O Orion Core é um produto de infraestrutura em pré-lançamento, não um aplicativo para o usuário final nem uma vertical. Ele separa contratos, orquestração de casos de uso, integração com providers e controle de execução entre fronteiras explícitas. A experiência de usuário pertence a uma camada diferente. O Core já expõe hoje uma API HTTP de transporte, mas sua superfície técnica continua em evolução.
02 — Arquitetura
Uma arquitetura, dois fluxos diferentes.
A direção de dependência protege o núcleo contra detalhes externos. O caminho de execução mostra como uma intenção entra pelo transporte e alcança uma capacidade concreta. Os dois fluxos não são a mesma coisa.
Dependência
Quem pode conhecer quem.
Infrastructure → Adapters → Application → Core. Essa direção é a fronteira oficial do projeto e já é protegida por verificações de dependência no código.
-
Infrastructure
Constrói e conecta implementações concretas, executa bootstrap e mantém os mecanismos operacionais. Composition vive aqui: DIContainer, UseCaseFactory, Plugin bootstrap e o registro de capacidades.
-
Adapters
Implementam Ports e traduzem tecnologias concretas para os contratos do Core.
-
Application
Define intenção e orquestra casos de uso exclusivamente através dos contratos do Core. Não seleciona provider.
-
Core
O centro protegido. Define os contratos fundamentais e os modelos operacionais sem depender de frameworks, bancos ou providers.
Fora das fronteiras internas
Providers são detalhes substituíveis.
- LLM providers
- Embedding services
- Vector stores
- Rerankers
- Persistence backends
- Telemetry
Eles não fazem parte da identidade arquitetural do Core. Entram pelo Adapter, depois de um Port, e podem ser trocados sem reescrever o núcleo.
03 — Execução
Como uma intenção vira execução.
O trabalho atravessa o sistema em outro eixo. O Execution Runtime não é um degrau entre Adapter e Provider: envolve a operação inteira.
- HTTP Request
Uma intenção chega pela borda de transporte.
- Transport
Valida o pedido, monta o command e devolve a resposta serializada.
- Command / Use Case
A Application declara o que deve acontecer e sob quais policies.
- Core Port
O contrato estável pelo qual a intenção deixa o núcleo.
- Adapter
Traduz o contrato para uma tecnologia concreta.
- Provider / Store
A capacidade externa ou o backend de persistência que executa o detalhe.
04 — Execution Runtime
Intenção e execução são responsabilidades diferentes.
A Application declara o que o sistema deve fazer. O contrato do Runtime vive no Core; a implementação concreta vive na Infrastructure. Adapters não deveriam reinventar retry, timeout e concorrência — o Runtime é a autoridade para essas policies.
Isso separa a decisão de negócio do controle operacional. Um caso de uso pode pedir um trabalho durável; o Runtime decide como esse trabalho sobrevive a falha, espera, cancelamento e limite de recurso.
Trabalho durável
Jobs · filas · leases
Workers
Execução concorrente
Agendamento
Trabalho adiado e recorrente
Recuperação
Reconciliação · checkpoints
Controle operacional
Backpressure · limites de recursos
Sinais
Eventos · trilha de auditoria · tracing
05 — Capability System
Providers são capacidades resolvidas, não dependências fixas.
Plugins declaram capabilities. O Capability Registry é a autoridade de seleção. A composição constrói e injeta. A Application não escolhe o provider; o provider não se torna a identidade do Core.
- Registro de plugin
Uma implementação se declara como capacidade disponível.
- Capability Registry
Centraliza a seleção. Saúde e prioridade entram na política; o algoritmo fino permanece na documentação técnica.
- Seleção
Uma capacidade concreta é escolhida sem vazar essa decisão para o núcleo.
- DIContainer
A Infrastructure compõe e injeta a implementação escolhida.
- Port / Adapter
O resto do sistema continua falando com um contrato, não com um fornecedor.
06 — Capacidades cognitivas
O que o Core já executa.
Os caminhos existem. A qualidade de retrieval e RAG continua em evolução e avaliação.
Ingestão
DisponívelDocument sources · Eligibility · Processing · Chunking · Embeddings · Indexing · Jobs / backpressure
Retrieval & RAG
Em evoluçãoSemantic retrieval · Hybrid path · Reranking · Query context · Answerability · Context assembly · Evidence return. O fluxo inclui contextualização opcional, geração e registro em memória. Funciona; não está finalizado.
Memória conversacional
DisponívelMemoryPort · ConversationStorePort · session scope · in-memory · SQLite/WAL. O backend conversacional já pode ser durável.
Observabilidade
DisponívelMetrics · Correlation · Tracing · Audit · Runtime events. Há sinal operacional; isso não promete reconstrução perfeita de absolutamente tudo.
- IngestãoDisponível
- RuntimeDisponível
- MemóriaDisponível
- Retrieval / RAGEm evolução
- IdentidadePróximo
07 — Limites
O que o Orion Core ainda não é.
Não é um aplicativo para usuário final.
O Core expõe uma API técnica; experiência de usuário pertence a outra camada.
Identidade não está concluída.
A fronteira está planejada e marcada como próximo passo. Não é apresentada como existente.
Retrieval e RAG não estão finalizados.
Funcionam, mas permanecem em evolução. Não são estado da arte nem “RAG avançado”.
Não é uma distribuição fechada em um único provider.
Providers continuam substituíveis. Tampouco é uma vertical: aplicações especializadas pertencem a camadas futuras.
08 — Princípios em engenharia
Princípios transformados em arquitetura.
Estes compromissos de engenharia derivam dos princípios institucionais da Orion Impact.
09 — Continuar
A arquitetura explica como. O Manifesto explica por quê.
Aprofunde a tese por trás desta arquitetura no Manifesto ou acompanhe o desenvolvimento para o estado verificável do que existe hoje e da direção em que o produto evolui.