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

Die kompakte Tagesquittung

Das Arbeitsprotokoll enthält nicht sämtliche technischen Einzelheiten des QM-Laufs. Es fasst den abgeschlossenen Vorgang in einer kompakten und schnell erfassbaren Form zusammen.

Die ausführlichen Prüfdaten verbleiben im strukturierten Laufdatensatz, in der Auditspur, im PDF-Protokoll und in den technischen Detailbefunden.

Das Arbeitsprotokoll bildet die sichtbare Verbindung zwischen dem Arbeitstag und diesen vertiefenden Nachweisschichten. Der Nutzer erkennt auf einen Blick, dass der Systemzustand geprüft und dokumentiert wurde.

Das Ereignis

Jeder Eintrag benötigt einen eindeutigen Ereignistyp. Dieser benennt den tatsächlich stattgefundenen Systemvorgang.

Mögliche Ereignisse sind:

• QM-Tagesprüfung angeboten,
• QM-Tagesprüfung gestartet,
• QM-Tagesprüfung abgeschlossen,
• QM-Lauf unterbrochen,
• QM-Lauf fortgesetzt,
• vollständiges Rollen-Audit abgeschlossen,
• PDF-Protokoll erzeugt,
• technische Nachprüfung vorgemerkt.

Der Ereignistyp muss maschinenlesbar und fachlich verständlich sein. Eine abgeschlossene Prüfung darf nicht lediglich als allgemeines Systemereignis gespeichert werden. Der konkrete Vorgang muss später eindeutig auffindbar bleiben.

Ein Ereignis ist kein Tätigkeitsnachweis

Der Eintrag QM-Tagesprüfung abgeschlossen bedeutet, dass das System den vorgesehenen Prüfvorgang beendet hat.

Er bedeutet nicht, dass der Nutzer seine Tagesarbeit begonnen hat, anwesend war, eine bestimmte Leistung erbracht oder eine arbeitsrechtliche Pflicht erfüllt hat.

Ereignisart und Personenbewertung bleiben strikt getrennt. Der Nutzer stellt lediglich den gebundenen Arbeitskontext bereit, in dem der Systemlauf ausgeführt wird.

Dauer und Zeit

Das Arbeitsprotokoll kann die technische Dauer des QM-Laufs ausweisen, beispielsweise 13 Sekunden.

Diese Zeit beschreibt den Zeitraum vom Start bis zum Abschluss des technischen Prüfvorgangs einschließlich der vorgesehenen Systemprüfungen. Eine nachgelagerte PDF-Auslieferung kann davon getrennt betrachtet werden.

Die Laufzeit darf für technische Optimierung, Timeout-Analyse und Betriebsbeobachtung verwendet werden. Sie darf niemals als Arbeitsgeschwindigkeit des Nutzers interpretiert werden.

Sichtbare Uhrzeiten werden konsistent in Europe/Berlin ausgegeben. Sommer- und Winterzeit werden automatisch berücksichtigt. Die technische Speicherung kann intern in UTC erfolgen.

Das Protokoll kann beide Ebenen miteinander verbinden: die sichtbare Berliner Lokalzeit und den technischen UTC-Zeitstempel. Dadurch bleibt der Eintrag sowohl für den Arbeitsalltag als auch für technische Vergleiche eindeutig.

Der Zeitpunkt ist kein Anwesenheitsnachweis

Die Uhrzeit beschreibt ausschließlich, wann das Systemereignis stattfand. Sie belegt nicht, wann der Nutzer seine Arbeit aufgenommen hat, wie lange er gearbeitet hat, ob er pünktlich war oder wann er den Arbeitsplatz verlassen hat.

Der erste Login ist lediglich ein möglicher technischer Trigger. Aus dem Zeitstempel darf keine Anwesenheits- oder Arbeitszeitkontrolle abgeleitet werden.

Der gebundene Arbeitskontext

Ein Protokolleintrag gilt niemals abstrakt für das gesamte System. Er wird mindestens Nutzer, Mandant, Rolle, Prüfebene, Tagesdatum und Run-ID zugeordnet.

Ergänzend können der aktive Arbeitsraum, Objekt- oder Vorgangsscope, App-Version und Funktionsregister-Version geführt werden.

Dadurch bleibt eindeutig, für welchen konkreten Systemzustand das Ergebnis gilt.

Der Mandant begrenzt die Aussage

Ein QM-Ergebnis für einen bestimmten Mandanten gilt ausschließlich für diesen Mandanten. Es darf nicht auf eine andere Organisation oder einen anderen Super-Admin-Prüfkontext übertragen werden.

