Ein erklärbares Gastprofil — aus Daten, die über jedes System im Hotel verstreut liegen.
Robert Blust · Software Engineer & Architekt
Das Problem
Ein Stammgast sieht aus wie fünf Fremde.
Warum es nicht gelöst ist
Zusammenführen ist einfach. Falsch liegen ist teuer.
Die naheliegende Lösung
Über die E-Mail abgleichen.
Scheitert an geteilten Familienadressen, an OTA-Relay-Adressen, und an jedem, der den Anbieter wechselt.
Was es kostet
Ein Gast sieht die Aufenthalte und Rechnungen eines anderen.
Eine falsche Zusammenführung ist ein Datenschutzvorfall — kein Schönheitsfehler. Also versuchen es die meisten gar nicht.
Das Schwierige ist nicht, Treffer zu finden. Sondern zu wissen, wann man einem nicht traut.
Die Idee
Speichern, was passiert ist. Herleiten, wer es war.
Datensätze sind unveränderlichKorrekturen kommen als neue Datensätze, nie als Änderung. Das Original ist immer das, was die Quelle wirklich geschickt hat.
Das Profil ist abgeleitetEine Berechnung über die Datensätze, keine Zeile, die jemand ändert. Jederzeit neu herleitbar.
Mandantengetrennt von Tag einsEine Instanz für viele Marken oder Häuser, ohne Weg dazwischen.
Quellen bleiben unangetastet. Identität ist eine Schlussfolgerung, kein Feld.
Wie entschieden wird
Nicht „passt das?“ — sondern „wie sicher sind wir?“
1 ·Geteiltes starkes Merkmal E-Mail, Telefon, Kundennummer, Ausweis → führt direkt zusammen.
2 ·Wahrscheinlichkeits-Score Führt nur über einer Schwelle zusammen, die der Betrieb selbst gesetzt hat. Sonst: Warteschlange.
3 ·Ein Mensch entscheidet Das letzte Wort — und die Entscheidung hält auch gegen neue Hinweise.
Ab Werk ist automatisches Zusammenführen ausgeschaltet. Es schlägt vor; ein Mensch entscheidet.
Die zwei Garantien
Jede Entscheidung ist erklärbar und umkehrbar.
Erklären
„Warum sind das ein Gast?“
Die vollständige Kette: welcher Matcher, wie sicher, aufgrund welcher Hinweise, wann — und wer, wenn ein Mensch oder ein Agent entschieden hat.
Umkehren
Wieder trennen — und es hält.
Eine Trennung schreibt eine dauerhafte Regel, damit neue Hinweise die beiden nicht stillschweigend wieder zusammenführen.
Das gab es, bevor eine unsichere Entscheidung überhaupt möglich war. Diese Reihenfolge war der Punkt.
Wo KI hingehört
Ein Agent ist nur ein weiterer unsicherer Matcher.
Identität kommt zuerstEin Agent, der Gastdaten nutzt, muss wissen, welcher Gast. Ohne das beantwortet er Fragen über fünf Fremde.
Abgesichert durch vorhandene MaschinerieSchwellen, Review-Queue, Umkehrbarkeit — der Agent bekommt keine Ausnahme, die ein Fuzzy-Score nicht auch bekäme.
Die Audit-Spur benennt ihnJede Entscheidung hält fest, ob das System, ein Mensch oder ein benannter Agent sie getroffen hat.
Jede Stufe gibt nach oben, was sie nicht belegen kann. Eskalation ist der Normalfall, nicht die Ausnahme.
Das Schwungrad
Jede menschliche Entscheidung ist ein beschriftetes Beispiel.
Was schon anfällt
Merkmalsvektor + menschliches Urteil.
Jede Entscheidung speichert, warum sie so bewertet wurde. Jede Review sagt bestätigt oder abgelehnt. Auf den eigenen Daten des Betriebs.
Was daraus wird
Heute Regeln, später ein Modell.
Der Matcher hängt hinter einer Methode — Kandidaten rein, bewertete Entscheidungen raus. Ein Modell ist die dritte Implementierung, kein Umbau.
Noch kein Modell, keine Pipeline. Aber die Daten fallen in der richtigen Form an.
Stand der Dinge
Die Engine steht. Fast nichts sonst.
✓Identitätsauflösung— deterministisch und wahrscheinlichkeitsbasiert, mit Review-Queue✓Erklären, Umkehren, Audit-Spur— jede Entscheidung, inklusive wer sie getroffen hat✓Gast-Timeline— was ein Gast aktuell hat, nicht nur was beobachtet wurde○Konnektoren— echte PMS-, POS-, Buchungssysteme. Als Nächstes, und der Teil, der über Nutzbarkeit entscheidet.○Agent als Steward, MCP— vorgesehen, nicht gebaut. Die Audit-Spur benennt bereits einen Agenten; noch handelt keiner.○ML-basiertes Matching— kein Modell, keine Trainings-Pipeline. Heute sind es handgeschriebene Regeln, und der Matcher heisst auch so.○Produktivbetrieb— noch keiner. Keine Kunden. Das ist eine Grundlage, kein Produkt.
Das Modell
Offener Kern — weil man nachprüfen können muss.
Open Source · Apache 2.0
Engine, Graph, API, Konnektoren.
Selbst betreiben. Genau nachlesen, wie entschieden wurde, zwei Ihrer Gäste zusammenzuführen.
Kommerziell (geplant)
Hosting, Konsole, MCP für KI-Agenten.
Der Kern hängt nie davon ab und wird nie beschnitten, um es zu verkaufen.
Eine Blackbox, die Gäste zusammenführt, würde ich nicht einsetzen.
Worum ich bitte
Sagen Sie mir, wo das falsch ist.
1 ·Ist das Problem der verstreuten Gastdaten in Ihrem Betrieb real genug, dass jemand für die Lösung zahlen würde?
2 ·Würde eine Review-Queue tatsächlich benutzt — oder ignoriert, wie jede andere Warteschlange?
3 ·Welches System müsste zuerst angebunden sein, damit das überhaupt etwas wert ist?
4 ·Würden Sie einen Agenten über eine Zusammenführung entscheiden lassen — und was müsste er Ihnen vorher zeigen?
github.com/guestgraph · ein Nein ist mir mehr wert als ein höfliches Ja