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

Das QM liefert Diagnose und Nachweis

Das Qualitätsmanagement erzeugt Prüfdaten, Einzelbefunde, Gesamtstatus, Soll-Ist-Vergleiche, technische Empfehlungen, Prüfaufträge, PDF-Protokolle, Arbeitsprotokolleinträge, Run-IDs, Hashes und Auditspuren.

Diese Ergebnisse schaffen eine belastbare Entscheidungsgrundlage. Sie ersetzen jedoch nicht die zuständige fachliche, rechtliche oder wirtschaftliche Entscheidung.

Das QM beschreibt:

• was technisch möglich ist,
• was geschützt funktioniert,
• welche Nachweise vorliegen,
• welche Risiken bestehen,
• welcher nächste Prüfschritt sinnvoll ist.

Es entscheidet nicht eigenständig, ob ein Geschäftsvorgang verbindlich freigegeben wird.

Diagnose ist nicht Entscheidung

Eine Diagnose stellt einen Zustand fest. Eine Freigabe verändert einen fachlichen, rechtlichen oder wirtschaftlichen Zustand.

Diese beiden Vorgänge müssen technisch und organisatorisch getrennt bleiben.

Eine QM-Diagnose wie:

Die Exposé-Freigabefunktion ist erreichbar und geschützt.

bedeutet nicht:

Das konkrete Exposé wird automatisch freigegeben.

Ebenso bedeutet eine technisch grüne Vergütungsprüfung nicht, dass eine Provision anerkannt oder ausgezahlt werden darf.

Die Betriebsbereitschaft einer Entscheidungsfunktion ist etwas anderes als die konkrete Entscheidung selbst.

Die harte Grenze zur Produktivwirkung

Zwischen Prüfen, Bewerten und Nachweisen einerseits sowie fachlichem Freigeben, wirtschaftlichem Anerkennen, rechtlichem Binden und produktivem Ausführen andererseits liegt eine ausdrückliche Sperrschicht.

Diese Grenze muss serverseitig, rollenbezogen, capability-gebunden, auditierbar und Fail-Closed umgesetzt sein.

Eine grüne Ampel darf diese Sperre nicht automatisch öffnen. Auch Cron, Agent, QM-Service oder S•U•S•I dürfen sie nicht selbstständig übergehen.

Die Sperre wirkt durch die gesamte technische Kette

Es genügt nicht, einen Freigabebutton auszublenden.

Die Trennung muss in Route, Middleware, Controller, Service, Command, Datenbank, Statusübergang und Audit wirksam sein.

Ein direkter URL-Aufruf oder manipulierter Request darf die Freigabegrenze nicht umgehen. Die Freigabe benötigt eine eigene Capability und einen zulässigen Prozesszustand.

Fehlt eine Voraussetzung, wird der Vorgang serverseitig abgewiesen.

Auch vollständiges Grün öffnet die Sperre nicht

Selbst wenn alle Prüfschritte erfolgreich, keine technischen Fehler vorhanden, Neutralität bestätigt und alle Nachweise vollständig sind, bleibt die Produktivwirkung zunächst gesperrt.

Grün bedeutet lediglich:

Die Freigabestrecke könnte durch eine berechtigte Stelle sicher verwendet werden.

Erst eine ausdrücklich autorisierte Entscheidung darf den nächsten Zustand auslösen.

Diese Entscheidung erhält einen eigenen Akteur, Grund, Zeitpunkt, Status und eine eigene Auditspur.

Keine rechtlich bindende Anerkennung

Ein QM-Lauf darf keine rechtsverbindliche Erklärung abgeben. Dazu gehören Vertragsannahme, Leistungs- oder Forderungsanerkennung, Abnahme, Genehmigung, Widerrufsverzicht oder verbindliche Freigabe.

Ein technischer Status kann bestätigen, dass die dafür vorgesehene Funktion arbeitet. Er darf aber die erforderliche Willenserklärung einer berechtigten Person oder Stelle nicht ersetzen.

Rechtsverbindliche Entscheidungen benötigen eindeutige Willensbildung, einen berechtigten Akteur, einen konkreten Gegenstand, dokumentierten Zeitpunkt, gegebenenfalls Re-Authentifizierung und eine eigene Quittung.

Keine automatische Vertrags- oder Leistungsanerkennung

