S•U•S•I - Qualitätsmanagement für immoSoR

Zwei Prüfungen mit unterschiedlichem Auftrag

Der Cron-Lauf arbeitet ohne aktiven persönlichen Login. Er untersucht die mandantenbezogenen technischen Grundlagen und beantwortet die Frage:

Ist die technische Infrastruktur des Mandanten grundsätzlich betriebsbereit und konsistent?

Geprüft werden können zentrale Services, Datenbankverbindungen, Queues, Worker, NotificationCenter, Outbox, Rollen- und Capability-Register, Versionsstände, Hash- und Auditfunktionen sowie Konfigurationszustände.

Der Cron-Lauf beantwortet jedoch nicht abschließend:

Kann dieser konkrete Nutzer in seiner aktuellen Sitzung heute sicher arbeiten?

Diese Frage gehört zum Tagesstart. Dort werden Nutzeridentität, Mandant, Rolle, Sitzung, Capabilities, aktueller Scope und rollenbezogene Tagesfunktionen geprüft.

Die Ebenen greifen ineinander

Ein guter Hintergrundlauf kann den Tagescheck verkürzen, vorbereiten, gezielter machen und technisch absichern.

Der Tagesstart darf auf bereits bestätigte Hintergrundbefunde zurückgreifen. Prüfrelevante Daten werden jedoch nicht ungeprüft übernommen. Der aktuelle Nutzerkontext wird immer neu gebunden.

Die Beziehung lautet:

Hintergrund-QM → bestätigt systemische Grundlagen → liefert aktuelle technische Vorbefunde → Tagescheck prüft den konkreten Nutzerkontext

Der zyklische Betriebsablauf

Das Hintergrund-QM kann nachts, früh morgens, vor dem typischen Arbeitsbeginn oder in festgelegten Intervallen laufen.

Der Lauf erfolgt nicht, weil ein Nutzer anwesend ist. Er folgt einem technischen Zeitplan. Sichtbare Zeiten und fachliche Tageszuordnungen werden in Europe/Berlin geführt, während die technische Speicherung intern in UTC erfolgen kann.

Während des Arbeitstages verwendet der konkrete Tagescheck die Ergebnisse der jüngsten gültigen Hintergrundprüfung. Dabei wird kontrolliert, ob der Cron-Befund noch aktuell ist, dieselbe App- und Registerversion gilt, der Mandant übereinstimmt und seit dem Hintergrundlauf keine relevante Änderung eingetreten ist.

Veraltete oder widersprüchliche Hintergrunddaten dürfen keinen grünen Tagesstatus erzeugen.

Tagesbefunde können anschließend in die systemische Prüfung zurückfließen. Wiederkehrende Timeouts, fehlende Nachweise, Konfigurationsdrift, instabile Dienste oder wiederholte Rollen- und Scopeabweichungen werden im nächsten Hintergrundlauf erneut betrachtet.

So entsteht ein lernender Qualitätskreislauf, der das System verbessert, ohne einzelne Nutzer zu bewerten.

Mandantenbezogene Prüfung

Jeder Hintergrundlauf erhält einen eigenen Mandantenkontext. Er wird mindestens an company_id, Prüfregister, App-Version, Zeitfenster, Run-ID und Konfiguration gebunden.

Ergebnisse eines Mandanten gelten nicht automatisch für einen anderen. Ein Fehler in Mandant A darf den Status von Mandant B nicht verfälschen.

Die Mandantentrennung arbeitet Fail-Closed.

Innerhalb eines Mandanten kann das Hintergrund-QM mehrere Rollenprofile prüfen, etwa Makler, Empfehlungspartner, Assistenz oder einen ausdrücklich gebundenen Super-Admin-Prüfkontext.

Dabei werden keine realen Nutzerhandlungen simuliert. Geprüft werden registrierte Funktionsketten, Rollen- und Capability-Zuordnungen, erwartete Schutzbedingungen und technische Erreichbarkeit.

Personenbezogene Sitzungs-, Scope- und Zuweisungsfragen bleiben Aufgabe des Tageschecks beziehungsweise des vollständigen Rollen-Audits.

Kein undifferenzierter Plattformstatus

Ein plattformweiter Gesamtstatus darf die mandantenbezogenen Einzelbefunde nicht verdecken.

Erforderlich bleiben Einzelergebnisse je Mandant, Funktionsgruppe, Befundklasse, Versionsbindung und Nachweis.

Ein Gesamttrend kann ergänzend dargestellt werden. Der eigentliche Befund bleibt jedoch immer einem konkreten Mandanten und Lauf zugeordnet.

