Seu dado fica local
Fila, índice, representação do conteúdo e geração rodam dentro da estrutura do cliente. Nada sensível precisa sair do ambiente.
ORION Core · Arquitetura
A arquitetura por trás do Orion Core.
O Orion Core é o motor de IA que roda dentro da estrutura da própria organização: recebe documentos, entende perguntas e responde a partir deles — sem que dados sensíveis saiam do ambiente do cliente.
Esta página mostra a arquitetura por dentro e, camada por camada, o que já funciona hoje. O núcleo é funcional em ambiente de testes; a interface é o próximo passo.
Núcleo funcional em ambiente de testes · TRL 4
Hoje o núcleo é exercitado por testes automatizados de código, ainda sem interface para o usuário final. Ao longo desta página, o que está construído e o que é o próximo passo aparecem marcados.
O que isso garante
Engenharia que vira garantia.
Antes da arquitetura por dentro, o que ela significa na prática para quem usa.
Nada se perde em falha
Cada etapa tem estado registrado e pode ser retomada, reprocessada ou reexecutada. Uma queda no meio vira etapa recuperável, não trabalho perdido.
Toda resposta vem com suas fontes
O motor devolve, junto da resposta, os trechos e o documento de origem que usou para respondê-la.
Rastreável de ponta a ponta
Cada mudança relevante é registrada como evento, com trilha de auditoria em runtime e métricas. O caminho do documento até a resposta pode ser reconstruído.
Arquitetura em camadas
Do pedido na borda ao dado local, uma camada por vez.
Um pedido entra pela borda e desce para dentro: validado, decidido no núcleo de regras, executado pelo runtime, processado pelos pipelines cognitivos e servido por dados local-first. As dependências apontam para dentro — cada camada acima existe para servir o núcleo.
-
1Borda e entradaFuncional
Onde documentos e perguntas chegam. O pedido é validado e organizado antes de entrar — a porta de fora do sistema.
-
2Núcleo de regras e contratosFuncional
O coração do domínio: as regras, os contratos e os eventos que definem o que o sistema pode fazer — independente de qualquer tecnologia específica.
-
3Runtime e pipelines cognitivosFuncional
O motor que mantém o trabalho em execução: eventos, filas, recuperação de falhas e os pipelines que transformam documentos em respostas.
-
4Dados local-firstFuncional
Índices, registros e memória operacional guardados na estrutura do cliente, próximos de onde o dado nasce.
Modelos e componentes se conectam por adaptadores trocáveis: trocar um modelo de linguagem ou um mecanismo de busca não exige reescrever o núcleo.
Runtime
Um runtime persistente, não um sistema que responde e esquece.
Estados explícitos e recuperáveis
O trabalho é modelado com estados registrados; se algo falha no meio do caminho, o runtime sabe exatamente onde parou.
Por que importa: nenhuma ingestão ou consulta se perde por causa de uma queda.
Modelo de eventos
Cada mudança relevante — um documento ingerido, um pipeline avançando, um job concluído — é registrada como um evento.
Por que importa: é isso que permite reconstruir de qual documento veio cada resposta.
Jobs e workers persistentes
Trabalho pesado e de longa duração roda em segundo plano, desacoplado de qualquer requisição individual.
Por que importa: processar uma base grande não trava o uso nem depende de alguém observando.
Do documento à resposta
Como uma pergunta vira uma resposta com fonte.
DocumentoEntrada controlada de arquivos e conteúdo institucional.
PreparoExtração, limpeza e organização do conteúdo em unidades de significado.
Busca por significadoRepresentação do conteúdo para localizar trechos por sentido, não só por palavra exata.
Busca combinadaSemântica e literal juntas, com reordenação dos trechos mais relevantes.
Montagem do contextoAs evidências mais fortes reunidas para embasar a resposta.
Resposta com fonteGeração final que devolve a resposta junto dos trechos e do documento de origem.
Este é um pipeline entre vários que o runtime pode executar — cada um uma sequência de estados, eventos e etapas recuperáveis.
Não buscamos construir apenas mais uma interface de IA. Buscamos construir o runtime por trás dela.
Por que nessa ordem
O núcleo primeiro. As camadas seguintes, na ordem certa.
Construímos primeiro o núcleo — a parte difícil e invisível, já funcional em testes. A partir dele, a engenharia avança em camadas, cada uma preparando a próxima.
-
1Autenticação e autorizaçãoPróximo passo
Controle de quem acessa o quê. É o pré-requisito para qualquer uso real por um cliente.
-
2Memória operacional persistenteNa sequência
Memória por sessão e por cliente — e é ela que traz o isolamento entre clientes, cada um com seus próprios dados.
-
3Interface e verticaisDepois
A camada de produto para saúde, jurídico e setor público — o que dá rosto ao núcleo.
Adiar interface e verticais foi deliberado: uma base madura evita reconstruir a fundação a cada novo caso de uso.
Próximos passos
Veja para onde a engenharia vai — ou coloque o Core à prova.
Para a tese e os compromissos por trás desta arquitetura, veja o Manifesto e os Princípios.