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

Die geschlossene Betriebskette

Der grundsätzliche Ablauf lautet:

Cron → gibt den regelmäßigen Takt vor

Agent → überwacht die technische Durchführung

QM-Service → prüft und bewertet die gesammelten Daten

S•U•S•I → erklärt das Ergebnis und begleitet den Nutzer

Nach Abschluss fließen relevante Befunde wieder in die nächste geplante Prüfung ein. So entsteht ein Kreislauf statt einer losen Aneinanderreihung technischer Prozesse.

Jede Übergabe bleibt über Run-ID und Korrelationsspur nachvollziehbar.

Cron · Der Taktgeber

Cron übernimmt die zeitliche Auslösung des Hintergrund-QM. Er kann Prüfungen nachts, morgens, in definierten Intervallen oder mandantenweise anstoßen.

Cron startet ausschließlich zuvor registrierte und freigegebene Prüfprofile. Er entscheidet nicht selbst, welche Funktion fachlich grün oder rot ist.

Cron ist Zeitgeber, nicht Bewertungsinstanz.

Der Zeitplan muss eindeutig dokumentiert sein. Dazu gehören Prüfintervall, Startzeit, Zeitzone, Mandantenumfang, Rollenprofile und Funktionsregister-Version.

Sichtbare Zeiten werden konsistent in Europe/Berlin ausgegeben. Die technische Speicherung kann intern in UTC erfolgen. Eine Änderung des Zeitplans benötigt eine nachvollziehbare Konfigurationsänderung.

Eine zufällig vorhandene Cronzeile ist noch keine betriebliche Abnahme.

Cron erzeugt einen Auftrag, kein Ergebnis

Der Cron-Trigger erzeugt oder disponiert einen Prüfauftrag. Dieser enthält mindestens Run-ID, Mandant, Prüfprofil, Registerversion, App-Version, Triggergrund und geplanten Startzeitpunkt.

Das eigentliche Ergebnis entsteht erst nach der tatsächlichen Durchführung und Bewertung.

Ein erfolgreich ausgelöster Cronjob darf deshalb niemals mit einem erfolgreich abgeschlossenen QM-Lauf verwechselt werden.

Schutz vor Doppelstarts

Vor dem Start wird geprüft, ob für denselben Mandanten, Prüfbereich, Zeitraum und Versionsstand bereits ein aktiver oder gültig abgeschlossener Lauf besteht.

Wiederholte Trigger werden idempotent behandelt. Ein zweiter Cron-Aufruf darf keine parallele Prüfkette erzeugen.

Lauf-Sperren und eindeutige Schlüssel verhindern widersprüchliche Ergebnisse und doppelte Nachweise.

Die Grenzen von Cron

Cron darf nicht selbst:

• Befunde umklassifizieren,
• Rollen oder Capabilities verändern,
• Funktionen produktiv freigeben,
• Provisionen oder Auszahlungen auslösen,
• Schutzsperren umgehen,
• Nutzer bewerten.

Seine Aufgabe endet mit der kontrollierten Übergabe des Prüfauftrags.

Agent · Die technische Laufaufsicht

Der Agent überwacht, ob ein vom Cron oder aus einer anderen Quelle angestoßener Lauf tatsächlich arbeitet.

Er kontrolliert Start, Fortschritt, Lease, Heartbeat, Timeout, Unterbrechung, Wiederaufnahme und Finalisierung.

Dadurch erkennt er den Unterschied zwischen geplant, gestartet, aktiv, unterbrochen, hängend, abgeschlossen und fehlgeschlagen.

Der Agent verhindert, dass ein Lauf nur scheinbar aktiv bleibt.

Leases verhindern parallele Bearbeitung

Ein Worker erhält eine zeitlich begrenzte Lease auf einen Prüfauftrag. Solange sie gültig ist, darf kein zweiter Worker denselben Auftrag übernehmen.

