research gate: Sinter scaling without overstating bitwise reproducibility

[marcohost33-maker]

Problem

Phase 7A soll fuer grosse p×d×rounds-Sweeps Sinter verwenden. Das ist fuer Parallelisierung, max_shots, max_errors und Resume sinnvoll. Die aktuell dokumentierte sinter.collect-API exponiert jedoch keinen Seed-Parameter.

sinter.Task.strong_id() hash't Circuit, DEM, Decoder, Metadata und Postselection und identifiziert damit die Aufgabe. Das ist nicht dasselbe wie eine reproduzierbare konkrete RNG-Folge.

Konsequenz

Ein Sinter-Run darf nicht automatisch den bestehenden Claim seed -> bit-identical erben. Fuer Sinter brauchen wir einen separaten Reproduzierbarkeitsvertrag, z.B. STATISTICAL_REPRODUCIBILITY, waehrend der direkte Manifest-Runner BITWISE_REPLAY behalten kann.

Akzeptanz vor Integration

• dokumentieren, welche Zufallsquelle/Seeding-Policy Sinter in der gepinnten Version tatsaechlich nutzt
• differential experiment: gleiche Tasks zweimal -> statistische Konsistenz, aber Bitidentitaet nicht voraussetzen
• Evidence-Schema um sampling_backend + reproducibility_tier erweitern
• strong_id, package versions, task metadata, max_shots/max_errors und resume file provenance erfassen
• falls exakter Seed technisch nicht steuerbar ist: das explizit als NR/Claim-Ceiling fuehren

Quellen

• https://github.com/quantumlib/Stim/blob/main/doc/sinter_api.md
• https://github.com/quantumlib/Stim/wiki/Sinter-v1.13-Python-API-Reference

Kein Blocker fuer PR #39-#41; Blocker fuer einen spaeteren Sinter-Promotionsclaim.