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

Drei Schichten für drei Leserbedürfnisse

Das PDF gliedert sich in drei klar getrennte, aber miteinander verbundene Ebenen:

1. Kundenlesefassung
2. Technische Prüffassung
3. Revisionsfassung

Jede Schicht beantwortet andere Fragen. Die verständliche Kurzfassung darf technische Einzelheiten reduzieren, aber niemals verfälschen. Die technische Fassung darf ausführlicher sein, ohne die Lesbarkeit der ersten Ebene zu belasten. Die Revisionsfassung bindet Ergebnis, Identität, Version, Zeit und Hash.

Alle drei Schichten gehören zu derselben unveränderlichen PDF-Fassung.

Warum ein ungegliedertes Protokoll nicht genügt

Ein rein technisches Protokoll wäre für viele Nutzer kaum verständlich. Eine ausschließlich kurze Nutzerfassung wäre für Technik, Support und Revision nicht ausreichend.

Ein unstrukturierter Mischtext würde zentrale Aussagen verdecken, technische Details unlesbar machen, Revisionsdaten verstreuen und unterschiedliche Zielgruppen überfordern.

Das Schichtenmodell sorgt dafür, dass jeder Leser die für seinen Zweck erforderliche Tiefe erhält, ohne dass unterschiedliche oder widersprüchliche Dokumente entstehen.

Schicht 1 · Kundenlesefassung

Die erste Schicht erklärt den geprüften Systemzustand in ruhiger und verständlicher Sprache. Sie richtet sich an den Nutzer im aktuellen Arbeitskontext.

Im Mittelpunkt stehen die Fragen:

• Kann ich sicher weiterarbeiten?
• Welche Funktionen wurden geprüft?
• Was ist nutzbar?
• Gibt es Einschränkungen?
• Ist eine wirtschaftliche Wirkung entstanden?
• Was geschieht als Nächstes?

Technische Rohdaten werden nur dann gezeigt, wenn sie zum Verständnis erforderlich sind.

Der Prüfkontext in der Kundenlesefassung

Die Kundenlesefassung benennt Prüftag, Nutzerrolle, Mandant oder Organisation, Prüfebene, geprüften Arbeitskontext, App- und Funktionsregisterstand sowie Start- und Endzeit in verständlicher Form.

Dadurch erkennt der Leser, worauf sich das Ergebnis tatsächlich bezieht. Ein grüner Makler-Tagescheck darf nicht als allgemeine Systemfreigabe erscheinen. Nicht geprüfte Rollen, Mandanten und Funktionsbereiche bleiben ausdrücklich außerhalb der Aussage.

Verständliche Kurzbewertung

Die zentrale S•U•S•I-Stellungnahme steht weit oben im Dokument. Sie beschreibt Gesamtstatus, betroffene Funktionen, weiterhin nutzbare Bereiche, Risiken und nächste Maßnahme.

Die wichtigste Aussage steht vor technischen Einzelheiten.

Beispielsweise:

Die für den heutigen Maklerkontext erforderlichen Kernfunktionen sind verfügbar und geschützt. Der Neutraltest wurde mit 0,00 EUR abgeschlossen. Es entstand keine wirtschaftliche Wirkung.

Ampelstatus mit Klartextgrund

Die Kundenlesefassung zeigt Grün, Gelb oder eine der vier Rot-Kategorien. Die Farbe wird immer mit einem verständlichen Grund verbunden.

Grün bedeutet vollständige Bestätigung. Gelb bedeutet, dass die Funktion grundsätzlich nutzbar ist, aber ein Teilnachweis oder eine Vertiefung offen bleibt.

Rot unterscheidet zwischen kritischer Schutzverletzung, technischem Ausfall, Nachweislücke und Konfigurationsmangel.

Eine bloße Farbgrafik ohne Erklärung ist unzulässig.

Wirtschaftlichen Schutz sichtbar bestätigen

Die Kundenlesefassung weist ausdrücklich aus:

• Neutraltest mit 0,00 EUR,
• keine Forderung,
• keine Provision,
• keine Auszahlung,
• kein realer Lead,
• keine Kundenbuchung,
• keine Produktivfreigabe.

Der Wirtschaftsmodus wird als LOCKED ausgewiesen.

Diese Aussage ist besonders bei gelben oder roten Befunden wichtig. Ein technischer Fehler darf nicht den Eindruck erzeugen, dass Geld oder Vermögen betroffen waren.

Der nächste Schritt