Die Lease enthält Run-ID, Workerkennung, Beginn, Ablaufzeit und letzten Heartbeat.

Eine Lease ist kein dauerhafter Besitz. Sie muss regelmäßig bestätigt oder kontrolliert neu vergeben werden.

Heartbeats zeigen den Laufzustand

Der Worker sendet regelmäßige Heartbeats. Dadurch erkennt der Agent, ob der Prozess aktiv ist, Fortschritt stattfindet oder eine Unterbrechung vorliegt.

Ein fehlender Heartbeat führt nicht automatisch zu einem grünen Abschluss.

Zunächst wird geprüft, ob der Worker ausgefallen ist, nur die Kommunikation gestört wurde, ein sicherer Zwischenstand besteht oder eine Fortsetzung möglich ist.

Wiederaufnahme statt blindem Neustart

Ein abgebrochener Lauf soll nicht unkontrolliert vollständig neu begonnen werden. Der Agent ermittelt den letzten bestätigten Prüfschritt.

Die Fortsetzung bleibt an Run-ID, Mandant, Prüfprofil, Registerversion, Payload-Hash und letzten sicheren Zustand gebunden.

Ein veralteter oder widersprüchlicher Zwischenstand wird nicht übernommen.

Fortsetzen bedeutet Wiederaufnahme derselben Akte, nicht Erzeugung eines neuen parallelen Laufs.

Technische Fehlerklassifikation

Der Agent kann technische Fehler vorbereitend einordnen, etwa Timeout, abgelaufene Lease, nicht erreichbarer Worker, blockierte Queue, ungültige Antwort oder fehlgeschlagene Finalisierung.

Diese technische Klassifikation unterstützt den QM-Service.

Der Agent entscheidet jedoch nicht allein über Rot-Kritisch, fachliches Risiko oder wirtschaftliche Wirkung. Die abschließende Bewertung bleibt beim QM-Service.

Retry, Backoff und Dead Letter

Wiederholbare Fehler können kontrolliert erneut ausgeführt werden. Der Agent berücksichtigt Fehlerklasse, maximale Wiederholungszahl, Backoff-Zeit, bisherige Versuche und aktuellen Systemzustand.

Wiederholungen erfolgen nicht endlos. Jeder fehlgeschlagene Retry bleibt protokolliert.

Dauerhaft nicht ausführbare Aufträge werden in einen Dead-Letter-Zustand überführt. Dieser enthält Run-ID, Fehlerklasse, Anzahl der Versuche, letzten Fehler, Zeitpunkt und empfohlenen nächsten Schritt.

Der Auftrag bleibt sichtbar und wird nicht still gelöscht.

Finalisierung als eigener Schritt

Ein Lauf ist nicht abgeschlossen, nur weil alle Einzelprüfungen scheinbar beendet sind.

Die Finalisierung umfasst das Sammeln der Einzelbefunde, die Vorbereitung des Gesamtstatus, die Hashbildung, die Vervollständigung des Audits, die Referenzierung des Berichts und das Setzen des Abschlusszustands.

Der Agent überwacht, dass ein Lauf nicht dauerhaft bei 99 Prozent stehen bleibt.

Ein Fehler in der Finalisierung wird als eigener technischer oder nachweisbezogener Befund geführt.

Die Grenzen des Agenten

Der Agent darf keine fachliche Freigabe erteilen, wirtschaftliche Wirkung aktivieren, Rechte erweitern, Mandanten wechseln, Rollen zuweisen, rote Befunde zu Grün erklären oder ungeprüfte Ergebnisse veröffentlichen.

Der Agent ist Laufaufsicht, nicht Freigabeinstanz.

QM-Service · Die Bewertungsinstanz

Der QM-Service übernimmt die eigentliche Prüflogik. Er erhält Prüfauftrag, Kontext, Funktionsregister, technische Ergebnisse, Agentenstatus und Einzelbefunde.

