Kontrollierte Analytics

Datenvertrag binden. Ausführung kontrollieren. Ergebnis erklären.

Controlled Analytics bindet einen Report an exakte DatasetVersion-Objekte, validiert Query Context auf dem Server und bewahrt Berechtigungs-, RLS-, Filter-, Binding- und Artifact-Kontext hinter einem unterstützten Ergebnis.

Controlled Analytics bindet einen Report an exakte DatasetVersion-Objekte, validiert Query Context auf dem Server und bewahrt Berechtigungs-, RLS-, Filter-, Binding- und Artifact-Kontext hinter einem unterstützten Ergebnis.
Datenvertrag binden. Ausführung kontrollieren. Ergebnis erklären. Controlled Analytics bindet einen Report an exakte DatasetVersion-Objekte, validiert Query Context auf dem Server und bewahrt Berechtigungs-, RLS-, Filter-, Binding- und Artifact-Kontext hinter einem unterstützten Ergebnis.
ReportVersion erfasst die analytische Absicht.

Dimensionen, Metriken, Aggregation, Diagramm, persistente Filter, Interaktionen und DatasetVersion-Bindings gehören zu einer unveränderlichen ReportVersion. Runtime-Filter erzeugen einen neuen Run-Kontext, statt die gespeicherte Definition unbemerkt zu ändern.

Der Server verantwortet Kompilierung und RLS.

Der Browser-Query-Context referenziert autorisierte Spalten und Metriken. Das Backend validiert ihn und kompiliert schreibgeschütztes SQL. Runtime- Filter können geschützte RLS-Origin-Metadaten nicht imitieren.

Visualisierungen nutzen einen gemeinsamen Vertrag.

Balken- und horizontale Balkendiagramme, Linien-, Flächen- und Streudiagramme mit optionaler Größe, Kreis- und Ringdiagramme, Tabellen, KPI und Multi-Series-Diagramme verwenden einen gemeinsamen versionierten, rendererneutralen Vertrag. Top N mit deterministischem Other, zeitliche Granularität, Vergleich, Drill, Referenzlinien und barrierefreie Fallback-Darstellung bleiben Teil derselben Spezifikation.

Runs bewahren Teilergebnisse.

AnalyticsRun erfasst Versions-Bindings, Status, Filter, Berechtigungs- und RLS-Scope, Zeilenzahl, Diagnosen und Artifacts. Multi-Binding führt gespeicherte Bindings sequenziell aus und weist den Teilerfolg pro Binding aus; Overlay-, Union- und Merge-Verhalten bleibt eine explizite Report-Konfiguration statt eines abgeleiteten Joins.

Dashboards verdecken Widget-Fehler nicht.

Dashboard- und Widget-Runs behalten ihre Verbindung zu Report- und AnalyticsRun-Identitäten. Ein fehlgeschlagenes Widget muss erfolgreiche Widgets nicht verbergen oder als falscher Gesamterfolg erscheinen.

Artefakte und Cache bewahren die Governance-Identität.

Ergebnisstichproben, Profile, Diagramm-Payloads, Vollergebnisse und Diagnosen bewahren SHA-256-, Größen-, Retention- und Lineage-Metadaten. Lokale und S3-Zugriffe sind begrenzt und integritätsgeprüft; öffentliche Locator bleiben opak. Die Cache-Identität umfasst Report-/Dataset-Versionen, Berechtigungs-/RLS-Scope, Diagramm-/Konfigurationsverträge, Ausführungsrichtlinie, Limits und gehashte SQL-Parameter.

ReportVersion erfasst die analytische Absicht.

Dimensionen, Metriken, Aggregation, Diagramm, persistente Filter, Interaktionen und DatasetVersion-Bindings gehören zu einer unveränderlichen ReportVersion. Runtime-Filter erzeugen einen neuen Run-Kontext, statt die gespeicherte Definition unbemerkt zu ändern.

Der Server verantwortet Kompilierung und RLS.

Der Browser-Query-Context referenziert autorisierte Spalten und Metriken. Das Backend validiert ihn und kompiliert schreibgeschütztes SQL. Runtime- Filter können geschützte RLS-Origin-Metadaten nicht imitieren.

Visualisierungen nutzen einen gemeinsamen Vertrag.

Balken- und horizontale Balkendiagramme, Linien-, Flächen- und Streudiagramme mit optionaler Größe, Kreis- und Ringdiagramme, Tabellen, KPI und Multi-Series-Diagramme verwenden einen gemeinsamen versionierten, rendererneutralen Vertrag. Top N mit deterministischem Other, zeitliche Granularität, Vergleich, Drill, Referenzlinien und barrierefreie Fallback-Darstellung bleiben Teil derselben Spezifikation.

Typisierte Runtime-Filter leiten gültige Operatoren und Platzhalter aus dem ausgewählten Spaltenvertrag ab.

Inspect Data unterstützt begrenzte Seitennavigation, Sortierung und Spaltenprojektion, ohne den gespeicherten Report neu zu definieren.

Begrenzte CSV-, JSON- und Bildexporte bewahren Kürzungs- und Lineage-Metadaten.

Auto-Refresh erzeugt neuen Run-Kontext; die unveränderliche ReportVersion wird nicht mutiert.

Runs bewahren Teilergebnisse.

AnalyticsRun erfasst Versions-Bindings, Status, Filter, Berechtigungs- und RLS-Scope, Zeilenzahl, Diagnosen und Artifacts. Multi-Binding führt gespeicherte Bindings sequenziell aus und weist den Teilerfolg pro Binding aus; Overlay-, Union- und Merge-Verhalten bleibt eine explizite Report-Konfiguration statt eines abgeleiteten Joins.

Dauerhafte Ausführung nutzt Idempotenz, begrenzte Retries, Timeouts, Abbruch, Leases und die Rückgewinnung veralteter Runs.

Run-Events unterstützen Live-Replay mit Polling-Fallback, wenn Streaming nicht verfügbar ist.

Ein fehlgeschlagenes Binding bewahrt seine eigene sichere Diagnose; ein erfolgreiches Binding wandelt den Run nicht fälschlich in einen vollständigen Erfolg um.

Dashboards verdecken Widget-Fehler nicht.

Dashboard- und Widget-Runs behalten ihre Verbindung zu Report- und AnalyticsRun-Identitäten. Ein fehlgeschlagenes Widget muss erfolgreiche Widgets nicht verbergen oder als falscher Gesamterfolg erscheinen.

Artefakte und Cache bewahren die Governance-Identität.

Ergebnisstichproben, Profile, Diagramm-Payloads, Vollergebnisse und Diagnosen bewahren SHA-256-, Größen-, Retention- und Lineage-Metadaten. Lokale und S3-Zugriffe sind begrenzt und integritätsgeprüft; öffentliche Locator bleiben opak. Die Cache-Identität umfasst Report-/Dataset-Versionen, Berechtigungs-/RLS-Scope, Diagramm-/Konfigurationsverträge, Ausführungsrichtlinie, Limits und gehashte SQL-Parameter.

Der aktuelle Kompilierungsscope bleibt explizit.

Der kontrollierte Dataset-bewusste Compiler zielt derzeit auf PostgreSQL. Andere Source-Familien benötigen einen abgenommenen Materialisierungs- oder Dialektadapterpfad; die bloße Existenz eines Konnektors schafft diesen Pfad nicht.

Nächster Schritt

Beginnen Sie mit dem Datenfluss, der keine Unklarheit zulässt.

Bringen Sie die relevanten Systeme, Verantwortlichen, Regeln, Lieferverpflichtungen und Nachweisanforderungen ein.

Kritischen Datenfluss besprechen