Bei einem nicht vollständig grünen Ergebnis erklärt das PDF, ob der Nutzer weiterarbeiten kann, welche Funktion eingeschränkt ist, ob eine Nachprüfung folgt, ob Technik oder Administration handeln muss und ob der Nutzer selbst etwas tun soll.

Häufig lautet die richtige Aussage:

Für Sie besteht derzeit kein weiterer Handlungsbedarf.

Dadurch wird technische Verantwortung nicht unnötig auf den Nutzer verlagert.

Schicht 2 · Technische Prüffassung

Die zweite Schicht dokumentiert die technische Ausführung des Laufs. Sie richtet sich an Technik, Support, Qualitätsverantwortliche, Betrieb und gegebenenfalls Revision.

Sie zeigt nicht nur den Gesamtstatus, sondern die einzelnen Funktionsbefunde. Dadurch lässt sich eine Störung gezielt analysieren, ohne Rohdaten aus verschiedenen Systemen erneut zusammensuchen zu müssen.

Funktionsdetails je Prüfpunkt

Für jede geprüfte Funktion können dokumentiert werden:

• Funktionsschlüssel,
• Anzeigename,
• Pflichtgrad,
• Route oder technischer Anker,
• Capability,
• Scope,
• Sollzustand,
• Istzustand,
• Ergebnisstatus,
• Laufzeit,
• Fehler- oder Befundcode,
• technische Maßnahme.

Die Detailtiefe richtet sich nach der Prüfebene. Ein kurzer Tagescheck enthält weniger Einzelfelder als ein vollständiges Rollen-Audit.

Status nach Modul oder Funktionsgruppe

Die technische Prüffassung ordnet Einzelprüfungen nach Funktionsgruppen, etwa Kontext und Sitzung, Dashboard, Objekte, Anfragen, Rückrufe, Termine, Partnerbereich, Zuweisungen, Audit und Nachweis sowie Neutralität und Wirtschaftsschutz.

Dadurch wird sichtbar, ob ein roter Gesamtstatus nur eine Funktion, eine Gruppe oder den gesamten Arbeitskontext betrifft.

Soll-Ist-Vergleich

Jeder technische Befund wird auf einen definierten Sollzustand bezogen. Dokumentiert werden erwartetes Ergebnis, tatsächliches Ergebnis, Abweichung und Befundklasse.

Beispiele:

• Soll: HTTP 200 · Ist: HTTP 500
• Soll: fremde Ressource wird abgewiesen · Ist: Zugriff möglich
• Soll: Hash vorhanden · Ist: Hash fehlt

Der Soll-Ist-Vergleich verhindert unscharfe oder rein subjektive Bewertungen.

Technische Befundklassifikation

Die Prüffassung unterscheidet Grün, Gelb, Rot-Kritisch, Rot-Technisch, Rot-Nachweis und Rot-Konfiguration.

Jeder Befund enthält Ursache, Wirkung, Risiko, Maßnahme und Zuständigkeit. Mehrere Befunde können gleichzeitig bestehen. Der Gesamtstatus richtet sich nach der höchsten Schutzrelevanz.

Laufzeiten, Timeouts und Wiederaufnahme

Dokumentiert werden können Startzeit je Prüfpunkt, Endzeit, Dauer, Soft-Timeout, Hard-Timeout, Retry und Wiederaufnahme.

Diese Angaben dienen ausschließlich der technischen Betriebsanalyse. Sie dürfen nicht zur Bewertung der Arbeitsgeschwindigkeit des Nutzers verwendet werden.

Technische Laufzeit und menschliche Arbeitsleistung bleiben strikt getrennt.

Empfohlene technische Maßnahmen

Die technische Fassung kann konkrete Folgemaßnahmen ausweisen, etwa Retry, Serviceprüfung, Konfigurationsergänzung, erneute Hashbildung, Rollen-Audit, Funktionssperre, Reconciliation oder Reparaturpatch.

Maßnahmen werden aus dem tatsächlichen Befund abgeleitet. Eine automatische fachliche oder wirtschaftliche Freigabe ist ausgeschlossen.

Betroffene und unbetroffene Bereiche

Die technische Fassung zeigt präzise, welche Funktionsgruppe betroffen ist, welche Prüfungen erfolgreich waren, welche Funktionen nicht ausgeführt wurden und welche Bereiche weiterhin nutzbar bleiben.