Er führt Soll-Ist-Vergleiche durch und bestimmt, ob eine Funktion vorhanden, erreichbar, ausführbar, geschützt, neutral und nachgewiesen ist.

Der QM-Service ist damit die fachlich-technische Bewertungsmitte.

Der QM-Service kennt den Prüfumfang

Der Service löst das passende Funktionsregister auf. Maßgeblich sind Mandant, Rolle, Prüfebene, App-Version und Registerversion.

Für den Tagescheck gilt ein begrenztes Register. Das vollständige Rollen-Audit verwendet die tiefere A/B/C-Prüfung. Das Hintergrund-QM arbeitet mit einem mandantenbezogenen Infrastruktur- und Funktionsprofil.

Nicht relevante Funktionen werden nicht willkürlich in die Bewertung aufgenommen.

Strukturierte Befundbewertung

Der QM-Service unterscheidet mindestens Grün, Gelb, Rot-Kritisch, Rot-Technisch, Rot-Nachweis und Rot-Konfiguration.

Die Bewertung richtet sich nach Pflichtgrad, Schutzrelevanz, Soll-Ist-Abweichung, wirtschaftlicher Wirkung und Nachweisstatus.

Ein fehlender Schutz darf nicht durch eine funktionierende Oberfläche überstimmt werden. Ein technischer Ausfall darf umgekehrt nicht ohne Beleg als Schutzverletzung klassifiziert werden.

Bestätigung der Neutralität

Der QM-Service prüft verbindlich:

• Testwert 0,00 EUR,
• economic_effect = none,
• Wirtschaftsmodus LOCKED,
• keine Forderung,
• keine Provision,
• keine Auszahlung,
• keine Produktivfreigabe.

Kann die Neutralität nicht bestätigt werden, entsteht ein kritischer Befund. Ein ansonsten funktionierender Lauf darf dann nicht grün werden.

Berechnung des Gesamtstatus

Der Gesamtstatus ergibt sich aus den Einzelbefunden.

Berücksichtigt werden kritische MUSS-Funktionen, offene Teilnachweise, technische Ausfälle, Konfigurationsmängel und Nachweislücken.

Der schwerste relevante Befund bestimmt die Gesamtwirkung. Unbetroffene Funktionen bleiben separat sichtbar.

Eine einzelne Störung muss nicht automatisch den gesamten Arbeitskontext sperren.

Die belegbare Datenbasis

Der QM-Service liefert strukturierte Felder für Gesamtstatus, Einzelbefunde, betroffene und unbetroffene Funktionen, wirtschaftliche Wirkung, Neutralität, Maßnahmen und Payload-Hash.

Diese Daten bilden die Grundlage für S•U•S•I-Stellungnahme, PDF-Protokoll, Arbeitsprotokoll, Audit und technische Folgeaufträge.

Die verständliche Sprache wird nicht innerhalb der Prüflogik frei erfunden.

Keine Personen- oder Vergütungsbewertung

Der QM-Service bewertet keine Arbeitsleistung, Anwesenheit, Geschwindigkeit, Zuverlässigkeit, Provision oder Auszahlung.

Er stellt ausschließlich den technischen und organisatorischen Systemzustand fest.

Fachliche und wirtschaftliche Freigaben bleiben getrennten Prozessen vorbehalten.

S•U•S•I · Die verständliche Begleitung

S•U•S•I ist die sichtbare Erklärungsschicht. Sie lädt ein, erklärt, begleitet, nimmt Stellung und weist nach.

Beim Hintergrund-QM erscheint sie nicht als permanenter technischer Monitor. Sie zeigt nur die für den aktuellen Nutzer und seine Rolle relevanten Ergebnisse.

Komplexe Systemdaten verbleiben in der technischen Prüffassung.

S•U•S•I erklärt die Bewertung

S•U•S•I übersetzt strukturierte Befunde in ruhige Fachsprache.

Die Stellungnahme beantwortet:

• Was wurde geprüft?
• Was ist nutzbar?
• Gibt es Risiken?
• Was geschieht jetzt?
• Wo liegt das Protokoll?

Eine Farbe allein genügt nicht. Die wichtigste Aussage lautet stets:

Kann der Nutzer sicher weiterarbeiten?

S•U•S•I erfindet keine Ursachen

S•U•S•I verwendet ausschließlich freigegebene Befund- und Textregeln.

Ist eine Ursache nicht eindeutig geklärt, wird dies sichtbar benannt.

Zulässig ist:

Der Dienst hat innerhalb der vorgesehenen Zeit nicht geantwortet. Die genaue technische Ursache wird geprüft.

Nicht zulässig wäre ohne Beleg:

Der Server war überlastet.

S•U•S•I unterscheidet zwischen festgestellt, wahrscheinlich und ungeklärt.

Verständliche Nachweise

S•U•S•I überführt die strukturierte Bewertung in Kundenlesefassung, PDF-Protokoll, Arbeitsprotokolleintrag und Tagesgruß.

Alle Ausgaben bleiben an Run-ID, Mandant, Rolle, Version und Hash gebunden.

S•U•S•I verändert den Befund nicht. Sie macht ihn verständlich und auffindbar.

Keine Überforderung des Nutzers

Nicht jeder technische Einzelbefund wird direkt angezeigt.

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

Ein nichtkritischer Hintergrundbefund kann im technischen Bericht verbleiben. Ein relevanter Tagesbefund wird klar und knapp erklärt.

Die Oberfläche bleibt ruhig und arbeitsbezogen.

S•U•S•I bewertet nicht den Menschen

Die Stellungnahme bezieht sich auf Funktion, Dienst, Schutz, Nachweis und Konfiguration.

Sie enthält keine Bewertung von Arbeitsleistung, Anwesenheit, Geschwindigkeit, Verhalten oder Kooperationsbereitschaft.

Ein roter Befund ist ein Systembefund.

Übergabe Cron → Agent

Cron übergibt Run-ID, Triggerzeit, Mandant, Prüfprofil, Versionen und geplanten Auftrag.

Der Agent bestätigt, dass der Auftrag angenommen, die Lease gesetzt, ein Worker aktiv und der Laufstatus überwacht wird.

Der Übergang wird protokolliert. Ein Auftrag ohne Annahme bleibt sichtbar als nicht gestartet.

Übergabe Agent → QM-Service

Der Agent liefert technische Einzelresultate, Laufstatus, Fehlerklassen, Timeouts, Retry-Informationen sowie Abschluss- oder Unterbrechungszustand.

Der QM-Service ergänzt fachlichen Soll-Ist-Vergleich, Schutzbewertung, Neutralitätsbewertung, Gesamtstatus und Maßnahmen.

Übergabe QM-Service → S•U•S•I

Der QM-Service liefert strukturierte Daten wie overall_status, Befundklassen, betroffene und unbetroffene Funktionen, economic_effect, Neutralitätsstatus, Maßnahmen und Payload-Hash.

S•U•S•I erzeugt daraus verständliche Stellungnahme, Nutzerhinweis, PDF, Arbeitsprotokoll und Tagesgruß.

Rückfluss in den nächsten Prüfzyklus

Nutzerrelevante Befunde und abgeschlossene Nachweise werden im System registriert.

Sie können ein Rollen-Audit, eine technische Nachprüfung, eine Hintergrundbeobachtung oder einen Konfigurationsauftrag auslösen.

Der nächste Cron-Lauf berücksichtigt den aktualisierten Systemstand. Dadurch schließt sich der Qualitätskreislauf.

Warum die Funktionstrennung notwendig ist

Ohne klare Trennung könnte Cron einen Auftrag bereits als erfolgreich markieren, obwohl keine Prüfung stattgefunden hat. Der Agent könnte technische Wiederholung mit fachlicher Freigabe verwechseln. Der QM-Service könnte Nutzertexte frei formulieren. S•U•S•I könnte technische Zustände verändern.

