advanexus Living System Map
So funktioniert advanexus
Von Quelle und Ausführung bis zum nachweisgestützten Geschäftsergebnis.
Fortschritt, der Verbindungen bewahrt.
advanexus verbindet advance und nexus: vorankommen, ohne die Verbindung zwischen Daten, Entscheidungen, Verantwortung und Nachweisen zu unterbrechen.
Tiefe
- L0
- L1
- L2
- L3
- L4
- L5
Mit den Pfeiltasten navigieren, mit Eingabe prüfen, mit Escape eine Ebene höher gehen und mit Plus oder Minus zoomen.
Alle hier gezeigten Datensätze und Kennungen sind synthetische Beispiele.
63 Interaktive advanexus-Systemkarte
Die Karte kann belegte Fakten und Nachweise zeigen; Geschäftsverpflichtung, Freigabe und endgültige Entscheidung bleiben in menschlicher Verantwortung.
Metadaten-, Vorschau-, Abfrage-, Transfer-, Schreib-, Lösch- und Qualitätsfunktionen unterscheiden sich nach Connector, Treiber und akzeptiertem Deployment.
Eine stabile Identität oder veränderliche Definition ist kein Lauf. Eine explizite Versionsreferenz bewahrt die akzeptierte Absicht.
Eine Abfrage ist eine Operation oder veränderliche Arbeitsdefinition, keine gesteuerte Dataset-Identität.
Definitionen und Versionen beweisen keine Ausführung. Jeder Lauf ist ein eigener Datensatz mit Geltungsbereich, Status und Ergebnis.
Ein künftiger Ausführungstermin durchläuft neue Zulassungsprüfungen und fixiert vor dem Dispatch die dann aktuelle unveränderliche JobVersion in einem dauerhaften PipelineRun; Exactly-once-Geschäftswirkungen und Rollback hängen vom Executor, Connector, von der Richtlinie und nachgewiesener Idempotenz ab.
QualityRule ist derzeit ein veränderlicher Quellvertrag, keine an DatasetVersion gebundene unveränderliche Regel; QualityRun bleibt von PipelineRun getrennt.
DatasetVersion sperrt Vertrag, SQL, Schema und Beziehungen, nicht physische Quellzeilen. Zeilenreproduktion braucht ein gespeichertes Ergebnis, Artefakt oder materialisiertes Snapshot.
Ein Entwurf ist nicht ausführbar. ReportVersion kann an DatasetVersion oder ein unveränderliches SQL-Snapshot gebunden sein; Laufzeitfilter gehören zu AnalyticsRun.
VisualizationDraft ist eine flüchtige, einem Actor gehörende Sicht auf genau einen begrenzten QueryExecution-Snapshot und führt SQL nicht erneut aus. Beim Speichern entstehen kanonische Dataset- und Report-Versionen; der Entwurf selbst bleibt nicht maßgeblich.
Visualization ist eine menschenlesbare Sicht auf ein Ergebnis, keine Datenquelle und kein Beweis für dessen Richtigkeit.
Eine veröffentlichte VisualizationWorkspaceVersion fixiert ihr responsives Layout sowie die exakten ReportVersion- und DatasetVersion-Bindungen. DashboardRun → WidgetRun → Actor-sichtbarer AnalyticsRun bewahrt jedes Ergebnis, einschließlich Teilerfolg. Aktualisierungspläne, vorbereitete Daten, Alarme und kontrollierte Freigaben sind getrennte, versionsgebundene und erneut autorisierte Kontrollen; Freigabe und Export bleiben von der Deployment-Richtlinie abhängig.
Assurance ist ein berechtigungsbewusstes Lesemodell über kanonischen Quellen. Es besitzt, verändert oder vervollständigt deren Verlauf nicht.
Ein Service-Desk-Ticket ist ein operativer Supportablauf, kein Assurance Case und kein Beweis erfolgreicher Behebung.
EvidencePackage ist ein technischer Export mit Manifest und Prüfsummen; es ist nicht automatisch digital signiert, WORM oder rechtlich endgültig.
Ein Intelligence-Vorschlag benötigt deterministische Validierung, menschliche oder regelbasierte Bestätigung und neue Autorisierung vor der kanonischen Aktion.
Tenant, Project, Actor, Mitgliedschaft, Berechtigungen und RLS werden je Operation neu geprüft. Eine Rollenperspektive autorisiert nicht.
Audit- und Outbox-Projektionen sind eventual-konsistente Read-side-Nachweise. Der kanonische Servicestatus bleibt maßgeblich; Lücken bleiben sichtbar.