Das unterstützt eine begrenzte und verhältnismäßige Reaktion. Ein Fehler in einer Einzelfunktion darf nicht automatisch als Totalausfall behandelt werden.

Schicht 3 · Revisionsfassung

Die dritte Schicht bindet das Protokoll eindeutig an den tatsächlichen Prüflauf. Sie enthält die Informationen, mit denen Identität, Integrität, Version, Zeitpunkt und Herkunft später überprüft werden können.

Sie bildet die technische Beweis- und Vergleichsschicht und ermöglicht den Abgleich zwischen Datenbankquittung, strukturiertem Payload, PDF, Arbeitsprotokoll und Auditspur.

Run-ID als zentrale Identität

Jeder Lauf erhält eine eindeutige Run-ID. Sie verbindet Einladung oder Trigger, technischen Lauf, Stellungnahme, PDF, Arbeitsprotokoll, Auditereignisse und mögliche Folgemaßnahmen.

Eine Run-ID wird nicht wiederverwendet. Wiederholungen und Neubewertungen erzeugen neue Laufidentitäten.

Dadurch bleiben frühere und spätere Zustände eindeutig voneinander getrennt.

Nachweis-Hash und PDF-Hash

Der Nachweis-Hash bindet die strukturierten Prüfdaten. Er kann Kontextdaten, Einzelergebnisse, Gesamtstatus, Neutralitätsbestätigung, Maßnahmen und Versionsstände umfassen.

Der Hash macht stille Änderungen erkennbar. Hashalgorithmus und kanonische Datendarstellung müssen versioniert sein. Ein fehlender oder nicht reproduzierbarer Nachweis-Hash führt zu Rot-Nachweis.

Zusätzlich erhält die PDF-Datei einen eigenen PDF-Hash. Damit kann später geprüft werden, ob genau diese Datei zum Lauf gehört.

Beide Werte erfüllen unterschiedliche Aufgaben:

• Nachweis-Hash schützt den fachlich-technischen Payload.
• PDF-Hash schützt die konkret ausgegebene Datei.

Beide Werte werden in der Revisionsfassung geführt.

Versionsstände

Die Revisionsfassung dokumentiert mindestens:

• App-Version,
• Funktionsregister-Version,
• Audit-Schema-Version,
• Bewertungsregel-Version,
• S•U•S•I-Übersetzungsregel-Version,
• PDF-Layout-Version,
• gegebenenfalls Agenten- oder QM-Service-Version.

Dadurch bleibt nachvollziehbar, nach welchen Regeln das Ergebnis entstanden ist. Eine neue Regelversion verändert frühere Protokolle nicht.

Zeitstempel in UTC und Europe/Berlin

Technische Speicherung erfolgt vorzugsweise in UTC. Sichtbare Tages- und Arbeitszeiten werden in Europe/Berlin ausgegeben.

Die Revisionsfassung kann beide Angaben enthalten:

• Start UTC,
• Ende UTC,
• Start Europe/Berlin,
• Ende Europe/Berlin.

Damit bleiben technische Vergleichbarkeit, Nutzerverständlichkeit sowie Sommer- und Winterzeit miteinander vereinbar. Der Berliner Tagesbezug bestimmt den fachlichen Arbeitstag.

Nutzer-, Rollen- und Mandantenbindung

Die Revisionsfassung führt user_id, company_id, role_code, aktiven Kontext, gegebenenfalls Rollenbindung oder Assignment, Prüfebene und Triggergrund.

Diese Daten zeigen, für welchen konkreten Kontext das Ergebnis gilt. Sie dienen der technischen Zuordnung des Prüflaufs und nicht der Leistungsüberwachung.

Trigger und Prüfebene

Dokumentiert wird, wodurch der Lauf ausgelöst wurde, etwa durch ersten Login, manuellen Start, Rollenwechsel, Mandantenwechsel, Versionsänderung, Auditauftrag, Agent, Hintergrund-Cron oder Vor-Dienstbeginn-Automatik.

Zusätzlich wird die Prüfebene angegeben: Ebene 1, Ebene 2 oder Ebene 3.

Dadurch wird verhindert, dass ein kurzer Tagescheck später als vollständiges Rollen-Audit missverstanden wird.

Wirtschafts- und Neutralitätsnachweis

Die Revisionsfassung führt verbindlich:

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

Diese Angaben gehören zur beweisbaren Schutzschicht. Besonders bei roten Befunden bleibt damit sichtbar, dass kein wirtschaftlicher Außenfall ausgelöst wurde.