Der Eintrag wird serverseitig mandantengebunden gespeichert und angezeigt. Ein fremder Mandant darf ihn nicht allein über eine erratbare ID öffnen.

Die Rolle begrenzt den Prüfumfang

Die Rollen A, B und C besitzen jeweils ein eigenes Funktionsregister. Der Eintrag muss deshalb sichtbar machen, welche Rolle geprüft wurde.

Ein grünes Ergebnis für Rolle A · Makler bestätigt weder Rolle B · Affiliate noch Rolle C · Assistenz oder andere Rollen desselben Nutzers.

Nach einem Rollenwechsel entsteht ein neuer Arbeits- und Prüfkontext. Frühere Einträge bleiben unverändert auf ihren ursprünglichen Kontext begrenzt.

Die Run-ID verbindet sämtliche Nachweisschichten

Die Run-ID ist der zentrale Identifikator des Prüflaufs. Sie verbindet Tagestrigger, Nutzerentscheidung, technischen Lauf, Einzelbefunde, S•U•S•I-Stellungnahme, PDF-Protokoll, Arbeitsprotokolleintrag, Auditereignisse und mögliche Folgemaßnahmen.

Eine Run-ID wird niemals für einen anderen Lauf wiederverwendet. Wiederholung oder Neubewertung erzeugen eine neue Laufidentität.

Das Ergebnis

Der Protokolleintrag zeigt den Gesamtstatus des Laufs. Mögliche Zustände sind Grün, Gelb, Rot-Kritisch, Rot-Technisch, Rot-Nachweis und Rot-Konfiguration.

Eine bloße Farbkugel reicht fachlich nicht aus. Mindestens ein kurzer Klartextgrund oder ein Verweis auf die ausführliche Stellungnahme muss vorhanden sein.

Der vollständige Befund verbleibt im PDF und in der technischen Prüffassung.

Grün im Arbeitsprotokoll

Grün bestätigt für den protokollierten Kontext, dass die erforderlichen Tagesfunktionen vorhanden, die richtigen Ziele erreichbar, die Schutzbedingungen erfüllt, die Neutralität bestätigt und die Nachweise vollständig sind.

Der Eintrag darf knapp bleiben, weil keine unmittelbare Maßnahme erforderlich ist.

Beispielsweise:

QM-Tagesprüfung im Maklerkontext abgeschlossen. Kernfunktionen und Schutzbedingungen bestätigt. Keine wirtschaftliche Wirkung.

Gelb im Arbeitsprotokoll

Gelb weist auf einen offenen Teilnachweis oder eine vertiefte Prüfanforderung hin.

Der Eintrag benennt, welche Funktion grundsätzlich nutzbar ist, welcher Nachweis noch fehlt und ob eine Nachprüfung vorgemerkt wurde.

Gelb ist keine negative Bewertung des Nutzers. Es beschreibt eine kontrollierte Unvollständigkeit des Systemnachweises.

Rot im Arbeitsprotokoll

Ein roter Eintrag muss die Kategorie erkennen lassen. Er unterscheidet zwischen Schutzverletzung, technischem Ausfall, fehlender Auditspur und fehlender Konfiguration.

Die Wirkung wird auf die betroffene Funktion begrenzt. Der Eintrag verweist auf die Folgemaßnahme oder das Detailprotokoll.

Auch bei Rot darf keine persönliche Schuldzuweisung entstehen.

Neutraltest und wirtschaftlicher Schutz

Das Arbeitsprotokoll bestätigt ausdrücklich, dass der QM-Lauf mit 0,00 EUR durchgeführt wurde.

Der Eintrag kann ausweisen:

• Neutraltest: 0,00 EUR,
• wirtschaftliche Wirkung: keine,
• Wirtschaftsmodus: LOCKED.

Damit bleibt sichtbar, dass kein realer wirtschaftlicher Vorgang ausgelöst wurde.

Es entstehen keine Forderung, Provision, Gutschrift, Auszahlung, Rechnung, Kundenbuchung oder Produktivfreigabe.

Selbst bei einem roten technischen oder nachweisbezogenen Befund bleibt die wirtschaftliche Wirkung gesperrt. Ein QM-Ergebnis ist keine Provisions- oder Vergütungsentscheidung.

Keine Vergütungsfolge

Das Arbeitsprotokoll wird nicht mit Bonusregeln, Provisionsberechnung, Affiliate-Auszahlung oder Leistungsvergütung verbunden.

Ein grüner Tagescheck ist kein abrechenbares Erfolgsereignis. Eine wirtschaftliche Wirkung benötigt immer eine gesonderte fachliche, kaufmännische und revisionsfähige Freigabekette.

Hash und Integrität

