Xolib Cross-Tenant Intelligence — Gesamtkonzept¶

Stand: 13.03.2026 | Autor: Claude (Session 68) Dieses Dokument definiert die Architektur fuer systemweites Lernen ueber alle Mandanten hinweg. Es ist der strategische Nordstern fuer Xolibs Data-Moat-Ausbau.

1. Vision: Vom Mandanten-Silo zum lernenden System¶

Problem: Jeder Mandant (Hausverwaltung) operiert in einer Datenblase. Wissen, das Mandant A durch 500 Bank-Matchings generiert, hilft Mandant B nicht. Scoring-Schwellenwerte sind statisch, nicht datengetrieben. Agents entscheiden fuer jeden Mandanten bei Null.

Vision: Xolib lernt aus JEDER Interaktion JEDES Mandanten — anonymisiert, DSGVO-konform, kartellrechtlich sauber — und gibt dieses Wissen als Systemwissen an alle zurueck. Je mehr Hausverwaltungen Xolib nutzen, desto besser wird Xolib fuer alle.

Strategische Einordnung: Dies ist die Konkretisierung von "Software = Interface, Daten = Produkt" (STRATEGY.md). Es transformiert Xolib von einer Multi-Tenant-SaaS zu einer Datenplattform mit Network Effects.

2. Bestandsaufnahme: Was wir schon haben¶

Xolib hat bereits eine erstaunlich breite Datenbasis, die nur darauf wartet, cross-tenant genutzt zu werden:

2.1 Event Store (Fundament)¶

75+ Event-Typen in 15+ Domaenen (Auth, Property, Tickets, Payments, Banking, Agents, Score, WEG, etc.)
40+ API-Routes emittieren Events
Append-only, tenant-scoped, JSONB-Payload
Bereits 3 Indexes: [tenantId, eventType], [tenantId, entityType, entityId], [tenantId, createdAt]

2.2 Agent-System (Entscheidungs-Infrastruktur)¶

8 Agenten + Orchestrator mit konfigurierbaren Autonomie-Levels
AgentRun Records: summary, actionsCount, confidence, durationMs, details JSON
AIAction Records: type, input, output, confidence, status
22 KI-Funktionen im Model-Router, alle mit statischen Parametern

2.3 Feedback & Outcome Tracking (Supervision)¶

AgentFeedback: Thumbs up/down (rating -1/0/1) pro Agent-Run
AgentOutcome: Prediction vs. Actual (isCorrect Boolean)
Ziel laut STRATEGY.md: 50.000 Feedbacks fuer ersten LoRA Fine-Tune

2.4 Score Engine (Normalisierung)¶

31 Normalisierungsfunktionen mit hartkodierten Schwellenwerten
5 Kategorien, gewichtet, mit Hash-Chain-Integritaet
ScoreFactor mit dataSource, dataVersion, dataFreshness

2.5 Bank Matching (Confidence Scoring)¶

Multi-Signal-Scoring: Betrag (0.35), Datum (0.20), Referenz (0.25), Name (0.20)
Gewichte sind statisch — koennten aus cross-tenant Daten gelernt werden
WEG-Hausgeld-Matching folgt demselben Pattern

2.6 RAG Pipeline (Wissensschicht)¶

pgvector fuer Embeddings, 4 Quelltypen (Dokumente, Agent-Findings, Knowledge, Tickets)
Tenant-scoped, aber erweitbar auf systemweite Wissensquellen

2.7 AI Usage Tracking (Kosten/Performance)¶

AIUsageLog: tenantId, functionName, model, tokens, latency, success, confidence, cost
Pro KI-Funktions-Performance-Daten

3. Die 5 Saeulen des Cross-Tenant-Lernens¶

Saeule 1: Benchmark Engine (Vergleichsdaten)¶

Was: Anonymisierte Vergleichskennzahlen ueber alle Mandanten.

Metriken (Phase 1):

