Catalogo de módulos

O Olivares AI e uma plataforma modular: um motor mais um catalogo de módulos de capacidade mais conectores. Um módulo consome eventos normalizados do núcleo, declara as suas entidades no modelo de dados partilhado e expoe a sua própria API e vistas — sem re-arquitetar o resto.

O binário stock liga 29 pacotes de módulos, organizados abaixo em áreas de capacidade numeradas (a tabela agrupa vários pacotes numa única área, e algumas entradas são infraestrutura fundamental ou pos-v1). Leia-o como um catalogo, não como uma lista de verificação de funcionalidades: governar/observar e amplo e ativo em todo o ambiente; a atuação e a parte estreita e bloqueada — cada linha e marcada live, provisionada a pedido (503 até configurada), ou um ponto deny-closed. A plataforma e pre-1.0. Veja Honestidade e limites para como formulamos o que esta e não esta construído.

Além do catalogo numerado há um módulo de suporte live-ingest (numerado XXIV no código): a torneira de eventos ao vivo que os outros módulos leem. E infraestrutura em vez de uma superficie autonoma, portanto não é contado entre o catalogo numerado.

Como ler o estado de cada módulo

Cada módulo tem duas metades, e a distincao honesta entre elas e todo o ponto:

• Governar / Observar — catalogar, observar, comparar, bloquear, reportar. Isto esta construído e ligado hoje para os módulos marcados como live abaixo. O produto e leitura primeiro e detetivo por defeito: observa e governa fora de banda, não se coloca no caminho do pedido.
• Atuar — agir na sua infraestrutura real (implantar, disparar, despachar, enviar, aplicar). Isto é deliberadamente estreito e enquadra-se em três estados:
  • live — ligado no binário predefinido, sem provisionamento necessário.
  • on-demand — o backend esta construído e ligado a um ponto de injeção mas permanece deny-closed até que um operador o provisione via config; até la uma ação aprovada e honestamente “declarada, não atuada” (por exemplo, deploy apply/retire retorna um 503 claro).
  • seam — uma interface declarada, deny-closed, sem backend predefinido ainda.

A divisao e o contrato: o produto observa e governa amplamente, e atua num subconjunto pequeno, maioritariamente bloqueado por provisionamento. Nada aqui afirma execução que o código não faz.

Descoberta e estado ao vivo

Capacidades, identidade e governança

Implantação e stack de modelos

Modelos hospedados não são auto-hospedaveis. O Módulo X pode rotear para Claude (diretamente ou via Bedrock/Vertex/Foundry), mas essa inferência ainda alcança a API do fornecedor. Apenas modelos genuinamente auto-hospedados (vLLM/Ollama) funcionam totalmente offline; air-gap aplica-se ao plano de controlo Olivares, não a inferência hospedada.

Custo, qualidade e conformidade

Segurança e garantia

Coordenação, voz e saída

Plataforma e relatórios

Uma nota transversal: o kill switch

Além de qualquer módulo individual, o kill switch do ambiente liga um portão de paragem a cada ponto de atuação: deploy, orchestration fire, voice open, model execution e budget spend. Uma paragem e aplicação positiva e e deny-closed — um estado de paragem ilegível e tratado como parado, nunca como passa. Veja o tour do kill-switch.

Relacionado

• O que é o Olivares AI? — o produto numa página.
• Permitido vs observado e fidelidade — como os módulos I-III se mantém honestos sobre o que conseguem provar.
• Honestidade e limites — a postura completa live-vs-roadmap.
• Arquitetura — como o motor, camadas e conectores se compoem.