Infrastrukturprüfung

Das Hintergrund-QM kann prüfen, ob Webanwendung, Datenbank, Storage und zentrale Konfiguration erreichbar beziehungsweise geladen sind, Module korrekt registriert wurden, der Routenbestand konsistent ist und Cachezustände plausibel erscheinen.

Diese Prüfung bildet die technische Grundschicht. Sie ersetzt keine fachliche Funktionsabnahme.

Queue- und Workerprüfung

Geprüft werden aktive Worker, Queuezustände, wartende Aufträge, hängende Jobs, Dead Letters sowie Retry- und Backoff-Zustände.

Ein Hintergrundsystem kann technisch erreichbar sein, während seine Verarbeitung stillsteht. Deshalb gehören Queue und Worker ausdrücklich zur Betriebsbereitschaft.

Outbox und NotificationCenter

Das Hintergrund-QM prüft offene Outbox-Einträge, fehlgeschlagene Zustellungen, Dead-Letter-Zustände, nicht bestätigte Receipts und wiederholte Fehler.

Im Pilot bleibt diese Sicht vorzugsweise lesend. Ein Retry wird nur auf Grundlage eines definierten Betriebsvertrags ausgeführt.

Unkontrollierter Versand oder Massenwirkung bleibt ausgeschlossen.

Rollen-, Capability- und Scope-Konsistenz

Das Hintergrund-QM kann unbekannte Capabilities, unvollständige Rollenbindungen, widersprüchliche Zuordnungen, veraltete Funktionsregister, fehlende Mandantenbindungen und ungültige Policy-Stände erkennen.

Es darf jedoch keine Rechte automatisch erweitern. Abweichungen erzeugen gezielte Prüf- oder Konfigurationsaufträge.

Eine automatische Selbstfreigabe ist ausgeschlossen.

Versionen und Register

Jeder Lauf dokumentiert App-Version, Funktionsregister-Version, QM-Regelversion, Agenten- beziehungsweise Cron-Version und Audit-Schema-Version.

Abweichende oder veraltete Versionen werden sichtbar. Ein Tagescheck darf keine Hintergrundbestätigung aus einem anderen relevanten Versionsstand übernehmen.

Versionen bilden einen wesentlichen Teil des Prüfkontexts.

Audit- und Nachweisfähigkeit

Das Hintergrund-QM prüft, ob Auditereignisse geschrieben, Run-IDs gebildet, Hashes erzeugt, PDF- und Arbeitsprotokollbindungen hergestellt und Revisionsdaten vollständig gespeichert werden können.

Eine technisch funktionierende Plattform ohne Nachweisschicht ist nicht vollständig betriebsbereit.

Fehlende Audit- oder Hashfunktionen werden als Nachweisbefund klassifiziert.

Konfigurationsdrift

Das System vergleicht Soll- und Ist-Konfigurationen. Dabei können fehlende Pflichtprofile, abweichende Modulzustände, unvollständige Funktionsregister, Rollen ohne erwartete Capability, veraltete Policies oder fehlende Zuordnungen sichtbar werden.

Konfigurationsdrift wird nicht automatisch durch pauschale Rechtevergabe repariert. Sie erzeugt einen gezielten Einrichtungs- oder Prüfauftrag.

Wirtschaftlicher Schutz

Auch das Hintergrund-QM arbeitet ausschließlich mit neutralen Prüfdaten.

Es löst keine Provision, Auszahlung, Forderung, Rechnung, Kundenbuchung oder Produktivfreigabe aus.

Der Wirtschaftsmodus bleibt LOCKED. Wirtschaftlich wirksame Integrationen dürfen auf Erreichbarkeit und Sperrstatus geprüft werden. Eine reale Transaktion wird nicht simuliert.

Cron als kontrollierter Auslöser

Cron ist ausschließlich der Taktgeber. Er startet den Lauf zu einem definierten Zeitpunkt, entscheidet aber nicht selbst, welche Funktion freigegeben wird, welcher Befund grün ist oder welche wirtschaftliche Maßnahme zulässig wäre.

Cron übergibt den Prüfauftrag an die vorgesehenen Services. Die fachliche Bewertung erfolgt durch den QM-Service, die verständliche Einordnung durch S•U•S•I und die Laufüberwachung durch den Agenten.

Vor einer produktiven Aktivierung müssen Zeitplan, Mandantenumfang, Registerversion, Laufzeitgrenzen, Fehlerlogik, Nachweisordnung und Rückfallverhalten feststehen.

Eine sichtbare Cronzeile allein ist keine Abnahme.

Keine unkontrollierten Parallelstarts