Der Protokolleintrag enthält oder referenziert einen Nachweis-Hash. Dieser verbindet strukturierte Prüfdaten, Gesamtstatus, Stellungnahme, PDF und Arbeitsprotokolleintrag.

Dadurch wird erkennbar, ob der kompakte Eintrag und der ausführliche Nachweis tatsächlich zusammengehören. Der Hash macht stille nachträgliche Veränderungen sichtbar.

In der Oberfläche kann er verkürzt dargestellt werden, beispielsweise:

d96ae58d…

Im Detailprotokoll und in der Revisionsfassung bleibt der vollständige Integritätswert verfügbar. Die verkürzte Darstellung ersetzt ihn nicht.

Fehlender Hash als eigener Befund

Wurde der QM-Lauf technisch abgeschlossen, der Hash aber nicht erzeugt, liegt kein vollständig grüner Nachweis vor.

Der Befund lautet Rot-Nachweis. Die fachliche Funktion muss nicht zwingend erneut ausgeführt werden. Zunächst wird die Nachweisschicht geprüft und gegebenenfalls revisionsfähig ergänzt.

Eine Hashrekonstruktion darf keine erfundenen Daten erzeugen.

Verbindung zum PDF-Protokoll

Das Arbeitsprotokoll bleibt kompakt. Für Einzelbefunde, Prüfdaten und Revisionsdetails verweist es auf das QM-PDF.

Die Verbindung erfolgt über Run-ID, PDF-URL, PDF-Hash und Payload-Hash. Der Nutzer kann aus dem Tagesprotokoll direkt zur ausführlichen Quittung wechseln.

Ein Eintrag ohne auffindbare PDF oder Detailquittung ist unvollständig.

Arbeitsprotokoll und PDF erfüllen unterschiedliche Aufgaben:

• Arbeitsprotokoll: kompakter Tages- und Ereignisnachweis sowie schnelle Orientierung.
• PDF-Protokoll: Kundenlesefassung, technische Prüffassung und Revisionsfassung mit vollständiger Befund- und Hashbindung.

Beide gehören zusammen, dürfen aber nicht miteinander verwechselt werden.

Zugriffs- und Sichtordnung

Der Nutzer erhält Zugriff auf den eigenen Tages- und Rollenbezug. Er kann nachvollziehen, wann der Lauf stattfand, welcher Kontext geprüft wurde, welches Ergebnis vorlag und wo die PDF liegt.

Die Sicht dient Transparenz und Vertrauen. Der Nutzer muss nicht von technischen Verantwortlichen abhängig sein, um seinen eigenen Nachweis einzusehen.

Technik und Support sehen ausschließlich die für Fehleranalyse notwendigen Daten, etwa Befundklasse, Funktionsschlüssel, Laufzeit, Fehlercode, Run-ID, Hash und technische Maßnahme.

Dieser Zugriff bleibt zweckgebunden und auditiert. Ein pauschaler Anspruch auf sämtliche fachlichen oder personenbezogenen Daten besteht nicht.

Keine Leistungsakte für Vorgesetzte

Aus dem Arbeitsprotokoll dürfen keine Produktivitätsauswertungen, Anwesenheitslisten, Geschwindigkeitsrankings, Verhaltensprofile oder Beschäftigtenbewertungen abgeleitet werden.

Ein technischer Systemnachweis darf nicht in eine Personalbewertung umgedeutet werden. Die arbeitsrechtliche Neutralität gehört zum Governance-Vertrag.

Super-Admin und Revision

Ein Super-Admin erhält keine unprotokollierte Vollsicht allein aufgrund seiner Plattformrolle.

Mandantenbezogene Detailansichten benötigen einen sichtbaren Prüfkontext, passende Capability, gegebenenfalls Re-Authentifizierung und eine Auditspur.

Revision arbeitet möglichst lesend und unabhängig. Jede Einsicht bleibt auf den tatsächlichen Prüf- und Nachweiszweck begrenzt.

Das Protokoll dokumentiert das System, nicht den Menschen

Gegenstand des Arbeitsprotokolls sind Betriebsbereitschaft, Schutzwirkung, Erreichbarkeit und Auditfähigkeit.

Nicht Gegenstand sind Qualität der individuellen Arbeit, Menge erledigter Vorgänge, Geschwindigkeit, Anwesenheit, Motivation oder Verhalten.

Die Formulierungen müssen diese Grenze sichtbar einhalten.

Unzulässige Ableitungen

Aus dem Protokoll darf nicht geschlossen werden:

• Der Nutzer war um 15:05 Uhr erstmals anwesend.
• Der Nutzer benötigte 13 Sekunden für eine Aufgabe.
• Der Nutzer hat den Tagescheck zu spät ausgeführt.
• Der Nutzer arbeitet besonders zuverlässig, weil viele grüne Läufe vorliegen.
• Der Nutzer verweigert Qualitätsarbeit, weil ein Lauf abgelehnt wurde.

