Wie VibeBI funktioniert.

1 · Überblick

VibeBI ist eine On-Premise-Enterprise-Analytics-Plattform, die ein Roh-Warehouse in einen governance-gesteuerten Self-Service-BI-Dienst verwandelt. Sie basiert auf drei Produktoberflächen, die Verträge teilen, Verantwortlichkeiten aber trennen:

• VibeBI Desktop — die Power-User- und Administrationsoberfläche: BI Agent (Berichte), DG Agent (Data Governance), Explorer, Store, Zertifizierungs- und Zugriffsansichten.
• VibeBI Web — eine schlanke, schreibgeschützte Nutzeroberfläche zum Entdecken und Öffnen von Share-Links für governance-gesteuerte Berichte.
• VibeBI Server — die headless On-Prem-Control-Plane: Identität, Zugriffskontrolle, Report Store, Scheduling, Audit, Warehouse-Broker und LLM-Gateway.

VibeBI wird mit einer eigenen eingebetteten Agent-Engine ausgeliefert. Der Agent übernimmt den Großteil des Entwurfs; menschliche Stewards und IT-Custodians geben frei und führen über Zertifizierungsgates aus — sie sind nie der Engpass.

2 · Architektur

Die Plattform trennt die Agent-Runtime (auf dem Laptop des Nutzers) von der Control Plane (On-Prem-Server). Warehouse- und LLM-Credentials erreichen niemals Endnutzergeräte.

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 · Der Alchemist (Medaillon)

Der Umfang von VibeBI beginnt bei Bronze — nach der Ingestion. Die Daten werden durch ein governance-gesteuertes Medaillon geführt: Bronze → Silber → Gold + Semantik. Die eine harte Regel: Gold wird nie direkt aus Bronze gebaut; zertifizierte Silber-Views müssen zuerst existieren.

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"]
            

Stufe 1 (Bronze → Silber) umfasst Profiling, Datenqualitätsanalyse, Konformation und Domänen-/Klassifizierungsvorschläge. Stufe 2 (Silber → Gold) umfasst Entity Resolution, Manifest- und Gold-View-Entwurf, Validierung und Repair-Loops. Physische Datenbanknamen sind Deployment-Konfiguration, nicht in Binaries fest verdrahtet.

4 · Semantikschicht

Die Semantikschicht macht Berichte langlebig. Statt Dashboards an physische Tabellen zu binden, stellt VibeBI Entitäten, Granularitäten, Mappings, zertifizierte Kennzahlen und Gold-Modell-Metadaten über einen einzigen Vertrag.

• Zertifizierte Kennzahlen — steward-freigegebene Measures mit Expression, Granularität und Gold-Bindung. Eine Definition, überall wiederverwendet.
• Business-Glossar — unternehmens-, team- und persönlich abgegrenzte Begriffe mit Definitionen und Aliassen, die in Agent-Sitzungen eingespeist werden.
• Feld-Tags — jedes exponierte Feld trägt ≥ 1 Datendomäne und eine Klassifizierungsstufe.

Weil Berichte die Semantikschicht lesen, wird eine Upstream-Schemaänderung im Mapping Silber→Gold aufgefangen — nachgelagerte Berichte laufen ohne Neuschreiben weiter.

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

5 · Gold-BI-Learning (Self-Grow-Loop)

Gold ist keine einmalige Veröffentlichung. VibeBI erfasst Nachfragesignale aus jedem BI-Agent-Turn — Nutzerfragen, spärliche/leere Kennzahlen aus Live-Probes, Abfragefehler, Join-Lücken und Entitäten, die der Assistent nicht beantworten konnte — und macht daraus steward-geprüfte Verbesserungen an Geschäftstreibern, Manifesten und 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
            

Stewards behalten die Kontrolle. Vorschläge erzeugen bi_learning Geschäftstreiber in vorgeschlagen -Status, bis sie freigegeben sind. Manifest-Rebuilds für spärliche Kennzahlen kehren zurück zu Entwurf bis zur erneuten Veröffentlichung. Stewards können Schritt für Schritt verarbeiten oder eine volle Pipeline (verarbeiten → freigeben → veröffentlichen → Gold bauen) vom Desktop aus.

Der BI-Agent erhält einen kompakten Lernlücken -Abschnitt in späteren Turns (spärliche Measures, ungedeckte Entitäten, ausstehende Treiber), damit ehrlich geantwortet wird, statt bekannte Null-Spalten erneut zu proben. Der DG Agent nutzt denselben Backlog, wenn er Geschäftstreiber neu erzeugt.

6 · Agent-Engine

VibeBI betreibt eine zweckgebundene eingebettete Agent-Runtime — kein allgemeiner Chatbot. Zwei Agent-Rollen treiben das Produkt:

