Como o VibeBI funciona.

1 · Visão geral

O VibeBI é uma plataforma empresarial de analytics on-premise que transforma um armazém em bruto num serviço de BI governado e self-service. Assenta em três superfícies de produto que partilham contratos mas mantêm as responsabilidades separadas:

• VibeBI Desktop — a superfície de power-user e de administração: BI Agent (relatórios), DG Agent (governação de dados), Explorer, Store, ecrãs de certificação e de acessos.
• VibeBI Web — uma superfície de consumo leve, só de leitura, para descobrir e abrir ligações de partilha de relatórios governados.
• VibeBI Server — o plano de controlo on-prem sem interface: identidade, controlo de acessos, repositório de relatórios, agendamento, auditoria, broker do armazém e gateway LLM.

O VibeBI segue com o seu próprio motor de agentes embutido. O agente faz a maior parte da redação; os administradores de dados humanos e os depositários de TI aprovam e executam através de portões de certificação — nunca são o gargalo.

2 · Arquitetura

A plataforma separa o runtime do agente (no portátil do utilizador) do plano de controlo (servidor on-prem). As credenciais do armazém e do LLM nunca chegam aos dispositivos dos utilizadores finais.

flowchart LR
  subgraph client["User laptop"]
    DT["VibeBI Desktop"]
    SC["Agent sidecar :4580
VibeBI agent engine"]
    DT --> SC
  end
  subgraph server["On-prem server :8080"]
    AUTH["Auth / SSO"]
    BRK["Warehouse broker
read-only SQL"]
    GW["LLM gateway"]
    STORE["Report store
Postgres + object store"]
    ACL["Access control"]
  end
  CH[("Warehouse (EDW)
bronze · silver · gold")]
  WEB["VibeBI Web viewer"]
  SC --> AUTH
  SC --> BRK
  SC --> GW
  BRK --> CH
  DT --> STORE
  WEB --> AUTH
  WEB --> STORE
  STORE --> ACL
            

3 · The Alchemist (medallion)

O âmbito do VibeBI começa no bronze — após a ingestão. Promove os dados através de um medallion governado: bronze → silver → gold + semântica. A única regra rígida: o gold nunca é construído diretamente a partir do bronze; as views silver certificadas têm de existir primeiro.

flowchart LR
  B["Bronze
source-shaped landing
source__entity"] --> S["Silver
silver_<domain>
conformed views"]
  S --> G["Gold
gold_<domain>
facts & dims"]
  G --> SEM["Semantics
entities · grain · tags"]
  SEM --> CR["Create / Web
published gold only"]
            

A Fase 1 (Bronze → Silver) cobre perfilagem, análise de qualidade de dados, conformação e propostas de domínio/classificação. A Fase 2 (Silver → Gold) cobre resolução de entidades, redação de manifests e views gold, validação e ciclos de reparação. Os nomes físicos das bases de dados são configuração de implementação, não estão fixos nos binários.

4 · Camada semântica

A camada semântica é o que torna os relatórios duradouros. Em vez de ligar dashboards a tabelas físicas, o VibeBI expõe entidades, granularidades, mapeamentos, métricas certificadas e metadados de modelos gold através de um único contrato.

• Métricas certificadas — medidas aprovadas pelo administrador de dados, com expressão, granularidade e ligação gold. Uma definição, reutilizada em todo o lado.
• Glossário de negócio — termos com âmbito Empresa / Equipa / Pessoal, com definições e alias, injetados nas sessões do agente.
• Etiquetas de campo — cada campo exposto tem ≥ 1 domínio de dados e um nível de classificação.

Como os relatórios leem a camada semântica, uma alteração de esquema a montante é absorvida no mapeamento silver→gold — os relatórios a jusante continuam a funcionar sem reescrita.

# Agent discovery contract
GetSemantics      # entities, tables, grains, mappings, certified metrics
QueryVibeBIGold  # read-only SQL against published gold for real answers

5 · Gold BI learning (ciclo de auto-crescimento)

O gold não é uma publicação de uma só vez. O VibeBI captura sinais de procura de cada turno do agente de BI — perguntas de utilizadores, métricas esparsas/nulas de sondas em tempo real, erros de consulta, falhas de join e entidades a que o assistente não conseguiu responder — e transforma-os em melhorias revistas pelo administrador de dados nos business drivers, manifests e joins.

flowchart LR
  BI["BI Agent turns
chat + gold/silver probes"] --> SIG["Learning signals
catalog backlog"]
  SIG --> PROC["Process backlog
drivers · joins · hints"]
  PROC --> STW["Steward review
Gold → BI Learning tab"]
  STW --> GOLD["Approve drivers
publish manifests · build gold"]
  GOLD --> SEM["Updated semantics
fewer gaps next turn"]
  SEM --> BI
            

Os administradores de dados mantêm o controlo. As propostas criam bi_learning business drivers em proposto até aprovação. As reconstruções de manifest para métricas esparsas regressam a rascunho até nova publicação. Os administradores de dados podem processar passo a passo ou executar um pipeline completo (processar → aprovar → publicar → construir gold) a partir do ambiente de trabalho.

O agente de BI recebe uma secção compacta de lacunas de aprendizagem nos turnos seguintes (medidas esparsas, entidades por cobrir, drivers pendentes) para responder com honestidade em vez de voltar a sondar colunas conhecidas como nulas. O DG Agent usa o mesmo backlog ao regenerar business drivers.

6 · Motor de agentes

O VibeBI corre um runtime de agente embutido, feito de propósito — não um chatbot genérico. Dois papéis de agente impulsionam o produto:

7 · Modelo de governação

O controlo de acessos utiliza dois planos ortogonais, definidos pelo cliente e aplicados em cada campo, consulta, relatório e partilha.

Plano A — Domínios de dados (tema de negócio)

Áreas temáticas detidas pelo negócio (Receita, Cadeia de abastecimento, Compensação de RH), com subdomínios opcionais. Cada domínio tem um proprietário que aprova os pedidos de acesso — a parte responsável do negócio, não o construtor técnico da tabela.

Plano B — Níveis de sensibilidade

Papéis (RACI)

• Proprietário do domínio de dados — quem pode aceder a um domínio; aprova pedidos de acesso; coassina publicações sensíveis.
• Administrador de dados — o que os dados significam: definições, granularidade, métricas, aprovação de manifests, certificação DQ, e gold BI learning (processar sinais de chat → aprovar drivers → publicar gold).
• Depositário de dados (TI) — como os pipelines correm: execução de DDL, desempenho, backups, break-glass.

8 · Acesso derivado a relatórios

Esta é a regra nuclear de acesso, e não tem bypass:

As concessões ao nível do relatório (papéis, ligações de partilha) só podem restringir o acesso — nunca o alargar para além das autorizações de dados subjacentes. Um modelo gold construído a partir de várias tabelas silver herda a união das suas etiquetas de domínio, pelo que os proprietários de todos os domínios herdados se tornam os aprovadores.

9 · Implementação

100% on-premise é a nossa vantagem — o VibeBI corre inteiramente dentro da sua rede, com credenciais do armazém e chaves de modelo que nunca a abandonam. O piloto é uma instalação Docker Compose numa única VM; a produção reforça-se para um cluster HA sem redesenhar o produto.

On-premise é a predefinição, não a única opção. A mesma arquitetura implementa-se na cloud à sua escolha — pública, privada, híbrida ou multi-cloud — para que possa colocar o plano de controlo e o armazém de dados onde a sua estratégia de residência de dados e de operações o exigir.

O servidor é intencionalmente leve — um binário leve que corre confortavelmente em hardware comum. Toda a computação agentic — perfilagem, extração semântica, geração de modelos, redação de relatórios — corre distribuída no cliente de ambiente de trabalho de cada utilizador, não no servidor. O servidor trata apenas da governação, da intermediação e da disponibilização, pelo que os requisitos de recursos do lado do servidor se mantêm mínimos mesmo à medida que a base de utilizadores cresce.

Para clientes sensíveis a dados, o VibeBI suporta uma implementação totalmente air-gapped: 100% on-premise, sem qualquer dependência da internet, a correr contra um LLM interno. Nenhum dado, nenhuma consulta e nenhum metadado saem alguma vez da sua rede. O sistema inteiro — servidor, cliente de ambiente de trabalho e LLM — opera como um circuito fechado dentro do seu perímetro.

• Os agentes de criação correm nos portáteis dos utilizadores (~100 criadores em simultâneo).
• O visualizador web serve consumidores ocasionais em PC e telemóvel (~500 em simultâneo).
• A produção envia artefactos compilados — sem código-fonte nas imagens de runtime, sem source maps em produção.
• Os relatórios são armazenados como .report.ts + HTML gerado, renderizado através de APIs com ACL.

10 · Invariantes de segurança

Cinco não negociáveis mantêm-se em todas as implementações:

1. Credenciais do armazém nunca nos dispositivos cliente — todo o fluxo gold/semântica passa pelo broker do servidor.
2. Chaves LLM nunca nos dispositivos cliente — apenas gateway do servidor ou tokens emitidos de curta duração.
3. As ligações de partilha são URLs de capacidade — id opaco + SSO/ACL + token de renderização de curta duração, não caminhos HTML estáticos.
4. O acesso a relatórios deriva das autorizações de dados — nenhuma permissão isolada de relatório pode contornar as concessões de domínio + classificação.
5. A produção implementa artefactos compilados — sem src/ nas imagens de runtime.

11 · Stack tecnológica