Die Rollenverteilung verhindert diese Vermischungen und begrenzt jede Komponente auf ihren Auftrag.

Keine Komponente darf alles

Cron darf starten, aber nicht bewerten.

Der Agent darf überwachen, aber nicht fachlich freigeben.

Der QM-Service darf bewerten, aber nicht Nutzer oder Vergütungen beurteilen.

S•U•S•I darf erklären, aber keine unbelegten Befunde erzeugen.

Diese vier Sätze bilden den Kern der Betriebsordnung.

Technische Durchsetzung der Trennung

Die Funktionstrennung muss sich im Hardcode widerspiegeln.

Geeignete Grenzen sind getrennte Services, getrennte Statusfelder, eindeutige Commands, klar definierte Events, eigene Capabilities, nur lesende Übergabepayloads und ein Audit jeder Zustandsänderung.

Eine gemeinsame Methode, die „alles erledigt“, wäre nicht zulässig.

Controller und Scheduler bleiben dünn. Die Fachlogik liegt in den dafür vorgesehenen Services.

Fehlerfall: Cron startet nicht

Wird kein Prüfauftrag angelegt, erhalten Agent und QM-Service keinen gültigen Lauf.

Der Tagesstart bleibt dennoch möglich. S•U•S•I kann dem konkreten Nutzer den normalen Tagescheck anbieten.

Der fehlende Cron-Lauf ist ein Hintergrundbefund und kein Nutzerfehler.

Fehlerfall: Der Agent verliert den Heartbeat

Der Agent erkennt die Unterbrechung und prüft die Lease.

Der Lauf wird kontrolliert fortgesetzt, begrenzt wiederholt oder in den Dead-Letter-Zustand überführt.

Der QM-Service darf keinen unvollständigen Lauf als grün bewerten.

Fehlerfall: Der QM-Service kann nicht bewerten

Sind strukturierte Prüfdaten unvollständig oder widersprüchlich, wird der Gesamtstatus nicht frei geraten.

Der Lauf erhält Rot-Technisch, Rot-Nachweis oder einen definierten unvollständigen Zustand.

S•U•S•I erklärt, dass keine vollständige Bewertung möglich war.

Fehlerfall: Die S•U•S•I-Textregel fehlt

Der technische Befund bleibt erhalten. Es wird keine freie Formulierung erzeugt.

Ein sicherer Fallback weist darauf hin, dass für den Befund noch keine freigegebene Kurzbewertung vorliegt.

Die fehlende Textregel wird als Konfigurations- oder Nachweisbedarf behandelt.

Governance und Neutralität

Keiner der vier Akteure darf durch den QM-Prozess Provision, Auszahlung, Rechnung, Gutschrift, Kundenbuchung oder Produktivfreigabe auslösen.

Der Wirtschaftsmodus bleibt LOCKED. Ein grüner Lauf bestätigt ausschließlich die geprüfte Betriebsbereitschaft.

Cron analysiert Systemzustände. Der Agent analysiert Laufzustände. Der QM-Service bewertet Funktionen. S•U•S•I erklärt Systembefunde.

Keine dieser Komponenten bewertet Anwesenheit, Produktivität, Arbeitsgeschwindigkeit, Verhalten oder Beschäftigtenleistung.

Die revisionsfähige Gesamtspur

Die vollständige Kette lautet:

Cron-Trigger → Prüfauftrag → Agentenannahme → Lease und Heartbeats → technische Prüfschritte → QM-Bewertung → S•U•S•I-Stellungnahme → PDF → Arbeitsprotokoll → Audit und Hash → Folgemaßnahme

Jeder Übergang bleibt über Run-ID und Korrelationsdaten nachvollziehbar.

Ein späterer Lauf überschreibt den früheren nicht.