docs: add first implementation variant – central e-collecting system with privacy-preserving collision detection

[herpaderpaldent]

Worum geht es

Bisher dokumentiert das Repository die einzelnen Parameter des
Morphologischen Kastens, aber noch keine
zusammengesetzte Umsetzungsvariante. Dieser PR legt – als Anstoss – die erste
konkrete, durchgängige Umsetzungsvariante vor: Pro Parameter wird eine Ausprägung
gewählt, woraus sich ein zusammenhängendes Zielbild ergibt.

Neue Datei: docs/umsetzungsvarianten/zentrales-system-collision-detection.md

Hinweis: Dies ist ein Vorschlag einer teilnehmenden Person – kein Dokument der
Bundeskanzlei. Er dient als Diskussionsgrundlage und als Beispiel, wie eine Variante
über alle Parameter hinweg ausgestaltet werden könnte.

Motivation

Die Diskussion am Morphologischen Kasten an der letzten Veranstaltung war aus meiner Sicht
ziemlich chaotisch: Es fehlte ein übergeordnetes Konzept, an dem sich die einzelnen
Parameter festmachen lassen. Erschwerend kommt hinzu, dass die Parameter teils
voneinander abhängig sind oder sich gegenseitig ausschliessen – isoliert betrachtet
führt das schnell zu widersprüchlichen Kombinationen.

Darum gehe ich hier bewusst voran und lege die erste konkrete, durchgängige
Umsetzungsvariante vor: Sie wählt für jeden Parameter bewusst eine Ausprägung und zeigt,
wie daraus ein kohärentes Gesamtbild entsteht – inklusive der Abhängigkeiten (z. B.
«kein Opt-Out, weil die zentrale Collision Detection Doppelunterstützungen ohnehin verhindert»).

Der Vorschlag ist ausdrücklich als «Motzvorlage» gemeint: eine konkrete Grundlage, an
der man sich reiben, die man kritisieren und anhand derer man die Parameter diskutieren kann.
Ich freue mich über konkretes Feedback, wo es konzeptionelle Schwächen gibt.

Kerngedanke der Variante

• Zentrales E-Collecting-System verhindert Doppelunterstützungen kanalübergreifend
  (digital + Papier) – datensparsam und ballot-spezifisch, ohne Identitäten,
  frühere Unterstützungen oder den Kanal offenzulegen.
• Fire-and-Forget für Gemeinden: sie liefern bestätigte Papierunterstützungen ein,
  ohne personenbezogene Kollisionsrückmeldung.
• Genau eine Benutzeroberfläche – das Webportal für Gemeinden ohne Fachsystem; alle
  weiteren Funktionen inkl. Abruf aggregierter Sammelstände laufen über die API
  (kein eigenes Dashboard).
• Operativer Sammelstand ≠ amtliches Endresultat: aggregierte Zahlen sind vorläufig;
  die Bundeskanzlei korrigiert via Audit.
• Originalbögen verbleiben bei den Gemeinden (Aufbewahrung für Audit, danach Vernichtung).

Aufbau des Dokuments

1. Konzept – Zielbild, HERMES-Einordnung, Datensparsamkeit, Rollen, Schnittstellen
2. Architektur – Systemkontext (Mermaid-Diagramm)
3. Prozesse – digitale Unterstützung, Papiererfassung (inkl. Quittung/Aufbewahrung),
   Audit (Mermaid-Flowcharts)
4. Abbildung auf den Morphologischen Kasten – Auswahl + Begründung für alle 8 Parameter
5. Risiken und offene Punkte

Parameter-Auswahl (Kurzüberblick)

Parameter	Gewählte Ausprägung
1.1 Erfassung Papier	technologieneutral via Webportal/API (kombiniert 2+3, nicht auf OCR beschränkt)
1.2 Digitale Verarbeitung	Prüfung & Blockierung kanalübergreifender Doppelunterzeichnung
1.3 Behandlung Papier	Verbleib bei Gemeinde: Aufbewahrung für Audit, danach Vernichtung
2 Darstellung	keine zentrale Übersicht, nur Direktlink
3 Argumente	Plattform frei von Argumenten
4 Zuordnung	Anzahl pro Organisation, nur intern, freiwillig
5 Sammelstand	öffentlich verfügbar (via API), mit Vorläufigkeits-Hinweis
6 Föderale Ebenen	Zielbild: alle Ebenen; Versuchsbetrieb: Bundesebene
7 Administrative Voraussetzungen	keine (automatischer Zugang via eID)
8 Bedenkzeit	sofortige Übermittlung

Bewusst ausgeklammert

Das konkrete kryptografische Protokoll sowie das Multiballot-Verfahren sind nicht
Gegenstand dieses Vorschlags. Es wird lediglich auf bestehende wissenschaftliche Arbeiten
verwiesen, auf denen aufgebaut werden kann – insbesondere
MultiBallot (@famoser & Louistisserand) und die
Hackathon-Lösung von Team 6 (@knr1, @philoc et al).
Diese sind vor einer Umsetzung wissenschaftlich eingehend zu prüfen.

Hinweise

• Reine Dokumentations-Änderung, keine Anwendungslogik.
• Sprache: Deutsch (Arbeitsentwurf; FR-Übersetzung könnte später folgen).