Ein erfolgreich geprüfter Geschäftsprozess bedeutet nicht, dass die zugrunde liegende Leistung anerkannt ist.

Eine technisch erfasste Empfehlung begründet noch keinen Provisionsanspruch. Ein vorhandenes Dokument ist noch keine fachliche Anerkennung. Ein vollständiges Exposé ist noch keine Veröffentlichungsfreigabe. Ein erreichbarer Rechnungspfad erzeugt noch keine Forderung.

Das QM bestätigt die Funktionsfähigkeit der Strecke. Die Anerkennung bleibt ein eigenständiger fachlicher Vorgang.

Keine realen Kundenereignisse

Der QM-Lauf erzeugt keine echten Kundenbuchungen.

Ausgeschlossen sind reale Anfragen, Rückrufaufträge, Terminbuchungen, Reservierungen, Interessentenzuordnungen und Vertragsvorbereitungen.

Verwendet werden ausschließlich neutrale Testdaten. Diese müssen eindeutig als Prüfkontext gekennzeichnet sein und dürfen nicht in produktiven Kundenlisten, Vertriebsstatistiken, Arbeitskörben oder Umsatzprognosen erscheinen.

Ein technischer Test darf prüfen:

Kann ein Rückrufvorgang sicher angenommen, zugeordnet und quittiert werden?

Er darf nicht bewirken:

Ein realer Kunde erwartet nun tatsächlich einen Rückruf.

Test und Produktivvorgang erhalten getrennte Datentypen, Statuswerte, Ereignisse und Auditspuren.

Keine Abrechnungsfreigabe

Ein grüner QM-Lauf gibt keine Rechnung frei. Das QM darf weder Rechnungen erzeugen oder freigeben noch Rechnungsnummern vergeben, Forderungen buchen, Zahlungsstatus verändern oder Mahnprozesse auslösen.

Ein grüner Billing-Test bestätigt ausschließlich technische Erreichbarkeit, Schutz, Neutralität und Nachweisfähigkeit.

Die reale Abrechnung benötigt eine eigene Vertragsprüfung, Leistungsprüfung, Steuerlogik, Rechnungsfreigabe sowie Buchungs- und Ledgerkette.

Zahlungsanbieter bleiben außerhalb der QM-Entscheidung

Stripe, SEPA oder andere Zahlungsdienste können technisch geprüft werden. Der QM-Lauf darf aber keine echte Zahlungsanforderung, Abbuchung, Erstattung, Gutschrift oder Lastschrift auslösen.

Test- und Produktivschlüssel bleiben getrennt. Der Wirtschaftsmodus bleibt LOCKED.

Eine produktive Zahlungsfreigabe benötigt eine gesonderte und versiegelte Abnahmephase.

Keine Provisionsentscheidung

Das QM kann prüfen, ob Partneridentität, Herkunft, Zuordnung, Statusprojektion und Nachweisfunktion technisch korrekt arbeiten.

Daraus entsteht keine automatische Provision, Differenzprovision, Empfehlungsvergütung, Erfolgsprämie oder Gutschrift.

Ein Klick, eine Empfehlung oder ein technisch bestätigtes Ereignis reicht für eine wirtschaftliche Anerkennung nicht aus.

Erforderlich bleiben ein fachliches Erfolgsereignis, belastbare Evidenz, zulässige Kontaktgrundlage, berechtigte Prüfung und kaufmännische Freigabe.

Keine automatische Auszahlung

Auch nach einer späteren fachlichen Anerkennung darf das QM selbst keine Auszahlung auslösen.

Eine Auszahlung benötigt einen freigegebenen Anspruch, korrekte Empfängeridentität, geprüfte Bank- oder Zahlungsdaten, einen Abrechnungsbeleg, eine Ledgerbuchung und gegebenenfalls das Vier-Augen-Prinzip.

QM, Cron, Agent und S•U•S•I bleiben außerhalb dieser Entscheidung. Sie können lediglich feststellen, ob die benötigten Systemkomponenten technisch bereitstehen.

Keine automatische Exposé-Freigabe

Das QM kann prüfen, ob Snapshot, Medien, Grundrisse, Render, Preflight, Hash und Manifest technisch korrekt vorliegen.

Ein grüner Test darf dennoch nicht selbstständig das Exposé freigeben, die Safe-Fassung schließen, die öffentliche Auslieferung aktivieren oder das Objekt veröffentlichen.