Metrik	Quelle	Kohorte
Betriebskosten/qm	OperatingCostSettlement	Stadt + Gebaeudeart
Leerstandsquote	Unit.isOccupied	Stadt + Groesse
Zahlungsquote (Mieter)	Payment matched/total	Stadt + Groesse
Ticket-Loesungsdauer (Median)	Ticket.resolvedAt - createdAt	Kategorie + Groesse
Hausgeld/MEA (WEG)	WegHausgeld.sollBetrag / MEA	Stadt + WEG-Groesse
Score-Verteilung	PropertyScore	Stadt + Gebaeudeart
Heizkosten/qm	HeatingCostAllocation	Heizungsart + Region
BK-Wartungsanteil	OpCostItem (Wartung vs. Reparatur)	Gebaeudeart + Alter

Technische Architektur:

[Prisma/PostgreSQL]
       │
       ▼ (Nightly Cron, 3:00 Uhr)
[Aggregation Job]
       │
       ├── k-Anonymitaet: HAVING COUNT(DISTINCT tenant_id) >= 5
       ├── Generalisierung: Stadt (nie Strasse), Quartal (nie Tag)
       └── Rauschaddition: Laplace-Noise auf sensitive Aggregate
       │
       ▼
[Materialized Views: benchmark_*]
       │
       ▼
[Benchmark API: /api/v1/benchmarks/:metric]
       │
       ▼
[UI: "Ihr Wert vs. Markt" in KpiDonutGrid]

SQL-Beispiel (Betriebskosten-Benchmark):

CREATE MATERIALIZED VIEW benchmark_betriebskosten AS
SELECT
  date_trunc('quarter', ocs."createdAt") AS period,
  p.city,
  CASE
    WHEN p."totalUnits" <= 6 THEN 'klein'
    WHEN p."totalUnits" <= 20 THEN 'mittel'
    ELSE 'gross'
  END AS groesse_klasse,
  COUNT(DISTINCT p."tenantId") AS mandanten_count,
  COUNT(*) AS abrechnungen_count,
  AVG(ocs."totalCosts" / NULLIF(p."totalArea", 0)) AS avg_bk_per_sqm,
  PERCENTILE_CONT(0.25) WITHIN GROUP (ORDER BY ocs."totalCosts" / NULLIF(p."totalArea", 0)) AS p25,
  PERCENTILE_CONT(0.50) WITHIN GROUP (ORDER BY ocs."totalCosts" / NULLIF(p."totalArea", 0)) AS median,
  PERCENTILE_CONT(0.75) WITHIN GROUP (ORDER BY ocs."totalCosts" / NULLIF(p."totalArea", 0)) AS p75
FROM "OperatingCostSettlement" ocs
JOIN "Property" p ON ocs."propertyId" = p.id
WHERE ocs.status IN ('CALCULATED', 'SENT', 'ACCEPTED')
GROUP BY period, p.city, groesse_klasse
HAVING COUNT(DISTINCT p."tenantId") >= 5;

Wertversprechen: "Ihre BK liegen bei 2,80 EUR/qm. Der Marktmedian in Berlin (mittelgrosse Objekte) ist 3,20 EUR/qm. Sie liegen im besten Viertel."

Vorbild: Yardi Matrix (19 Mio. Einheiten, Benchmark-API, eigenstaendiges Datenprodukt).

Saeule 2: Pattern Learning (Modell-Verbesserung)¶

Was: KI-Modelle werden durch cross-tenant Feedback und Outcomes kalibriert.

2.1 Bank-Matching-Gewichte

Aktuell statisch: amount=0.35, date=0.20, reference=0.25, name=0.20

Optimierung durch cross-tenant Outcome-Daten:

1. Sammle: Alle auto-matches + manuelle Korrekturen (match/unmatch)
2. Feature-Vektor: [amountMatch, dateProximity, referenceMatch, nameMatch]
3. Label: 1 (korrekt bestaetigt) oder 0 (manuell korrigiert)
4. Logistische Regression → optimale Gewichte
5. Rollout: Neue Gewichte ersetzen statische Werte