Für denselben Mandanten, Prüfbereich und Zeitraum darf nicht unkontrolliert mehr als ein Lauf aktiv sein.

Lauf-Sperren verhindern Doppelprüfungen, widersprüchliche Ergebnisse, doppelte Nachweise und unnötige Last.

Wiederholte Cron-Trigger werden idempotent behandelt. Ein laufender oder bereits gültig abgeschlossener Auftrag wird erkannt.

Der Agent als Laufaufsicht

Der Agent überwacht Start, Lease, Heartbeat, Fortschritt, Unterbrechung, Wiederaufnahme, Timeout und Finalisierung.

Er erkennt verwaiste oder hängende Läufe und kann einen technischen Prüfauftrag vorbereiten.

Der Agent darf den geprüften Vorgang jedoch weder fachlich noch wirtschaftlich selbst freigeben.

Leases und Heartbeats

Jeder länger laufende Auftrag erhält eine zeitlich begrenzte Lease. Heartbeats bestätigen, dass Worker und Lauf noch aktiv sind.

Fehlt ein Heartbeat, wird der Lauf nicht still als erfolgreich angenommen. Der Zustand wird geprüft, und gegebenenfalls erfolgt eine kontrollierte Wiederaufnahme.

Leases verhindern, dass zwei Worker denselben Auftrag gleichzeitig bearbeiten.

Wiederaufnahme statt vollständigem Neustart

Ein unterbrochener Hintergrundlauf wird möglichst am letzten gesicherten Prüfschritt fortgesetzt.

Die Fortsetzung bleibt an Run-ID, Mandant, Registerversion, Prüfschritt und Payload-Hash gebunden.

Ein unkontrollierter Neustart könnte doppelte Prüfungen, doppelte Folgeaufträge und widersprüchliche Nachweise erzeugen. Deshalb hat die sichere Wiederaufnahme Vorrang.

Retry, Backoff und Dead Letter

Technische Fehler können einen kontrollierten Retry erlauben. Die Wiederholung erfolgt begrenzt, mit Backoff und passend zur Fehlerklasse.

Dauerhaft fehlerhafte Vorgänge werden in einen Dead-Letter-Zustand überführt und nicht endlos wiederholt.

Der Befund bleibt sichtbar und auditierbar. S•U•S•I kann betroffene Nutzer später verständlich informieren.

Finalisierung

Nach der technischen Prüfung wird der Lauf kontrolliert finalisiert.

Dazu gehören Gesamtstatus, Einzelbefunde, Hash, Audit, technischer Bericht und die Verknüpfung von Folgeaufträgen.

Ein Lauf darf nicht dauerhaft bei 99 Prozent ohne definierten Abschlusszustand verbleiben. Die Finalisierung ist ein eigener, überwachter Schritt.

Trenddaten und systemische Erkenntnisse

Einzelne Hintergrundläufe werden über die Zeit vergleichbar. Dadurch lassen sich häufige Timeouts, instabile Services, wiederkehrende Nachweislücken, Konfigurationsdrift, Versionsprobleme und mandantenbezogene Muster erkennen.

Diese Trends dienen ausschließlich der technischen Systemverbesserung.

Ausgewertet werden Funktionsgruppen, Dienste, Mandantenkonfigurationen, Versionen, Fehlerklassen und Laufzeiten des Systems.

Nicht ausgewertet werden Arbeitsgeschwindigkeit, Anwesenheit, Produktivität, Verhalten oder die Anzahl freiwillig gestarteter Tageschecks einzelner Nutzer.

Wiederkehrendes Gelb und Rot

Wiederkehrende gelbe Befunde können auf strukturelle Schwächen hinweisen, etwa fehlende Negativtests, instabile Hashbildung, unvollständige Konfigurationen oder langsam reagierende Dienste.

Das Hintergrund-QM bündelt diese Muster und überführt sie in gezielte Audits, Reparaturaufträge, Priorisierungen oder Folgepatches.

Wiederkehrende rote Befunde erhalten eine höhere technische Priorität.

Rot-Kritisch führt zu Schutzprüfung, Sperre, Reconciliation und Eskalation. Rot-Technisch zu Workeranalyse, Kapazitätsprüfung oder Reparaturpatch. Rot-Nachweis zur Prüfung der Revisionsschicht. Rot-Konfiguration zu einem gezielten Einrichtungsauftrag.

Übergabe an den Tagesstart

Der jüngste gültige Hintergrundlauf kann dem Tagescheck Infrastrukturstatus, bekannte technische Befunde, Versionsstand, Nachweisstatus und betroffene Funktionsgruppen bereitstellen.

