# Modellierte Vermögensentwicklung

## Zweck und Abgrenzung

`modelled_wealth_daily_v1` ist ein read-only Read Model über bereits gespeicherten
Bewertungen, bestätigten Importankern und Cash-Evidenz. Es ist **keine** dritte
Performance-Engine und darf weder TTWROR noch XIRR ersetzen.

- **Modellierte Wertentwicklung:** Standardansicht; geschätzte Entwicklung des
  bekannten Vermögens.
- **Verifizierte Anlagerendite:** bestehende strenge TTWROR-/XIRR-Berechnung. Bei
  unvollständiger Cashflow-Coverage bleibt sie `not_verified`.
- Ein Performance-Gate darf die Modellgrafik nicht unterdrücken.
- Normale GET-Aufrufe dürfen keine Provider abrufen und keine Datenbankwrites
  auslösen.

## Quellen und Doppelzählungsschutz

| Komponente | Bestätigter Anker | Modellierte Punkte |
| --- | --- | --- |
| PostFinance | `postfinance_official_import` | gespeicherte `daily_market_fx_v*`-Depotbewertung + Settlement-Cash |
| True Wealth | offizieller Gesamtwert | `truewealth_modelled_daily` |
| Krypto | keiner erzwungen | `daily_crypto_valuation_v1`; bestehende Legacy-Reihen `daily_crypto_current_valuation_v1` bleiben lesbar |
| Bankguthaben | bestätigte Cash-Snapshots | Carry-forward + bestätigte Kontobewegungen |

Für PostFinance gilt pro Tag genau eine der folgenden Varianten:

1. offizieller Gesamtanker; oder
2. Depotbewertung plus Settlement-Cash.

Der offizielle Gesamtanker wird niemals zusätzlich zu seinen Komponenten addiert.

## Historische Zeitachse

Die Zeitachse ist die Vereinigung der belastbaren Quelltage, nicht die exakte
Schnittmenge aller Kontostichtage. Für jeden Kalendertag im gewählten Zeitraum:

1. ein gespeicherter bestätigter Anker des Tages gewinnt;
2. sonst wird ein gespeicherter modellierter Tageswert verwendet;
3. fehlt ein neuer Wert, wird ausschließlich ein **älterer** Wert vorwärts
   fortgeschrieben;
4. ein späterer/heutiger Kurs wird nie rückwirkend auf einen früheren Tag gelegt;
5. fehlt für eine erwartete Komponente oder ein Konto jede Evidenz, wird nur diese
   Position als unbekannt geführt und die bekannte Teilsumme `incomplete` markiert.

Die Grafik erscheint ab zwei unterschiedlichen bestätigten oder modellierten
Evidenztagen. Unbekannte Konten bleiben als Ausschluss transparent, unterdrücken
aber bekannte Teilsummen nicht.

Die CHF-/Prozentveränderung verwendet innerhalb des gewählten Zeitraums den
ersten **vergleichbaren** Punkt: dieselben heute bekannten Hauptkomponenten und
dieselbe exakte interne Menge unbekannter Komponenten/Konten müssen bereits
enthalten sein. So wird das
spätere erstmalige Auftauchen eines Kontos nicht fälschlich als Vermögensgewinn
gezeigt. Der letzte bestätigte Importanker bleibt davon getrennt im Vertrag
sichtbar.

## Cash-Präzedenz

Der jüngste gültige Evidenztag gewinnt. Existieren am gleichen Tag mehrere
bestätigte Snapshot-Typen, gilt:

`reconciliation > manual_balance > csv_anchor_balance > calculated_balance`

Nach einem Anker wird pro Canonical Account ein gemeinsamer, deduplizierter
Bewegungsvertrag verwendet: Existiert eine aktive Budgetkonto-Projektion, ist deren
bestätigter Ledger für importierte Aktivität massgeblich. Bestätigte kanonische
Nicht-Import-Korrekturen (beispielsweise `vue_manual_cash`) bleiben zusätzlich
wirksam; bekannte CSV-/Bankimportquellen werden nicht ein zweites Mal addiert.
Ohne Budgetprojektion gilt der vollständige bestätigte kanonische Ledger. Cash-Karte
und Modellzeitreihe rufen dieselbe Hilfsfunktion auf. Bei einer Cash-Teilsumme aus
gemischten Stichtagen wird konservativ der älteste
enthaltene Komponentenstichtag ausgewiesen; die Qualität bleibt `carried`.
Ein Konto ohne eigenen
Anker oder berechenbare bestätigte Bewegung bleibt unbekannt; es erbt niemals
Werte oder Importmetadaten eines anderen Kontos desselben Anbieters.

## Importmetadaten

Haushalts-Importmetadaten werden für Cash-Karten nur anhand einer belastbaren
Canonical-Account-Zuordnung aggregiert:

- bestätigte Transaktion ist dem verknüpften Budgetkonto zugeordnet; oder
- der private Quellenreferenz-Fingerprint entspricht einer aktiven
  `household_account_source_mappings`-Zeile.

Nicht sicher zuordenbare Providerzeilen bleiben ausschließlich in der
anbieterweiten Diagnose. Sie werden nicht auf alle Konten kopiert.

## Qualitätskennzeichnungen

- `confirmed`: bestätigter Anker des Tages;
- `modelled`: gespeicherte tagesgenaue Modellbewertung;
- `carried`: ausschließlich aus älterer Evidenz vorwärts fortgeschrieben;
- `incomplete`: bekannte Teilsumme mit mindestens einer unbekannten Komponente
  oder einem unbekannten Konto;
- `unavailable`: keine belastbare Evidenz.

## Neue Importanker

Ein späterer offizieller Import bleibt append-only. Liegt davor ein modellierter
Wert derselben Komponente vor, enthält das Read Model einen Korrekturmarker. Das
gilt auch am selben Bewertungstag, wenn der Modellwert nachweislich vor dem
offiziellen Import erfasst wurde. Der Marker enthält:

- bestätigtem Wert;
- letztem vorherigen Modellwert;
- Abgleichsdifferenz.

Historische Modellzeilen werden nicht überschrieben.

Unbekannte Konten werden im öffentlichen Vertrag nur als generisches `Bankkonto`
mit optional bereits maskierter vierstelliger Endung und als response-lokaler
Schlüssel ausgegeben. Canonical Account IDs, IBANs und unmaskierte Namen bleiben
intern.