Kein GPT noetig. Einfache logistische Regression auf dem eigenen PostgreSQL.

2.2 Score-Normalisierung

Aktuell: 31 Normalisierungsfunktionen mit fixen Breakpoints. Beispiel: normalizeBelegungsquote(rate) hat feste Stufen (>95% = 100, 90-95% = 80, etc.)

Cross-Tenant-Kalibrierung:

1. Sammle: Alle Belegungsquoten aller Mandanten
2. Berechne: Percentil-Verteilung (P10, P25, P50, P75, P90)
3. Normalisiere: Relativ zur Verteilung statt absolut
   → Score 100 = Top-10% deines Kohorten-Segments
   → Score 50 = Median deines Segments
4. Update: Quartalsweise neue Breakpoints

2.3 Agent-Entscheidungs-Kalibrierung

Jeder Agent produziert AgentRun mit confidence. Cross-tenant Outcome-Daten zeigen, ob diese Confidence kalibriert ist:

Finanzwaechter sagt: "Zahlungsausfall-Risiko 80%" (confidence)
AgentOutcome nach 30 Tagen: Zahlung eingegangen (isCorrect = false)

Ueber 1000 solcher Datenpunkte:
→ Kalibrierungskurve: Wenn Agent "80%" sagt, ist es in Wirklichkeit 62%
→ Automatische Confidence-Korrektur

2.4 Ticket-Klassifizierung

Aktuell: GPT klassifiziert Tickets ad-hoc. Cross-Tenant: Sammle alle (Ticket-Text, tatsaechliche Kategorie, tatsaechliche Prioritaet) Paare. → Fine-Tuned Classifier, der besser wird je mehr Mandanten Tickets erstellen.

Saeule 3: Template Intelligence (Best Practices)¶

Was: Die besten Vorlagen, Texte und Workflows werden systemweit geteilt.

3.1 Kommunikations-Templates

Welche E-Mail-Vorlagen fuehren zu den besten Outcomes?

Messung:
- Mahnung Template A → 45% Zahlung innerhalb 7 Tage (n=230 Mandanten)
- Mahnung Template B → 62% Zahlung innerhalb 7 Tage (n=180 Mandanten)
→ Template B wird als "Empfohlen" markiert

3.2 Wirtschaftsplan-Muster

Cross-Tenant-Analyse: Welche Kostenarten werden typischerweise vergessen?

Analyse ueber alle Wirtschaftsplaene:
- 83% enthalten "Muellabfuhr"
- 67% enthalten "Aufzugswartung"
- Nur 34% enthalten "Rueckstellungen Dach"
→ Warnung: "23 Kostenarten werden von >80% der WEGs beruecksichtigt. Ihrem Plan fehlen 3."

3.3 Beschluss-Compliance

Pattern-Erkennung ueber alle WEG-Beschluesse:

"Beschluesse vom Typ QUALIFIZIERTE_MEHRHEIT mit Kostenauswirkung > 10.000 EUR
 werden in 12% der Faelle angefochten.
 Empfehlung: Ausfuehrliche Begruendung + Kostenalternativen beifuegen."

Saeule 4: Anomalie-Erkennung (Fruehwarnsystem)¶

Was: Abweichungen eines Mandanten vom System-Normalzustand erkennen.

4.1 Kosten-Anomalien

Ihr Wasserverbrauch liegt 40% ueber dem Kohortenmedian.
→ Moegliche Ursache: Undichte Leitungen, defekte Zaehler
→ Empfohlene Aktion: Zaehlerablesung pruefen, Ingenieur-Agent auslösen

4.2 Zahlungsmuster-Anomalien

Ihre Zahlungsquote ist in den letzten 3 Monaten von 94% auf 78% gefallen.
Der Kohortentrend zeigt stabile 91%.
→ Empfohlene Aktion: Finanzwaechter-Alarm, proaktive Mieter-Kommunikation

