Zustandsmaschine

Lebenszyklus einer Email: Zustände und Übergänge

Die Aktionsmatrix entscheidet, was mit einer Email passieren soll. Aber wann genau befindet sich eine Email in welchem Zustand? Und welche Übergänge sind erlaubt?

Das email2rag-System definiert eine Zustandsmaschine (en: State Machine) mit möglichen Zuständen. Jede Email durchläuft eine Teilmenge davon, je nachdem welchen Weg sie durch die Pipeline nimmt.

fetchedabgeholt

parsedStruktur zerlegt

classifiedKategorie bestimmt

indexedVektoren gespeichert

awaiting_reviewEntwurf wartet

approvedfreigegeben

sentversendet

archivedabgelegt

rejectedabgelehnt

failedFehler

partially_indexedQdrant-Fehler

Relevanz: "Kern" sind die Zustände, die jede Email durchläuft. "Betrieb" sind Zustände, die nur bei Fehlern oder Teilausfällen auftreten.

Zustand	Bedeutung	Wer setzt ihn	Nächster Schritt	Relevanz
`fetched`	Vom Mailserver abgeholt	IMAP-Poller	MIME-Parsing	Kern
`parsed`	Struktur zerlegt (Header, Body, Anhänge)	ParseStep	LLM-Klassifikation	Kern
`classified`	Kategorie und Konfidenz bestimmt	ClassifyStep	Indexierung	Kern
`indexed`	Vektoren und Chunks gespeichert	ChunkStep	Entwurf oder Archivierung	Kern
`draft_ready`	Entwurf generiert, bereit für Operator-Review	DraftStep	Review (awaiting_review)	Kern
`awaiting_review`	Entwurf liegt zur menschlichen Prüfung bereit	DraftStep	Freigabe oder Ablehnung	Kern
`approved`	Mensch hat den Entwurf freigegeben	Operator (Dashboard)	Versand	Kern
`sent`	Antwort wurde versendet	SMTP-Worker	Archivierung	Kern
`rejected`	Entwurf wurde abgelehnt	Operator (Dashboard)	Neuer Entwurf oder Archivierung	Kern
`archived`	Verarbeitung abgeschlossen, abgelegt. Wer den Übergang auslöst, hängt von der Archivierungs-Regel der Kategorie ab: entweder bestätigt der Operator manuell, oder ein Hintergrundlauf archiviert automatisch nach Ablauf der hinterlegten Aufbewahrungsfrist	Operator oder Retention-Cron	Keine (Endzustand bis Retention-/DSGVO-Löschung)	Kern
`failed`	Verarbeitung fehlgeschlagen	PipelineErrorHandler	Retry oder Dead Letter	Betrieb
`partially_indexed`	Kern verarbeitet, aber Qdrant/ArangoDB fehlt	PipelineErrorHandler	Automatisches Nachindexieren	Betrieb
`deleted`	Endzustand nach Admin- oder Retention-/DSGVO-Löschung. Benutzer-initiiertes Löschen ist systemweit verboten (siehe Zielsystem und Sicherheit-DSGVO)	Admin (CLI/UI) oder Retention-Cron	Keine (Endzustand, MariaDB-Zeile entfernt nach Speicher-Pfad aus E3-Normregister)	Betrieb

Der Hauptweg

Die meisten Emails durchlaufen den Hauptweg: fetched → parsed → classified → indexed → awaiting_review → approved → sent. Das ist der vollständige Pfad von der Ankunft bis zur versendeten Antwort.

Im Testsystem befinden sich Emails in verschiedenen Zuständen: einige warten auf Freigabe (awaiting_review), andere sind archiviert oder bereits freigegeben. Die Verteilung ändert sich mit jeder verarbeiteten Email.

Abzweigungen und Sonderwege

Nicht jede Email geht den ganzen Weg. Es gibt Abzweigungen:

Archivierung: Spam, Newsletter und Information gehen nach der Klassifikation direkt in den Zustand archived, ohne Entwurf.
Ablehnung: Ein Mensch kann einen Entwurf ablehnen (rejected). Die Email bleibt gespeichert, bekommt aber keinen neuen Entwurf.
Teilweise indexiert: Wenn die Vektorspeicherung in Qdrant fehlschlägt, landet die Email bei partially_indexed statt indexed. Die Pipeline läuft trotzdem weiter. Konkretes Beispiel: MariaDB hat die Email gespeichert, die Kategorie wurde gesetzt, aber Qdrant war beim Embedding-Versuch nicht erreichbar. Der Zustand partially_indexed hält den Teilfortschritt fest, damit ein späterer Indexer-Lauf nur die fehlenden Schritte nachzieht.
Fehlgeschlagen: Bei schwerwiegenden Fehlern (LLM-Timeout, Parsing-Fehler) wird der Status auf failed gesetzt.

Die unsichtbare Grenze: Wann SEEN gesetzt wird

Ein kritisches Detail ist die Commit-Grenze (en: Commit Boundary) zum Mailserver. Die Email wird auf dem IMAP-Server erst als gelesen markiert, nachdem sowohl die Roh-Nachricht gespeichert als auch die MIME-Struktur geparst wurde. Bricht das System vorher ab, bleibt die Email auf dem Server als ungelesen und wird beim nächsten Polling erneut abgeholt.

Diese Grenze ist die zentrale Sicherung dafür, dass keine Email verloren geht. Alles davor ist reversibel, alles danach ist in der Datenbank gesichert.