Die finale Freigabe benötigt eine zuständige Rolle, eine konkrete Fassung, eine sichtbare Schlussprüfung, ausdrückliche Bestätigung und eine eigene Freigabequittung.

Keine automatische Widget- oder Landingpage-Veröffentlichung

Auch wenn die öffentliche Strecke technisch grün geprüft wurde, bleibt die konkrete Veröffentlichung gesperrt.

Die Aktivierung benötigt ein freigegebenes Objekt, eine freigegebene Exposé-Fassung, zulässige Domain- oder Placementbindung, einen berechtigten Akteur und Audit.

Das QM bestätigt die technische Veröffentlichungsfähigkeit. Es veröffentlicht nicht eigenständig.

Was das QM tun darf

Das QM darf Prüfaufträge erzeugen, etwa für ein vollständiges Rollen-Audit, die Prüfung einer Hashbindung, eine Konfigurationskontrolle, einen Service-Retry, eine Reconciliation oder Browserabnahme.

Der Auftrag beschreibt Ursache, Prüfziel, betroffene Funktion, Priorität und erwarteten Nachweis.

Ein Prüfauftrag ist keine Reparatur- oder Freigabeerlaubnis.

Das QM darf Befunde als Grün, Gelb, Rot-Kritisch, Rot-Technisch, Rot-Nachweis oder Rot-Konfiguration klassifizieren und Ursache, Auswirkung, Risiko sowie nächste technische Maßnahme beschreiben.

Es darf strukturierte Laufdaten, Stellungnahmen, PDF-Protokolle, Arbeitsprotokolle, Hashes und Auditereignisse erzeugen.

Diese Nachweise können Grundlage einer späteren autorisierten Entscheidung sein. Sie sind aber nicht selbst die Entscheidung.

Vorsorgliche Sperre bei Rot-Kritisch

Bei Rot-Kritisch darf die betroffene Funktion zum Schutz Fail-Closed gesperrt werden.

Diese Sperre ist eine technische Schutzmaßnahme. Sie ist keine fachliche Ablehnung, keine wirtschaftliche Entscheidung und keine Sanktion gegen den Nutzer.

Die Sperre bleibt auf die betroffene Funktion begrenzt.

Eine erneute Freigabe erfolgt erst nach Ursachenklärung, Reparatur, negativen und positiven Tests sowie berechtigter Bestätigung.

Die Entscheidung bleibt bei einer verantwortlichen Stelle

Fachliche und wirtschaftliche Freigaben benötigen eine eindeutig benannte Verantwortung.

Dazu gehören beispielsweise Exposé-Freigabe, kaufmännische Prüfung, Provisionsanerkennung, Zahlungsfreigabe, Vertragsannahme oder Objektveröffentlichung.

Jede Entscheidung muss einem realen Akteur zugeordnet sein.

Das System hat freigegeben ist für rechtlich oder wirtschaftlich relevante Vorgänge nicht ausreichend.

Keine Delegation der Verantwortung an einen Algorithmus

Das QM darf Empfehlungen und Befunde liefern. Die verantwortliche Stelle muss den konkreten Vorgang prüfen, den Kontext verstehen und die Entscheidung ausdrücklich treffen.

Dies gilt besonders für rechtliche Bindung, wirtschaftliche Anerkennung, Provisionsanspruch, Auszahlung und Veröffentlichung.

Automatisierung darf vorbereiten und absichern. Sie darf die Verantwortungszuordnung nicht unsichtbar machen.

Prüf- und Freigabe-Capability bleiben getrennt

Eine Prüf-Capability ist nicht automatisch eine Freigabe-Capability.

Beispielsweise:

expose.check ≠ expose.approve

und:

affiliate.settlement.inspect ≠ affiliate.payout.approve

Diese Trennung verhindert Selbstfreigabe. Sensible Entscheidungen können zusätzlich Re-Authentifizierung, Vier-Augen-Prinzip, Begründung und Audit erfordern.

Vom Befund zur Freigabe

Eine mögliche Freigabekette lautet:

QM-Lauf abgeschlossen → Befund und Nachweis vorhanden → verantwortliche Fachstelle prüft den konkreten Vorgang → Freigabebedingungen werden geprüft → ausdrückliche Entscheidung → Freigabeereignis → produktiver Zustandsübergang → eigene Quittung und Auditspur