Unveränderlichkeit und Versionierung

Nach der finalen Erstellung wird eine PDF nicht überschrieben. Korrekturen erfolgen nicht durch stilles Editieren.

Eine inhaltliche Änderung erzeugt eine neue Bewertung, eine neue Run-ID oder Revision, eine neue PDF, einen neuen PDF-Hash und neue Zeitstempel.

Die frühere Fassung bleibt erhalten. Dadurch entsteht eine lückenlose Historie.

Unveränderlichkeit ist deshalb wichtig, weil Nutzer, Technik und Revision ursprünglichen Befund, spätere Korrektur und erneuten Test eindeutig voneinander unterscheiden müssen.

Ein still überschriebenes PDF würde Nachweise entwerten, Ursache und Reparatur vermischen sowie zeitliche Abläufe verschleiern.

Neue Revision statt Austausch

Ein möglicher Ablauf lautet:

Run 1 → PDF v1 → Befund Rot-Nachweis

Nachweisschicht repariert → neuer Prüflauf → PDF v2 → Ergebnis Grün

PDF v1 bleibt bestehen. PDF v2 kann auf die Vorgängerfassung verweisen. Die Historie zeigt, wann der Befund bestand und wann er geschlossen wurde.

Widerruf oder Ungültigkeit wird markiert

Muss ein Protokoll fachlich zurückgenommen oder als ungültig erklärt werden, bleibt die Datei erhalten.

Ergänzt wird ein neuer Revisionsvermerk, etwa:

• ungültig,
• ersetzt durch,
• widerrufen,
• technisch fehlerhaft,
• erneute Prüfung erforderlich.

Der ursprüngliche Nachweis wird nicht vernichtet. Damit bleibt die Auditspur vollständig.

Verbindung zum Arbeitsprotokoll

Das Arbeitsprotokoll enthält eine kompakte Referenz auf Run-ID, Gesamtstatus, PDF, Hash, Zeit sowie Rollen- und Mandantenkontext.

Das PDF liefert die vertiefte Darstellung. Beide müssen eindeutig zusammengehören. Ein Arbeitsprotokolleintrag ohne auffindbare PDF ist unvollständig.

Verbindung zur Datenbankquittung

Die Datenbank enthält die strukturierten Lauf- und Befunddaten. Das PDF ist die lesbare und revisionsgebundene Ausgabe dieser Daten.

Der Abgleich erfolgt über Run-ID, Payload-Hash, PDF-Hash, Version und Erstellungszeit.

Der strukturierte Datensatz bleibt die maschinenlesbare Quelle. Das PDF darf ihm nicht widersprechen.

Verbindung zur Auditspur

Auditereignisse dokumentieren die relevanten Zustandswechsel: Lauf vorbereitet, Lauf gestartet, Prüfpunkt abgeschlossen, Befund erzeugt, Stellungnahme erstellt, PDF erzeugt und Arbeitsprotokoll geschrieben.

Die PDF fasst diese Spur lesbar zusammen. Detailereignisse können über Run-ID oder Korrelations-ID aufgelöst werden.

Verbindung zu Folgemaßnahmen

Ein gelber oder roter Befund kann mit einem technischen Prüfauftrag, Reparaturpatch, Konfigurationsauftrag, einer Reconciliation oder Wiederholungsprüfung verbunden werden.

Die Revisionsfassung kann auf diese Folgeakte verweisen. Spätere Prüfungen können wiederum auf das ursprüngliche PDF Bezug nehmen.

So entsteht eine geschlossene Befund- und Reparaturkette.

Datenschutz und Zugriffsordnung

Nicht jeder Nutzer darf jede PDF öffnen. Der Zugriff richtet sich nach Mandant, Rolle, Capability, Zuständigkeit und Zweck.

Der Nutzer erhält Zugriff auf den eigenen Tagesnachweis. Technik sieht die für die Fehlerbearbeitung notwendigen Prüffassungen. Revision erhält eine geeignete lesende Sicht.

Ein Super-Admin benötigt bei mandantenbezogenen Detaildaten einen sichtbaren und auditierten Prüfkontext.

Kein öffentlich erratbarer Download

Die PDF darf nicht allein über eine fortlaufende oder erratbare ID abrufbar sein.

Erforderlich sind Authentifizierung, Mandantenprüfung, Scope-Prüfung, Downloadprotokoll und gegebenenfalls zeitgebundener Zugriff.

