archivdms/.claude/agents/retention-dms-vergleich.md

DMS-Vergleich: Retention/Löschkonzept-Muster (Docspell, Paperless-ngx, ecoDMS, Alfresco)

Referenzdokument für retention-compliance-Agent. Vergleich existierender DMS-Systeme zu Aufbewahrung/Löschung, als Muster-Fundus für archivdms.

ecoDMS — zweistufiges Löschmodell (direkt übertragbar)

• Nach Ablauf gesetzlicher Frist: Dokument wandert automatisch in Papierkorb (nicht sofort gelöscht).
• Endgültiges Löschen erfordert separate manuelle Freigabe.
• Jede finale Löschung erzeugt GoBD-konformes Löschprotokoll (wer, wann, welches Dokument, Rechtsgrundlage).
• Technische Isolation bei Mandantenfähigkeit nicht öffentlich dokumentiert (closed source).

Für archivdms: Passt zur zurückgestellten Papierkorb-Idee. Empfehlung: retain_until erreicht → Status pending_deletion statt Hard-Delete. Löschung nur nach explizitem Review/Freigabe-Schritt, mit Audit-Log-Eintrag (Nutzer, Zeitstempel, Rechtsgrundlage, Dokument-Hash).

Docspell — Klassifizierung als Aufbewahrungs-Vorstufe

• Stanford NLP lernt Tag-/Korrespondent-Zuordnung aus bestehenden getaggten Dokumenten, sagt bei neuen Dokumenten voraus.
• Kein natives Retention/Löschkonzept dokumentiert — Fokus liegt auf Klassifizierung, nicht auf Fristenverwaltung.

Für archivdms: Kein direktes Retention-Muster, aber zeigt: korrekte Kategorie-Zuordnung (invoice/contract/personal_data/...) ist Voraussetzung für automatische Fristen-Ableitung. Bestätigt Ansatz von retention-compliance-Agent (Klassifizierung → Regel), nur regelbasiert statt ML.

Paperless-ngx — kein natives GoBD-Retention-Feature

• Kein dokumentiertes Aufbewahrungsfristen-/Löschkonzept als Kernfunktion.
• ML-Klassifikator (scikit-learn) für Tags/Korrespondent, aber nicht an Fristenlogik gekoppelt.
• Workflow-Hooks in Konsum-Pipeline könnten theoretisch für Retention-Trigger genutzt werden, ist aber kein vorgesehenes Feature.

Für archivdms: Negativbeispiel — Lücke im OSS-Feld. Bestätigt, dass GoBD-konformes Retention/Löschkonzept ein Differenzierungsmerkmal von archivdms ist, kein Nachbau eines bestehenden Musters.

Alfresco Governance Services — Terminologie/Denkmodell (nicht Architektur)

Alfresco ist ein volles Java/Spring-Content-Repository (CMIS-Standard), architektonisch kein Vorbild für archivdms (16+ GB RAM, 6-9 Container im Referenzstack, Solr+ActiveMQ+Transform-Services — Gegenteil von Single-LXC). Zwei Begriffe/Muster aus dem RM-Modul sind trotzdem übertragbar:

• Retention Schedule als Step-Sequenz: statt einer einzelnen Frist eine Abfolge von Aktionen (cutoff → retain → review → destroy/transfer), jeweils zeit- oder ereignisgetriggert. Passt zu GoBD-Fristen, die oft erst nach einem Ereignis zu laufen beginnen (z.B. Frist beginnt erst nach Ablauf des Geschäftsjahres = "cutoff"-Ereignis, nicht ab Dokumentdatum).
• Legal Hold: orthogonale Sperre, unabhängig von der Retention Schedule, blockiert jede Löschaktion (auch nach Fristablauf) bis explizit aufgehoben. Sauberes Vokabular für den DSGVO-vs-GoBD-Konfliktfall — Legal Hold als eigenes Flag/Objekt statt in die Fristenlogik selbst eingewoben.
• RM-Modul existiert weiterhin in Alfresco Community Edition (Grundfunktionen frei, eDiscovery/mehrstufige Freigabe-Workflows Enterprise-exklusiv).

Für archivdms: Erweiterung von Punkt 1 im Fazit unten — retain_until könnte künftig als Step-Sequenz statt Einzelwert modelliert werden, sobald ereignisgetriggerte Fristen (Geschäftsjahresende, Vertragsende) gebraucht werden. Legal-Hold-Flag als eigenständiges Feld (unabhängig von pending_deletion-Status) vormerken für den DSGVO/GoBD-Konfliktfall.

Fazit für retention-compliance-Agent

1. Zweistufiges Löschen (ecoDMS-Muster) in Retention-Regeln vorsehen: retain_until abgelaufen → pending_deletion, nicht sofort löschen. Feld requires_review bereits im Ausgabeformat vorhanden, gleiche Logik für finale Löschfreigabe nutzbar.
2. Löschprotokoll als eigenes Audit-Artefakt mitdenken, sobald Hard-Delete tatsächlich umgesetzt wird (aktuell nicht Scope des Agenten, aber Anschlussstelle).
3. Kein bestehendes OSS-System liefert vollständiges GoBD-Retention-Vorbild — archivdms-Ansatz (regelbasiert, strengste Regel gewinnt, DSGVO nie Vorrang vor gesetzlicher Pflicht) bleibt eigenständig zu verantworten.

Quelle: siehe Memory project_docspell_referenz und project_dms_vergleich_paperless_ecodms (Recherche 2026-07-17).