4.3 Score-Drift

3 Ihrer Objekte zeigen einen Score-Rueckgang > 15 Punkte in 90 Tagen.
Der Kohortentrend zeigt stabilen Score (+/- 3 Punkte).
→ Deep-Dive-Empfehlung pro Objekt

Saeule 5: Systemweites Wissen (Knowledge Graph)¶

Was: Domainwissen, das einmal gelernt wird, steht allen zur Verfuegung.

5.1 Regulatorisches Wissen

WEG-Recht, BetrKV, HeizkV, CO2KostAufG, DSGVO, GEG
→ RAG-Embeddings (tenant-uebergreifend, kein personenbezug)
→ Jeder Agent hat Zugriff auf aktuelles Recht
→ Updates: Automatisch bei Gesetzesaenderungen

5.2 Handwerker-Intelligence

Anonymisierte Bewertungen + Preise ueber Mandanten hinweg:
- Firma X: Ø Bewertung 4.2/5, Ø Reaktionszeit 2.3 Tage, Preis/Stunde 65 EUR
- Region Berlin Mitte: Ø Elektrikerpreis 72 EUR/h (P25: 58, P75: 85)
→ "Ihr Elektriker liegt 20% unter dem Marktpreis bei überdurchschnittlicher Bewertung"

5.3 Energie-Benchmarks

Heizkosten/qm nach Energietraeger + Gebaeudealter + Region
→ Automatische GEG-Compliance-Einschaetzung
→ "Ihr Gebaeude (Baujahr 1978, Gas) verbraucht 145 kWh/qm.
    Vergleichbare Gebaeude: Median 128 kWh/qm."

4. DSGVO-Compliance-Framework¶

4.1 Rechtliche Grundlage¶

Verarbeitungszweck	Rechtsgrundlage	Massnahme
Benchmark-Aggregation	Art. 6(1)(f) DSGVO — Berechtigtes Interesse	Anonymisierung, k-Anonymitaet
Modell-Training	Art. 6(1)(b) DSGVO — Vertragserfuellung*	AGB-Klausel + Opt-Out
Template-Ranking	Art. 6(1)(f) — Berechtigtes Interesse	Keine personenbezogenen Daten
Anomalie-Erkennung	Art. 6(1)(b) — Vertragserfuellung	Ergebnisse nur an betroffenen Mandanten

*Wenn Benchmarking und KI-Verbesserung als Produktfeature definiert sind (AGB).

4.2 Technische Schutzmassnahmen¶

k-Anonymitaet (Minimum-Kohortengroesse):

k = 5 (Minimum: 5 verschiedene Mandanten pro Aggregat)
k = 10 (empfohlen fuer sensitive Finanzdaten)
Implementierung: HAVING COUNT(DISTINCT "tenantId") >= k
Wenn Kohorte zu klein: Aggregat wird unterdrueckt (nicht angezeigt)

Generalisierung:

Geografie:  Strasse → Stadt (nie genauer)
Zeit:       Tag → Monat oder Quartal
Groesse:    Exakte Einheiten → Klassen (1-6, 7-20, 21-50, 51+)
Betraege:   Exakt → Dezile oder Quartile

Rauschaddition (Differential Privacy, Phase 2):

Laplace-Noise auf Aggregate:
ε (Epsilon) = 1.0 (moderater Privacy-Schutz)
Sensitivitaet = max(einzelner Beitrag eines Mandanten)
Rausch ~ Laplace(0, Sensitivitaet/ε)

Bibliothek: Google Differential Privacy (C++/Go/Java)
oder OpenDP/Tumult Analytics (Python, PostgreSQL-Konnektoren)

Audit-Trail:

Jede Cross-Tenant-Abfrage wird geloggt:
- Wer hat abgefragt (System-Job oder API-Call)
- Welche Aggregate (nicht Rohdaten)
- Kohortengroesse
- Angewandtes Rausch-Level