Der Tagesstart übernimmt diese Informationen nicht blind. Er prüft Aktualität, Mandantenbezug und Versionspassung.

Bereits grün bestätigte allgemeine Systemgrundlagen müssen nicht vollständig erneut tief geprüft werden. Der Tagescheck kann sich stärker auf Nutzer, Sitzung, Rolle, Mandant, individuelle Zuweisungen und konkrete Tagesfunktionen konzentrieren.

Dadurch wird der 15-Sekunden-Zielwert realistischer, ohne zwingende Schutzprüfungen auszulassen.

Bekannter Hintergrundbefund beim Login

Liegt bereits ein relevanter technischer Befund vor, kann S•U•S•I ihn beim Tagesstart ruhig einordnen.

Beispielsweise:

Die nächtliche Systemprüfung hat eine technische Störung im Rückrufdienst festgestellt. Ihre übrigen Tagesfunktionen werden normal geprüft. Für den Rückrufdienst ist bereits eine technische Nachprüfung aktiv.

Der Nutzer wird dadurch frühzeitig informiert und muss die Störung nicht erst während eines realen Fachvorgangs entdecken.

Ein roter Cron-Befund ist jedoch kein roter Nutzerstatus. Er beschreibt einen Systemzustand des Mandanten oder einer Funktion. Der Tagescheck prüft separat, ob und wie der konkrete Nutzer betroffen ist.

Ergebnis und Nachweis

Das Hintergrund-QM erzeugt einen technischen Betriebsbericht. Dieser kann Mandant, Run-ID, Zeitfenster, Register- und App-Version, geprüfte Funktionsgruppen, Status, Einzelbefunde, Laufzeiten, Retry- und Dead-Letter-Zustände, Hash und Folgeaufträge enthalten.

Der Bericht ist technischer und umfangreicher als die Tagesstellungnahme.

Jeder Lauf erzeugt eine mandantenbezogene Auditspur. Dokumentiert werden Trigger cron, Start und Ende, Worker oder Agent, Mandant, Prüfumfang, Ergebnis, Fehler- und Wiederholungsfälle sowie Finalisierung.

Korrekturen erzeugen neue Ereignisse. Frühere Zustände werden nicht still überschrieben.

S•U•S•I-Projektion

Nicht jeder technische Einzelbefund wird dem Nutzer direkt angezeigt.

S•U•S•I filtert nach Rolle, Relevanz, aktueller Betroffenheit und erforderlicher Handlung.

Der Nutzer erhält nur die für seinen Tagesablauf notwendige Information. Technik und Revision behalten Zugriff auf die vollständige Prüffassung.

Schutz- und Neutralitätsregeln

Fehlt ein eindeutiger Mandant oder Registerstand, startet kein ungebundener Hintergrundlauf.

Unbekannte Capabilities und widersprüchliche Konfigurationen werden nicht still akzeptiert. Sicherheitsrelevante Prüfungen arbeiten Fail-Closed.

Ein grüner Cron-Lauf erzeugt keine Exposé-Freigabe, Provision, Auszahlung, Rechnungsfreigabe, Rollenaktivierung oder Veröffentlichung.

Er bestätigt ausschließlich die geprüfte technische Betriebsbereitschaft.

Das Hintergrund-QM darf sichere technische Wiederholungen oder klar begrenzte Wiederaufnahmen ausführen. Es darf jedoch keine Rechte erweitern, Rollen zuweisen, Mandantenbindungen verändern, Zahlungsstatus korrigieren oder produktive Freigaben erteilen.

Konfigurations- und Schutzänderungen benötigen einen berechtigten und auditierten Vorgang.

Das zyklische Gesamtmodell

Nachts oder morgens:
Cron startet die mandantenbezogene Systemprüfung → Agent überwacht Lauf und Wiederaufnahme → QM-Service bewertet Infrastruktur und Funktionsgruppen → Bericht, Hash und Audit entstehen → bekannte Befunde werden bereitgestellt.

Beim Arbeitsbeginn:
Nutzer meldet sich an → S•U•S•I erkennt den konkreten Kontext → Tagescheck verwendet gültige Hintergrundbefunde → Sitzung, Rolle, Mandant und Tagesfunktionen werden geprüft → verständliche Stellungnahme und Tagesnachweis entstehen.

Im laufenden Betrieb:
Tagesbefunde fließen in Audit und Trends zurück → der nächste Cron-Lauf prüft die systemische Entwicklung.

So entsteht ein kontinuierlicher Qualitätskreislauf. Keine Ebene ersetzt die andere. Jede Ebene erfüllt ihren eigenen Prüfauftrag.