Plattformübersicht

Ein Betriebsmodell von der Source bis zum Nachweis.

advanexus führt Datenoperationen, kontrollierte Assets, Analytics, Python-Arbeit und verfügbare Nachweise in einem gemeinsamen Tenant- und Project-Modell zusammen, während jedes Modul für seine kanonischen Datensätze verantwortlich bleibt.

advanexus führt Datenoperationen, kontrollierte Assets, Analytics, Python-Arbeit und verfügbare Nachweise in einem gemeinsamen Tenant- und Project-Modell zusammen, während jedes Modul für seine kanonischen Datensätze verantwortlich bleibt.
Tenant und Project machen Scope zu einer Ausführungsentscheidung.

Tenant ist die Organisations- und Datenisolationsgrenze. Project ist darin der Mitgliedschafts- und Ausführungsscope – kein Anzeigefilter im Browser. Die Project-Auswahl steuert effektive Rollen, den Datenbank-Suchpfad und die für projektgebundene Module sichtbaren Ressourcen.

Gemeinsame Objekte machen den Lifecycle verständlich.

Actor, Source, FileVersion, TableVersion, DatasetVersion, ReportVersion, Environment, Run, Artifact, Evidence, Finding, Case und Ticket behalten jeweils einen eigenen kanonischen Verantwortlichen. Ihre expliziten Beziehungen sind wertvoller als ein generischer Aktivitätsstrom.

Verbinden und ermitteln.

Registrieren Sie Project-bezogene Sources, lösen Sie Treiberfunktionen auf, untersuchen Sie Metadaten und nutzen Sie begrenzte schreibgeschützte Exploration, bevor ein Ergebnis zu einem dauerhaften Asset wird.

Erstellen und validieren.

Bewahren Sie unveränderliche Dateiversionen, untersuchen Sie Inhalte, veröffentlichen Sie verwaltete TableVersion-Objekte, wenden Sie Data-Quality-Assertions an und halten Sie Ausführungsergebnisse implementierter Pipeline-Flows fest.

Kontrollieren und analysieren.

Geben Sie Datendefinitionen eine stabile Dataset-Identität, binden Sie ReportVersion exakt an DatasetVersion und führen Sie Analytics unter bekanntem Berechtigungs-, RLS- und Filterkontext aus.

Mit kontrolliertem Python erweitern.

ANPy verbindet Notebook-Revision, Environment-Identität, Kernel-Lifecycle und begrenzte CellRuns, ohne Prozessspeicher als dauerhaften Nachweis darzustellen.

Verstehen, untersuchen und nachweisen.

Intelligence unterstützt beim Ableiten und Vorbereiten registrierter Aktionen; Assurance verbindet unterstützte Datensätze zu abgegrenzten Untersuchungen, Findings, Cases, Integritätszuständen und Evidence Packages.

Tenant und Project machen Scope zu einer Ausführungsentscheidung.

Tenant ist die Organisations- und Datenisolationsgrenze. Project ist darin der Mitgliedschafts- und Ausführungsscope – kein Anzeigefilter im Browser. Die Project-Auswahl steuert effektive Rollen, den Datenbank-Suchpfad und die für projektgebundene Module sichtbaren Ressourcen.

Kontrollierte Bereitstellung

Die Project-Erstellung richtet die Tenant-Datenbank aus, erstellt ein mit einer Eigentumsmarkierung versehenes Schema, wendet Runtime-Berechtigungen an und registriert die System Sandbox Source, bevor das Mapping veröffentlicht wird.

Aktiver Kontext

Serverseitiger Session-Status bindet Akteur, Tenant und aktives Project; geschützte Anfragen validieren diesen Kontext erneut, statt Headern oder Seitenstatus zu vertrauen.

Explizite Ausnahmen

Assurance ist ein tenantweites Lesemodell, Service Desk eine tenantweite Queue mit optionalem Project-Kontext, und Intelligence kann globalen, projektbezogenen oder exakt objektbezogenen Scope verwenden.

Gemeinsame Objekte machen den Lifecycle verständlich.

Actor, Source, FileVersion, TableVersion, DatasetVersion, ReportVersion, Environment, Run, Artifact, Evidence, Finding, Case und Ticket behalten jeweils einen eigenen kanonischen Verantwortlichen. Ihre expliziten Beziehungen sind wertvoller als ein generischer Aktivitätsstrom.

Version identifiziert den exakten aufgezeichneten Vertragszustand; sie bedeutet keine Momentaufnahme aktiver Zeilen, sofern der Vertrag dies nicht ausdrücklich festlegt.

Run identifiziert einen Ausführungsversuch und dessen terminales oder partielles Ergebnis.

Artifact identifiziert aufbewahrte, begrenzte Ausgaben, Profile, Diagnosen oder Exportmaterialien.

Evidence erfasst, was eine kanonische Source belegen kann, und lässt fehlenden Kontext sichtbar.

Verbinden und ermitteln.

Registrieren Sie Project-bezogene Sources, lösen Sie Treiberfunktionen auf, untersuchen Sie Metadaten und nutzen Sie begrenzte schreibgeschützte Exploration, bevor ein Ergebnis zu einem dauerhaften Asset wird.