4.3 Kartellrechtliche Absicherung (RealPage-Lektion)¶

Hintergrund: RealPage (USA) wurde vom DOJ verklagt, weil cross-property Mietpreisempfehlungen als algorithmisches Price-Fixing gewertet wurden. Settlement 2025: Nur historische Daten (>1 Jahr alt) duerfen verwendet werden.

Xolib-Regeln: 1. KEINE Mietpreis-Empfehlungen basierend auf Echtzeit-Wettbewerberdaten 2. Benchmarks sind retrospektiv (mindestens Quartalsbasis) 3. Benchmarks sind deskriptiv (Vergleichswerte), nicht preskriptiv (Preisempfehlungen) 4. Keine Weitergabe individueller Mandantendaten an andere Mandanten 5. Dokumentation der Anonymisierung in einer DSFA (Datenschutz-Folgenabschaetzung)

5. Datenmodell¶

5.1 Neue Models¶

// Cross-Tenant Benchmark (anonymisiert, aggregiert)
model SystemBenchmark {
  id            String   @id @default(cuid())
  metricKey     String   // z.B. "betriebskosten_per_sqm", "zahlungsquote"
  period        DateTime // Quartalsbeginn
  cohortCity    String?  // Stadt oder null (bundesweit)
  cohortType    String?  // Gebaeudeart: MFH, EFH, WEG, Gewerbe
  cohortSize    String?  // klein, mittel, gross

  tenantCount   Int      // Anzahl Mandanten im Aggregat (>= k)
  sampleCount   Int      // Anzahl Datenpunkte

  mean          Float?
  median        Float?
  p25           Float?
  p75           Float?
  p10           Float?
  p90           Float?
  stdDev        Float?

  noiseEpsilon  Float?   // Angewandtes DP-Epsilon (null = kein Noise)

  createdAt     DateTime @default(now())

  @@unique([metricKey, period, cohortCity, cohortType, cohortSize])
  @@index([metricKey, period])
}

// Cross-Tenant Modell-Parameter (gelernte Gewichte)
model SystemModelParam {
  id            String   @id @default(cuid())
  modelKey      String   // z.B. "bank_matching_weights", "score_norm_belegungsquote"
  version       Int      @default(1)
  parameters    Json     // Gelernte Parameter als JSON
  trainingSize  Int      // Anzahl Datenpunkte im Training
  accuracy      Float?   // Validierungs-Accuracy
  validFrom     DateTime @default(now())
  validUntil    DateTime?
  isActive      Boolean  @default(true)

  createdAt     DateTime @default(now())

  @@unique([modelKey, version])
  @@index([modelKey, isActive])
}

// Cross-Tenant Template-Performance
model SystemTemplate {
  id            String   @id @default(cuid())
  templateType  String   // "mahnung", "einladung", "beschluss", "wirtschaftsplan"
  templateKey   String   // Identifikator des Templates
  content       String?  // Template-Inhalt (anonymisiert)

  usageCount    Int      @default(0)
  successRate   Float?   // Outcome-Rate (z.B. Zahlungseingang nach Mahnung)
  avgOutcomeDays Float?  // Durchschnittliche Tage bis Outcome
  tenantCount   Int      @default(0) // Wie viele Mandanten nutzen es

  isRecommended Boolean  @default(false)

  createdAt     DateTime @default(now())
  updatedAt     DateTime @updatedAt

  @@unique([templateType, templateKey])
  @@index([templateType, isRecommended])
}

// Aggregation Job Tracking
model SystemAggregationJob {
  id            String   @id @default(cuid())
  jobType       String   // "benchmark", "model_training", "template_ranking"
  status        String   // RUNNING, COMPLETED, FAILED
  startedAt     DateTime @default(now())
  completedAt   DateTime?

  recordsProcessed Int?
  benchmarksCreated Int?
  error         String?
  metadata      Json?

  @@index([jobType, status])
}

