Determinismus, Parallelität, Paging und Distribution

Diese Steuerungen beantworten unterschiedliche Fragen und sind keine Synonyme.

• Ein Projekt-Seed koordiniert Zufallsentscheidungen mit deklariertem Seed-Verhalten.
• Eine Distribution definiert die Auswahl aus einem Quellpool oder Zahlenbereich.
• numProcess fordert Worker an; Capability-Policy darf reduzieren, wenn Source oder Selector ihren Vertrag parallel nicht erhalten können.
• Paging verändert das Laden einer begrenzten Source. Das logisch ausgewählte Ergebnis darf sich nicht ändern.
• Streaming verändert Transport und Speicherverhalten. Es hebt den aktuellen bounded-count-Vertrag von Kafka- oder RabbitMQ-Sources nicht auf.

Source-Entscheidungen

Nutze ordered, wenn stabile Traversierung wichtig ist. Bei RabbitMQ erzwingt ordered einen Consumer für FIFO; explizites round_robin erlaubt konkurrierende Consumer und verzichtet auf globale Ausgabereihenfolge. Full-Pool-Policies wie random, weighted, reservoir oder stratified sind nur für Source-Familien mit entsprechender Capability zulässig.

Was geprüft werden muss

• Wiederhole dasselbe Seed-Modell und vergleiche Ausgabewerte statt Dateinamen oder Zeitstempel außerhalb des Vertrags.
• Vergleiche SP und MP nur bei deklarierter Topologie-Invarianz.
• Vergleiche Streaming und Page-Größen gegen dieselbe exakte begrenzte Menge.
• Werte eine automatische Reduktion auf einen Worker als Policy-Evidenz, nicht als Performancefehler.

Siehe Source- und Target-Auswahl, begrenzte RabbitMQ-Sources und die Source-Capabilities in der Authoring-Referenz.