Kein Glied wird übersprungen.

Die Freigabe erhält eine andere Ereignisart und eine andere Run- oder Command-Referenz als der QM-Lauf.

Dadurch bleibt nachvollziehbar, was das System geprüft und wer anschließend entschieden hat.

Unterschiedliche Ereignisse

Ein QM-Abschluss kann als qm_run_completed geführt werden.

Die fachliche Freigabe lautet beispielsweise release_approved, die wirtschaftliche Anerkennung settlement_approved und eine Auszahlung payout_authorized.

Diese Ereignisse dürfen nicht in einem einzigen Status zusammenfallen.

Jedes Ereignis besitzt einen eigenen Akteur, Zweck, Voraussetzungen und Nachweis.

Keine Freigabe durch Statusvererbung

Ein grüner QM-Status darf nicht automatisch in approved, published, payable, paid oder accepted übersetzt werden.

Die technische Grünstellung bleibt ausschließlich qm_passed oder eine vergleichbare Diagnose.

Diese Trennung verhindert unkontrollierte Seiteneffekte.

Selbstprüfung ist nicht Selbstfreigabe

Eine Person kann einen Vorgang vorbereiten oder prüfen. Sie darf nicht automatisch dieselbe fachliche oder wirtschaftliche Freigabe erteilen.

Je nach Risiko bleiben Prüfung und Freigabe, Erfassung und Auszahlung sowie technische Diagnose und kaufmännische Anerkennung getrennt.

Das QM kann diese Trennungsbedingungen prüfen. Es ersetzt sie nicht.

Cron, Agent und S•U•S•I bleiben außerhalb der Freigabekette

Cron startet Prüfungen. Der Agent überwacht Läufe. Beide dürfen keine Freigabeentscheidung, Provisionsanerkennung, Veröffentlichung oder Auszahlung vornehmen.

Auch wiederholt grüne Läufe erweitern ihre Befugnisse nicht.

S•U•S•I darf formulieren:

Die technischen Voraussetzungen für die weitere fachliche Prüfung sind bestätigt.

Sie darf ohne autorisierte Entscheidung nicht erklären:

Der Vorgang ist freigegeben und rechtsverbindlich anerkannt.

Die Sprache muss die Systemgrenze sichtbar machen.

Wirtschaftsmodus bleibt LOCKED

Während der gesamten QM-Strecke bleibt der Wirtschaftsmodus gesperrt. Der Test arbeitet mit 0,00 EUR.

Es entstehen keine Forderung, Buchung, Provision oder Auszahlung.

Erst eine nachgelagerte autorisierte Wirtschaftskette darf einen anderen Modus verwenden. Dieser Wechsel wird ausdrücklich protokolliert.

Der QM-Lauf selbst bleibt unverändert neutral.

Kein automatischer Wechsel in den Produktivmodus

Ein grüner Abschluss darf den Wirtschaftsmodus nicht automatisch entsperren.

Die Entsperrung benötigt einen eigenen Command, eine passende Capability, fachliche Freigabe, gegebenenfalls Re-Authentifizierung und Audit.

Fehlt diese Kette, bleibt die Wirtschaftssperre aktiv.

Selbst eine Fehlkonfiguration darf diese Schutzschicht nicht umgehen. Würde Grün versehentlich eine produktive Wirkung auslösen können, wäre dies ein Rot-Kritisch-Befund.

QM-Protokoll ist keine Freigabeurkunde

Das PDF-Protokoll dokumentiert Prüfumfang, Systemstatus, Befunde, Neutralität und Nachweise.

Es ist keine Vertragsurkunde, Zahlungsanweisung, Provisionszusage, Kundenbestätigung oder Produktivfreigabe.

Eine geeignete Klarstellung lautet:

Dieses Protokoll bestätigt ausschließlich den geprüften technischen Systemzustand. Es ersetzt keine fachliche, rechtliche oder wirtschaftliche Freigabe.

Arbeitsprotokoll bleibt Systemnachweis

Auch der Arbeitsprotokolleintrag dokumentiert ausschließlich QM-Lauf, Status, Kontext und Nachweis.

Ein grüner Eintrag darf keine nachgelagerten Geschäftsvorgänge automatisch starten.

Nachgelagerte Systeme müssen eine eigene Freigabereferenz verlangen.