5.2 Erweiterungen bestehender Models¶

// PropertyScore — Benchmark-Referenz
model PropertyScore {
  // ... bestehende Felder ...
  benchmarkMedian    Float?  // Median-Score der Kohorte
  benchmarkPercentile Int?   // Welches Percentil hat dieses Objekt? (0-100)
}

// Payment — Match-Feedback fuer Modell-Training
model Payment {
  // ... bestehende Felder ...
  matchCorrected     Boolean @default(false)  // Wurde Auto-Match korrigiert?
  matchCorrectedAt   DateTime?
}

6. Implementierungsarchitektur¶

6.1 Aggregation Pipeline¶

┌─────────────────────────────────────────────────────────┐
│                    PostgreSQL (Production)                │
│                                                          │
│  [XolibEvent] [Payment] [Ticket] [PropertyScore] [WEG]  │
└──────────────────────┬──────────────────────────────────┘
                       │
                       ▼ (Nightly Cron: 3:00 Uhr)
┌──────────────────────────────────────────────────────────┐
│              Aggregation Service (Node.js)                │
│                                                          │
│  1. SystemAggregationJob erstellen (status: RUNNING)     │
│  2. Benchmark-Metriken berechnen:                        │
│     - k-Anonymitaet pruefen (>= 5 Mandanten)            │
│     - Percentile berechnen (P10, P25, P50, P75, P90)    │
│     - Optional: Laplace-Noise addieren                   │
│  3. SystemBenchmark upserten                             │
│  4. Score-Normalisierungs-Breakpoints aktualisieren      │
│  5. Bank-Matching-Gewichte neu trainieren (wenn genug    │
│     korrigierte Matches vorhanden)                       │
│  6. Template-Performance-Rankings aktualisieren           │
│  7. SystemAggregationJob → COMPLETED                     │
│  8. Event emittieren: system.aggregation.completed        │
└──────────────────────────────────────────────────────────┘
                       │
                       ▼
┌──────────────────────────────────────────────────────────┐
│              SystemBenchmark (Materialized Views)         │
│              SystemModelParam (Gelernte Parameter)        │
│              SystemTemplate (Ranking)                     │
└──────────────────────────────────────────────────────────┘
                       │
                       ▼ (API + UI)
┌──────────────────────────────────────────────────────────┐
│  /api/v1/benchmarks/:metric                              │
│  → Score-Engine nutzt Benchmark-Percentile               │
│  → Bank-Matching nutzt gelernte Gewichte                 │
│  → KPI-Panels zeigen "Ihr Wert vs. Markt"               │
│  → Agents nutzen systemweites Wissen                     │
└──────────────────────────────────────────────────────────┘

6.2 Integration in bestehende Systeme¶

Score Engine:

// Aktuell (statisch):
function normalizeBelegungsquote(rate: number): number {
  if (rate >= 0.95) return 100
  if (rate >= 0.90) return 80
  // ...
}

// Neu (datengetrieben):
async function normalizeBelegungsquote(rate: number, cohort: Cohort): Promise<number> {
  const benchmark = await getBenchmark('belegungsquote', cohort)
  if (!benchmark) return staticFallback(rate) // Fallback auf alte Logik

  // Percentil-basierte Normalisierung
  if (rate >= benchmark.p90) return 100
  if (rate >= benchmark.p75) return 85
  if (rate >= benchmark.median) return 65
  if (rate >= benchmark.p25) return 40
  return 20
}

Bank Matching:

// Aktuell (statisch):
const WEIGHTS = { amount: 0.35, date: 0.20, reference: 0.25, name: 0.20 }

// Neu (gelernt):
async function getMatchingWeights(): Promise<Weights> {
  const param = await getActiveModelParam('bank_matching_weights')
  if (!param) return STATIC_FALLBACK
  return param.parameters as Weights
}

Agent Orchestrator:

// Aktuell: Statisches EVENT_AGENT_MAP
// Neu: Gewichtetes Mapping basierend auf historischer Relevanz
async function getRelevantAgents(eventType: string): Promise<AgentWeight[]> {
  const param = await getActiveModelParam('orchestrator_agent_weights')
  const weights = param?.parameters[eventType]
  if (!weights) return staticAgentMap[eventType] // Fallback

  // Nur Agents mit Relevanz > 0.3 einbeziehen
  return weights.filter(w => w.relevance > 0.3)
}

7. Phasenplan¶

Phase 1: Benchmark Foundation (2-3 Wochen)¶

Scope: - SystemBenchmark + SystemAggregationJob Prisma Models - Nightly Cron Job (einfacher Node.js-Worker) - 5 Metriken: BK/qm, Leerstandsquote, Zahlungsquote, Ticket-Loesungsdauer, Score-Verteilung - k-Anonymitaet (k=5) - Benchmark-API: GET /api/v1/benchmarks/:metric - Integration in PropertyScore: benchmarkMedian, benchmarkPercentile - KPI-Panels: "Ihr Wert vs. Markt" Anzeige

Kein GPT, kein ML, kein Differential Privacy. Reine SQL-Aggregation + API.

Wert: Sofort sichtbar fuer Kunden. Erster cross-tenant Datenpunkt. Validiert die Architektur.

Phase 2: Pattern Learning (3-4 Wochen)¶

Scope: - SystemModelParam Prisma Model - Bank-Matching-Gewicht-Optimierung (logistische Regression auf PostgreSQL) - Score-Normalisierungs-Kalibrierung (Percentil-basiert) - matchCorrected Tracking auf Payments - Agent-Confidence-Kalibrierung (wenn genug Outcome-Daten) - Agent-System-Map Gewichtung

Wert: Messbar bessere Auto-Match-Rate, realistischere Scores, genauere Agent-Entscheidungen.

Phase 3: Template Intelligence + Anomalien (3-4 Wochen)¶

Scope: - SystemTemplate Prisma Model - Mahnung-Effektivitaets-Tracking - Wirtschaftsplan-Vollstaendigkeits-Check - Anomalie-Erkennung (Kosten, Zahlungen, Score-Drift) - Anomalie-Alerts in Agent-System integrieren - WEG-spezifische Benchmarks (Hausgeld/MEA, Ruecklage-Adaequanz)

Wert: Proaktive Empfehlungen, "Best Practice"-Hinweise, Fruehwarnung.

Phase 4: Differential Privacy + Knowledge Graph (4-6 Wochen)¶

Scope: - Google DP Library oder Tumult Analytics Integration - Laplace-Noise auf sensitive Aggregate - Privacy Budget (Epsilon) Tracking - Regulatorisches Wissens-RAG (tenant-uebergreifend) - Handwerker-Intelligence - DSFA (Datenschutz-Folgenabschaetzung) dokumentieren

Wert: Formale Privacy-Garantien, erweitertes Wissens-Angebot.

Phase 5: Data Product (langfristig)¶

Scope: - Xolib Intelligence als eigenstaendiges Produkt (a la Yardi Matrix) - API-Zugang fuer externe Parteien (Banken, Investoren, Gutachter) - Score-as-a-Service - Erweitertes Benchmark-Dashboard

Wert: Neuer Umsatzstrom, staerkere Network Effects, hoeherer Exit-Multiple.

8. Wettbewerbs-Einordnung¶

Feature	Xolib (Ziel)	Immoware24	Aareon	Yardi
Cross-Tenant Benchmarks	✅ Phase 1	❌	❌ (nur intern)	✅ (Matrix)
Datengetriebene KI-Kalibrierung	✅ Phase 2	❌	❌	❌
Template Intelligence	✅ Phase 3	❌	❌	❌
Differential Privacy	✅ Phase 4	❌	❌	❓
Data Product	✅ Phase 5	❌	❌*	✅
Agent-Stack mit Feedback Loop	✅ (existiert)	❌	Teilweise	❌