Fremde Rollen und Mandanten werden serverseitig abgewiesen. Der Dateipfad selbst ist kein Berechtigungsnachweis.

Datenminimierung und arbeitsrechtliche Neutralität

Das PDF enthält nur die für Prüfung und Nachweis erforderlichen personenbezogenen Angaben.

Nicht erforderlich sind Leistungskennzahlen, Anwesenheitsprofile, vollständige Verhaltenshistorien oder unnötige technische Identifikatoren.

Interne IDs können in der Revisionsschicht geführt werden. Die Kundenlesefassung bleibt verständlich und datensparsam.

Das Dokument bewertet weder Arbeitsleistung noch Geschwindigkeit, Anwesenheit, Sorgfalt oder Kooperationsbereitschaft.

Auch Laufzeiten beziehen sich ausschließlich auf das System. Das PDF ist eine technische Prüfakte und keine Beschäftigtenakte.

Technische Erzeugung

Die PDF wird erst erzeugt, wenn der Lauf einen definierten Abschlusszustand besitzt, die Einzelbefunde gespeichert, der Gesamtstatus berechnet, die Stellungnahme geprüft sowie Neutralität und Wirtschaftssperre bewertet wurden.

Ein unvollständiger Zwischenstand darf nicht als finale PDF ausgegeben werden. Für unterbrochene Läufe können eigene Zwischen- oder Statusquittungen entstehen, die eindeutig als nicht final gekennzeichnet sind.

Idempotente PDF-Erzeugung

Wiederholte Abschlussaufrufe dürfen nicht mehrere widersprüchliche PDFs erzeugen.

Für denselben finalen Payload gilt:

• bereits erzeugte PDF zurückgeben,
• Hash vergleichen,
• keine stille Neuberechnung durchführen.

Eine inhaltlich veränderte Ausgabe benötigt eine neue Revision. Dadurch bleibt die Verarbeitung stabil und nachvollziehbar.

Fehler bei der PDF-Erzeugung

Scheitert die PDF-Erzeugung, obwohl der Lauf technisch abgeschlossen wurde, geht der fachliche Befund nicht verloren.

Es entsteht Rot-Nachweis. Die PDF-Erzeugung wird kontrolliert wiederholt, während die Wirtschaftssperre aktiv bleibt.

Die fachliche Funktion wird nicht automatisch erneut vollständig ausgeführt. Zuerst wird die fehlende Nachweisschicht repariert.

Integritätsprüfung nach der Erzeugung

Nach Erstellung werden mindestens folgende Punkte geprüft:

• Datei vorhanden,
• PDF technisch lesbar,
• Seitenzahl plausibel,
• Pflichtabschnitte vorhanden,
• Run-ID vorhanden,
• Status korrekt,
• Versionsdaten korrekt,
• Zeitstempel korrekt,
• PDF-Hash gebildet,
• Datenbankverknüpfung vorhanden.

Erst danach gilt das Protokoll als vollständig erzeugt.

Empfohlener Dokumentaufbau

Die Titelseite kann S•U•S•I-QM-Protokoll, Prüftag, Prüfebene, Rollen- und Mandantenkontext, Gesamtstatus, Run-ID, Version und einen kurzen Neutralitätshinweis enthalten.

Die Kundenlesefassung enthält verständliche Stellungnahme, geprüfte Kernbereiche, Ampelstatus, sichere Weiterarbeit, wirtschaftliche Neutralität, nächste Maßnahme und Protokollhinweis.

Die technische Prüffassung enthält Funktionsmatrix, Einzelstatus, Soll-Ist-Vergleich, Laufzeiten, Befundcodes, technische Maßnahmen sowie betroffene und unbetroffene Bereiche.

Die Revisionsfassung enthält Run-ID, Nutzer-, Rollen- und Mandantenbindung, Trigger, Prüfebene, App- und Registerversion, Regelversionen, UTC- und Berlin-Zeiten, Payload-Hash, PDF-Hash sowie Neutralitäts- und Wirtschaftsstatus.

Abschlussvermerk

Der Abschlussvermerk führt Erstellungszeit, Unveränderlichkeitshinweis, gegebenenfalls Vorgänger- oder Folgerevision sowie Verweise auf Arbeitsprotokoll und Detailaudit.

Eine geeignete Formulierung lautet:

Dieses Protokoll bildet den zum Erstellungszeitpunkt abgeschlossenen Prüfstand ab. Änderungen oder Neubewertungen erzeugen eine neue, eigenständig gehashte Revision.