Diagnoseautomation ersetzt keine Managemententscheidung

Das Management behält die Verantwortung für wirtschaftliche Folgen, Freigaben, Risikobewertungen im konkreten Geschäftsfall sowie personelle oder organisatorische Entscheidungen.

Das QM verbessert diese Entscheidungen durch belastbare Daten. Es nimmt sie dem Management aber nicht ab.

Diagnoseautomation ist Unterstützung, nicht Verantwortungsersatz.

Technische Statusordnung

Diagnose- und Freigabestatus werden getrennt gespeichert.

Beispielsweise:

qm_status = green
release_status = pending
economic_status = locked

Erst eine spätere Entscheidung kann setzen:

release_status = approved

Auch wirtschaftliche Anerkennung und Auszahlung bleiben getrennt:

settlement_status = approved
payout_status = not_authorized

Diese Mehrfachstatus verhindern ungewollte Zustandsvererbung.

Eigene Services und Auditspuren

Der QM-Service prüft, bewertet und weist nach. Der Release-Service prüft Freigabebedingungen, schreibt die Entscheidung und schließt die Fassung.

Billing- oder Settlement-Service übernehmen wirtschaftliche Anerkennung, Buchung und Ledger. Der Payout-Service autorisiert und führt Auszahlungen aus.

Kein Service übernimmt still die Aufgabe eines anderen.

Entsprechend dokumentiert das QM-Audit den Systemtest, das Release-Audit die fachliche Freigabe, das Economic-Audit Anerkennung und Buchung sowie das Payout-Audit die Auszahlung.

Die Spuren werden über Referenzen verbunden, aber nicht vermischt.

Technisch freigabefähig, aber noch nicht freigegeben

Die richtige S•U•S•I-Aussage lautet:

Die technischen Voraussetzungen wurden vollständig bestätigt. Der Vorgang bleibt bis zur ausdrücklichen fachlichen Freigabe im geschützten Status.

Ungeeignet wäre:

Alles ist freigegeben.

Zwischen technisch grün und fachlich freigegeben kann ein eigener Status liegen, beispielsweise ready_for_review oder release_ready.

Dieser Status bedeutet, dass die technischen Voraussetzungen erfüllt sind, die Entscheidung aber noch offen bleibt.

Die offene Entscheidung bleibt sichtbar

Dashboard oder Fachmaske können anzeigen:

• technisch geprüft,
• Nachweise vollständig,
• Freigabe noch offen,
• zuständige Stelle.

Der Nutzer erkennt damit: Die Technik ist bereit, der Geschäftsprozess wartet jedoch noch auf eine bewusste Entscheidung.

Governance und Revision

Jede Freigabeentscheidung benötigt einen realen Akteur.

Gespeichert werden mindestens approved_by, approved_at, approval_reason, subject_type, subject_id, Vorgängerstatus, neuer Status sowie Audit- oder Korrelations-ID.

Ein Systemkonto oder Agent darf nicht als fachlicher Entscheider erscheinen, sofern keine ausdrücklich freigegebene Regel dies vorsieht. Für den hier beschriebenen QM-Umfang bleibt eine autonome Produktivfreigabe ausgeschlossen.

Sensible Entscheidungen können eine Re-Authentifizierung oder ein Vier-Augen-Prinzip verlangen.

Revision muss nachvollziehen können, welcher QM-Lauf vorausging, welche Befunde vorlagen, wer anschließend entschieden hat, welche Wirkung ausgelöst wurde und ob die erforderlichen Rollen getrennt waren.

Auch künftige Automatisierung bleibt begrenzt

Spätere Automatisierung darf Prüfungen starten, Ergebnisse vorstrukturieren, Verantwortliche informieren und Freigaben vorbereiten.

Sie darf ohne gesonderte, ausdrücklich freigegebene Fachregel weder rechtsverbindlich anerkennen noch wirtschaftlich buchen, auszahlen oder veröffentlichen.

Eine neue Version darf nicht beiläufig aus Diagnose eine Freigabe machen.

Jede Erweiterung benötigt ein neues Pflichtenheft, Risikoanalyse, Capability-Konzept, technische Abnahme, Auditvertrag und gegebenenfalls rechtliche Prüfung.

Bis dahin bleibt die Produktivfreigabe manuell, ausdrücklich und revisionsfähig dokumentiert.