Keine dieser Aussagen wird durch den technischen Eintrag belegt.

Zulässige Aussage

Zulässig ist beispielsweise:

Am 22. Juli 2026 wurde um 15:05:58 Uhr im gebundenen Mandanten- und Rollenkontext ein technischer QM-Lauf abgeschlossen. Die Laufzeit des Systems betrug 13 Sekunden.

Diese Aussage bleibt sachlich, zweckgebunden und technisch überprüfbar.

Mögliche Mindestfelder

Ein Arbeitsprotokolleintrag kann mindestens folgende Felder enthalten:

event_key
run_id
user_id
company_id
role_code
active_context
qm_level
started_at_utc
completed_at_utc
display_time_europe_berlin
duration_ms
overall_status
neutral_test_amount
economic_status
statement_short
pdf_url
receipt_url
payload_hash
pdf_hash
created_at

Die technische Ausgestaltung kann variieren. Inhaltlich müssen Kontext, Ergebnis, Zeit und Nachweis eindeutig bleiben.

Nutzerentscheidung und Laufstatus getrennt halten

Eine freiwillige Ablehnung ist kein technischer Fehler. Deshalb werden Einladungs- oder Entscheidungsstatus, technischer Laufstatus und fachlicher Gesamtstatus getrennt gespeichert.

Ein möglicher Zustand lautet:

invitation_status = dismissed_today
run_status = not_started
overall_status = not_applicable

Dadurch entsteht kein falscher roter oder negativer Protokolleintrag.

Korrekturen erzeugen neue Ereignisse

Ein bestehender Arbeitsprotokolleintrag wird nicht still überschrieben.

Wird ein Befund später korrigiert, entstehen ein neuer Prüflauf, eine neue Run-ID, ein neues PDF, ein neuer Hash und ein neuer Protokolleintrag.

Der neue Eintrag kann auf seinen Vorgänger verweisen. Dadurch bleibt die Entwicklung des Systemzustands vollständig nachvollziehbar.

Beispiele

Grün:

Ereignis: QM-Tagesprüfung abgeschlossen
Kontext: Mandant 7 · Rolle A · Makler
Dauer: 13 Sekunden
Ergebnis: Grün. Kernfunktionen, Sitzung und Schutzbedingungen bestätigt. Neutraltest 0,00 EUR. Wirtschaft: LOCKED.
Nachweis: PDF und Hash hinterlegt.

Gelb:

Ereignis: QM-Tagesprüfung abgeschlossen
Kontext: Mandant 7 · Rolle B · Empfehlungspartner
Ergebnis: Gelb. Partnerbereich und eigene Empfehlungen sind nutzbar. Die vollständige Dokumentation des negativen Fremdzugriffstests ist noch offen. Kein unmittelbares Daten- oder Wirtschaftsrisiko.
Folge: Rollen-Audit vorgemerkt.

Rot-Technisch:

Ereignis: QM-Tagesprüfung mit technischem Befund abgeschlossen
Kontext: Mandant 7 · Rolle A · Makler
Ergebnis: Rot-Technisch. Der Rückrufdienst antwortete nicht innerhalb der festgelegten Zeit. Andere geprüfte Arbeitsbereiche bleiben verfügbar.
Wirtschaft: Keine Wirkung, LOCKED.
Folge: Fehleranalyse und kontrollierte Wiederholung vorbereitet.

Rot-Nachweis:

Ereignis: QM-Nachweis unvollständig
Ergebnis: Die fachliche Prüfung wurde abgeschlossen. Die Verbindung zwischen PDF, Auditspur und Payload-Hash konnte nicht vollständig bestätigt werden.
Folge: Revisionsprüfung eingeleitet.

Nutzen für Nutzer, Technik und Revision

Für den Nutzer schafft das Arbeitsprotokoll eine transparente Tagesquittung, schnelle Information über den Systemzustand, direkten Zugriff auf PDF und Detailnachweis sowie Klarheit über die fehlende wirtschaftliche Wirkung.

Für Technik und Support ermöglicht es eine eindeutige Run- und Kontextzuordnung, schnell auffindbare Befunde, technische Laufzeitanalyse sowie die Verbindung zu PDF, Audit und Hash.

Für Revision und Betreiber entsteht eine unveränderliche Ereignisspur mit klarer Versions- und Zeitbindung, dokumentierter Neutralität, kontrollierter Zugriffsordnung und Schutz vor unzulässiger Personen- oder Leistungsinterpretation.