7 · Governance-Modell

Die Zugriffskontrolle nutzt zwei orthogonale Ebenen, vom Kunden definiert und auf jedem Feld, jeder Abfrage, jedem Bericht und jeder Freigabe durchgesetzt.

Ebene A — Datendomänen (Business-Thema)

Business-eigene Themenbereiche (Revenue, Supply Chain, HR Compensation), mit optionalen Subdomänen. Jede Domäne hat einen Owner der Zugriffsanfragen genehmigt — die geschäftlich verantwortliche Partei, nicht der technische Tabellenbauer.

Ebene B — Sensitivitätsstufen

Rollen (RACI)

• Data-Domain-Owner — wer auf eine Domäne zugreifen darf; genehmigt Zugriffsanfragen; gegenzeichnet sensible Veröffentlichungen.
• Data Steward — was Daten bedeuten: Definitionen, Granularität, Kennzahlen, Manifest-Freigabe, DQ-Zertifizierung und Gold-BI-Learning (Chat-Signale verarbeiten → Treiber freigeben → Gold veröffentlichen).
• Data Custodian (IT) — wie Pipelines laufen: DDL-Ausführung, Performance, Backups, Break-Glass.

8 · Abgeleiteter Berichtszugriff

Das ist die zentrale Zugriffsregel, und sie hat keinen Bypass:

Berichtsebene-Freigaben (Rollen, Share-Links) können nur einschränken Zugriff — ihn niemals über die zugrunde liegenden Datenberechtigungen hinaus erweitern. Ein Gold-Modell aus mehreren Silber-Tabellen erbt die Vereinigung ihrer Domänen-Tags, sodass die Eigentümer aller geerbten Domänen zu den Freigebern werden.

9 · Bereitstellung

100 % On-Premise ist unser Vorsprung — VibeBI läuft vollständig in Ihrem Netzwerk, mit Warehouse-Credentials und Modellschlüsseln, die es nie verlassen. Der Pilot ist eine Single-VM-Installation mit Docker Compose; die Produktion härtet ohne Produkt-Redesign zu einem HA-Cluster.

On-Premise ist der Standard, nicht die einzige Option. Dieselbe Architektur wird bereitgestellt in der Cloud Ihrer Wahl — Public, Private, Hybrid oder Multi-Cloud — sodass Sie Control Plane und Warehouse dort platzieren können, wo es Ihre Data-Residency- und Betriebsstrategie erfordert.

Der Server ist bewusst schlank — eine schlanke Binary, die problemlos auf Standardhardware läuft. Die gesamte agentische Rechenlast — Profiling, semantische Extraktion, Modellgenerierung, Berichtsentwurf — läuft verteilt auf dem Desktop-Client jedes Nutzers, nicht auf dem Server. Der Server übernimmt nur Governance, Brokering und Serving, sodass der Server-Ressourcenbedarf auch bei wachsender Nutzerbasis minimal bleibt.

Für datensensible Kunden unterstützt VibeBI ein vollständig air-gapped Deployment: 100 % On-Premise, ohne Internetabhängigkeit, betrieben gegen ein internes LLM. Keine Daten, keine Abfragen und keine Metadaten verlassen jemals Ihr Netzwerk. Das gesamte System — Server, Desktop-Client und LLM — arbeitet als geschlossene Schleife innerhalb Ihres Perimeters.

• Create-Agents laufen auf Nutzer-Laptops (~100 gleichzeitige Ersteller).
• Der Web-Viewer bedient Gelegenheitsnutzer auf PC und Mobil (~500 gleichzeitig).
• Die Produktion liefert kompilierte Artefakte — kein Quellcode in Runtime-Images, keine Source Maps in Produktion.
• Berichte werden gespeichert als .report.ts + generiertes HTML, gerendert über ACL-gesteuerte APIs.

10 · Sicherheitsinvarianten

Fünf nicht verhandelbare Punkte gelten in jedem Deployment:

1. Warehouse-Credentials nie auf Client-Geräten — sämtliches Gold und sämtliche Semantik fließen über den Server-Broker.
2. LLM-Schlüssel nie auf Client-Geräten — ausschließlich Server-Gateway oder kurzlebig ausgestellte Tokens.
3. Share-Links sind Capability-URLs — opake ID + SSO/ACL + kurzlebiger Render-Token, keine statischen HTML-Pfade.
4. Berichtszugriff wird aus Datenberechtigungen abgeleitet — keine eigenständige Berichtsberechtigung kann Domänen- und Klassifizierungsfreigaben umgehen.
5. Die Produktion stellt kompilierte Artefakte bereit — kein src/ in Runtime-Images.

11 · Technologie-Stack