Sources und Konnektor-Funktionsverträge

Dauerhafte SQL-Console-Workspaces, SavedQueries und QueryExecutions

Unveränderliche Sandbox FileVersions und inhaltsbewusste Preflight-Prüfung

Erstellen und validieren.

Bewahren Sie unveränderliche Dateiversionen, untersuchen Sie Inhalte, veröffentlichen Sie verwaltete TableVersion-Objekte, wenden Sie Data-Quality-Assertions an und halten Sie Ausführungsergebnisse implementierter Pipeline-Flows fest.

Atomare Veröffentlichung stabiler Aliase nach der Validierung

Sourceorientierte QualityRuns und begrenzte Findings

Persistierte Ergebnisse von Query-, Transfer-, Delete-, Quality- und Master-Runs

Kontrollieren und analysieren.

Geben Sie Datendefinitionen eine stabile Dataset-Identität, binden Sie ReportVersion exakt an DatasetVersion und führen Sie Analytics unter bekanntem Berechtigungs-, RLS- und Filterkontext aus.

Dataset-Vertrag und unveränderlicher Versionsvergleich

AnalyticsRuns mit mehreren Bindings und Diagnose je Binding

Dashboards, die Ergebnisse einzelner Widget-Runs bewahren

Mit kontrolliertem Python erweitern.

ANPy verbindet Notebook-Revision, Environment-Identität, Kernel-Lifecycle und begrenzte CellRuns, ohne Prozessspeicher als dauerhaften Nachweis darzustellen.

Verstehen, untersuchen und nachweisen.

Intelligence unterstützt beim Ableiten und Vorbereiten registrierter Aktionen; Assurance verbindet unterstützte Datensätze zu abgegrenzten Untersuchungen, Findings, Cases, Integritätszuständen und Evidence Packages.

Identität, Onboarding und Settings bleiben Teil des Betriebsmodells.

Kontrolliertes Onboarding stellt Tenant- und Project-Zugriff bereit; Settings verwaltet Konto, Teamrollen und die Tenant-SAML-Richtlinie. Authentifizierte Anfragen erfordern einen passenden aktiven Session-Registry-Datensatz, aktuellen Tenant-/Nutzerstatus und den serverseitigen kanonischen Origin.

Enterprise-Einstieg

Der standardmäßige kontrollierte Pfad besteht aus Tenant-Bereitstellung durch den Plattformadministrator, erzwungener Änderung des temporären Passworts und expliziter Project-Erstellung – nicht aus angenommener öffentlicher Selbstregistrierung.

Teamzugriff

Das aktuelle Onboarding erstellt oder verwendet Nutzer unmittelbar und weist Rollen zu; es ist kein Lifecycle mit Einladungs-E-Mail oder ausstehendem Token.

SAML- und MFA-Nachweise

SAML-Metadaten/Login/ACS, JIT-Identitätsverknüpfung, Domain-Richtlinie und vom IdP bestätigte MFA-Nachweise sind vorhanden; Anwendungs-TOTP/WebAuthn und eine vollständige Step-up-Oberfläche nicht.

Session-Sicherheit

Widerrufener, abgelaufener oder abweichender Registry-Status wird fail-closed abgewiesen; Passwortänderungen, Resets und Kontolöschung widerrufen aktive Sessions.

Service Desk verbindet operative Kommunikation, ohne sie durch bloße Behauptung zum Nachweis zu machen.

Tenant-Nutzer können begrenzte Support-, Abrechnungs-, Sicherheits-, Fehler-, Feature- und Incident-Tickets erstellen und verfolgen. Plattformadministratoren können antworten, interne Notizen ergänzen, zuweisen und den Status ändern; unterstützte Ticket-Events können in Assurance projiziert werden.

Die Tenant-Queue ist tenantweit; Project-Identität ist optionaler Kontext und nicht das Autorisierungsprädikat der Liste.

Interne Notizen bleiben in Tenant-Templates verborgen, während öffentliche Antworten Teil des Tenant-Threads bleiben.

Anhänge, SLA-Automatisierung, E-Mail/Webhooks, unveränderliche TicketVersion und vollständiges ITSM-/CMDB-Verhalten gehören derzeit nicht zum Funktionsumfang.

Geführte Touren erklären das reale Produkt, nicht ein losgelöstes Video.

Gemeinsame Tour-Infrastruktur kann SQL Console, Dataset-Detail und Analytics mit synthetischen Beispielen, Wiedergabe-/Pause-/Weiter-Steuerung und seitenähnlichen Modaloberflächen demonstrieren. Touren vermitteln Workflow und Grenzen; sie führen keine Tenant-Aktionen aus und ersetzen keine Dokumentation.

Der Funktionsstatus ist Teil des Produktvertrags.

Verfügbar, produktionsorientiert, umgebungsabhängig und geplant sind unterschiedliche Zustände. Eine öffentliche Funktionsaussage ersetzt nie die Live-Abnahme der exakten Revision und Bereitstellung.

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