*Aareon hat 100 Mio. EUR in Stonal investiert (Dokumenten-KI), aber kein oeffentliches Benchmark-Produkt.

Immoware24: Hat we-do.ai akquiriert, bietet Text-KI und Anrufbeantworter. KEIN cross-tenant Learning erkennbar. Kein Agent-Stack, kein Event Store, kein Feedback Loop.

Xolibs Vorteil: Die gesamte Infrastruktur (Event Store, Agents, Feedback, Outcome Tracking, Score Engine) existiert bereits. Der Sprung zum cross-tenant Learning ist inkrementell, nicht grundlegend.

9. Metriken & Erfolgsmessung¶

Benchmark Engine¶

Anzahl Metriken mit ausreichender Kohorte (k >= 5)
Anteil Mandanten, die Benchmark-Vergleich in der UI sehen
Engagement: Wie oft werden Benchmark-Details geoeffnet

Pattern Learning¶

Bank-Matching Auto-Match-Rate (Ziel: von ~70% auf 85%+)
Score-Kalibrierung: Korrelation Score-Aenderung ↔ tatsaechliche Outcomes
Agent-Confidence-Kalibrierung: Brier Score (naeher an 0 = besser)

Template Intelligence¶

Mahnung-Effektivitaet: Zahlungseingang-Rate pro Template
Wirtschaftsplan-Vollstaendigkeit: % fehlende Standard-Kostenarten

Anomalie-Erkennung¶

True Positive Rate: Wie oft fuehrte ein Anomalie-Alarm zu einer echten Handlung?
False Positive Rate: Wie oft war ein Alarm irrelevant?

Gesamt (Data Moat)¶

Network Effect Score: Verbessert sich Metrik X, wenn Mandant N+1 hinzukommt?
Switching Cost: Wie viel systemgelerntes Wissen verliert ein Mandant bei Abwanderung?

10. Risiken & Mitigationen¶

Risiko	Schwere	Mitigation
DSGVO-Verstoss durch Re-Identifikation	Kritisch	k-Anonymitaet (k>=5), Kohorte zu klein = unterdruecken, DSFA
Kartellrecht (RealPage-Szenario)	Hoch	KEINE Mietpreis-Empfehlungen, nur retrospektive deskriptive Benchmarks
Zu wenige Mandanten fuer valide Benchmarks	Mittel	Phase 1 startet mit bundesweiten Aggregaten (ohne Stadtfilter)
Rausch-Addition verfaelscht Benchmarks	Mittel	Epsilon-Budget sorgfaeltig waehlen, Fallback auf k-Anonymitaet
Modell-Drift bei gelernten Parametern	Mittel	Versionierung, A/B-Test, automatischer Fallback auf statische Werte
Performance-Impact durch naechtliche Aggregation	Niedrig	Read Replica oder Zeitfenster (3-5 Uhr), materialized views

11. Zusammenfassung¶

Xolib hat alle Bausteine fuer cross-tenant Intelligence bereits implementiert: - Event Store (75+ Typen) → Rohstoff - Agent-System + Feedback + Outcomes → Supervised Learning Loop - Score Engine → 31 kalibrierbare Funktionen - Bank Matching → Confidence-Gewichte zum Lernen - RAG Pipeline → Erweiterbares Wissens-System

Was fehlt, ist die Aggregationsschicht — der Layer, der aus Mandanten-Silos systemweites Wissen destilliert. Das ist kein Grundlagen-Problem, sondern ein Integrationsschritt.

Phase 1 (Benchmarks) ist in 2-3 Wochen implementierbar und liefert sofort sichtbaren Kundenwert. Jede folgende Phase baut darauf auf und vertieft den Data Moat.

Das Endergebnis: Je mehr Hausverwaltungen Xolib nutzen, desto besser wird Xolib fuer alle. Das ist der staerkste Network Effect, den eine Vertical-SaaS haben kann.