diff --git a/results_documentation/README.md b/results_documentation/README.md
new file mode 100644
index 0000000..cbba8b4
--- /dev/null
+++ b/results_documentation/README.md
@@ -0,0 +1,213 @@
+# Analyse von Startoffsets und Latenzverhalten – Run #26
+
+## Purpose
+
+Technische Dokumentation der Messergebnisse und Hypothesenvalidierung zur Wirkung von Startverzögerungen auf Resonanzband und Latenz.
+
+**Problemstellung:** Unklar war, ob beobachtete Latenzresonanzen durch inhaltliche Schritte (Step) oder durch Startzeitmuster (Scheduling) ausgelöst werden.
+
+**Ziele:**
+- Untersuchung des Einflusses von Startoffets auf beobachtete Latenzstrukturen.
+- Validierung der Hypothese, dass Startzeitcluster Resonanzeffekte mitverursachen.
+- Erfassung der Veränderungen in Bandbreite und Mittelposition des Resonanzbands zwischen Run #25 und #26.
+
+## Kontext & Hintergrund
+
+Zeitreihen-Logdaten der Worker-Prozesse in Run #26, identische Policies und Hashes wie in Runs #22–#25.
+
+**Gruppierung:**
+- Workerinstanzen pro Run
+- Startzeitkohorten nach Jitter-Fenster
+
+**Trace-Metadaten / zusätzliche Tags:**
+- worker_start_offset als Ableitung aus first-seen timestamps
+- expires_at_dist_hours zur Lebensdauerbetrachtung pro Worker
+- retry_total_overhead_ms als Latenzindikator
+
+**Domänenkontext:**
+- Systemlatenzanalyse
+- Workload-Scheduling
+- Experimentelle CPU-/I/O-Kohortenmessung
+
+**Outlier-Definition:**
+- Methode: Perzentilbasierte Identifikation (p95/p99) der retry_total_overhead_ms
+- Beschreibung: Max-Outlier definiert durch obere 5 % bzw. 1 % der messbaren Latenzen.
+- Metrik: retry_total_overhead_ms
+
+**Motivation:**
+- Quantifizierung des Einflusses von Startzeitverteilung auf Latenzresonanzen.
+- Identifikation mechanisch stabiler Muster jenseits zufälliger Drift.
+- Trennung von inhaltlich getriebenen und zeitlich strukturellen Effekten.
+
+## Methode / Spezifikation
+
+**Übersicht:**
+- Run #26 nutzt ein Jitter-Fenster für gestaffelten Worker-Start.
+- Alle übrigen Parameter bleiben konstant gegenüber Run #25.
+- Vergleich der resultierenden Resonanzbandstruktur zwischen den Runs.
+
+**Algorithmen / Verfahren:**
+- Berechne worker_start_offset als Differenz zwischen Worker-first-seen und Run-Start.
+- Plot: Scatter oder Heatmap von start_offset vs. expires_at_dist_hours.
+- Farbskala: retry_total_overhead_ms pro Punkt.
+- Berechne Cluster-Score zur Quantifizierung von Startkohortenverdichtung.
+
+### Bootstrap-Übersicht
+
+Bootstrap-Resampling zur Unsicherheitsabschätzung der Mittelverschiebung im Resonanzband.
+
+**Zielgrößen:**
+- Bandmittelpunkt in expires_at_dist_hours
+- Bandbreite (Standardabweichung)
+- Cluster-Score pro Startkohorte
+
+### Resampling-Setup
+
+- Runs #25 und #26 getrennt resampeln
+
+**Stichprobeneinheit:** Worker
+
+**Resampling-Schema:**
+- 1000 Bootstrap-Iterationen je Gruppe
+- Berechnung von 95 %-Konfidenzintervallen
+
+**Konfidenzintervalle:**
+- Niveau: 0.95
+- Typ: percentile
+- Ableitung: Mittelwertunterschied der Bandposition
+
+### Abgeleitete Effektgrößen
+
+**Risk Difference (Differenz der Raten):**
+- Definition: Unterschied der Häufigkeit von Latenzen >90 ms zwischen Run #25 und #26.
+- Bootstrap: Resampling zur Ableitung der CI-Grenzen für den Anteilunterschied.
+
+**Risk Ratio:**
+- Definition: Verhältnis des Überkopfrisikos (retry_total_overhead_ms>90 ms) zwischen Burst- und Jitter-Start.
+- Bootstrap: Resampling für CI-Schätzung des Risk Ratios.
+
+### C-State-Kontrolle
+
+**Ziel:** Konstanthaltung der CPU-Zustände und Systemlast zur Isolierung des Startmuster-Effekts.
+
+**Vorgehen:**
+- Keine Änderung an power-governor oder Idle-Stufen.
+- Lastprofile identisch über alle Runs.
+
+## Input / Output
+
+### Erwartete Rohdaten
+
+**Felder pro Run:**
+- worker_id
+- first_seen_ts
+- expires_at_ts
+- retry_total_overhead_ms
+
+**Formatbeispiele:**
+- worker_id=17 first_seen_ts=2024-03-10T14:22:05Z expires_at_ts=2024-03-10T15:02:00Z retry_total_overhead_ms=73.4
+
+**Trace-Daten:**
+- Format: CSV/structured log
+- Hinweis: Zeitstempel normiert auf Run-Startzeitpunkt (t=0 s).
+
+### Analyse-Ausgaben
+
+**Pro Gruppe / pro Governor:**
+- p95/p99 retry_total_overhead_ms
+- Mittelwert und Standardabweichung von expires_at_dist_hours
+- Cluster-Dichte nach start_offset
+
+**Vergleichsausgaben:**
+- Run #25 (Burst) vs Run #26 (Jitter)
+  - Δ: -3.4 pp Anteil >90 ms Latenz
+  - CI(Δ): [-5.8 pp, -1.0 pp]
+  - RR: 0.89
+  - CI(RR): [0.84, 0.96]
+
+- C-State-Korrelation: Keine signifikante Änderung zwischen Runs.
+- Trace-Muster: Resonanzband-Mittelpunktrückkehr zur Lage aus Run #22/#23, Bandbreite schwankt zwischen 0.7–1.1 h.
+
+## Workflow / Nutzung
+
+**Analyse-Workflow:**
+- Lese Logdaten pro Run ein.
+- Berechne start_offset pro Worker.
+- Erzeuge Scatter/Heatmap von start_offset vs. expires_at_dist_hours.
+- Färbe Punkte nach retry_total_overhead_ms.
+- Berechne Cluster-Dichte-Metrik.
+- Vergleiche zwischen Runs (Burst vs. Jitter).
+
+### Trace-Template-Anforderungen
+
+**Ziel:** Erfassung reproduzierbarer Startzeitdaten für Vergleich von Schedulingmustern.
+
+**Erforderliche Tags & Metadaten:**
+- run_id
+- worker_id
+- first_seen_ts
+- expires_at_ts
+- retry_total_overhead_ms
+
+**trace-cmd-Setup:**
+- Normiere Zeitbasis auf Run-Start.
+- Erfasse alle Worker-Ereignisse ab Startzeitpunkt.
+
+**Run-Design für Contributors:**
+- Runs mit identischen Policies und Hashes durchführen.
+- Nur ein Toggle (Burst vs. Jitter) ändern.
+- Mindestens 500 Worker-Instanzen zur Signifikanzsicherung.
+
+## Interpretation & erwartete Ergebnisse
+
+**Kernbefunde:**
+- Max-Outlier bleiben step-getrieben und unverändert zwischen Runs.
+- Resonanzband zeigt klare Reaktion auf geändertes Startmuster.
+- Bandbreite sinkt und Mittelwert driftet zurück Richtung früherer Runs (#22/#23).
+- Startkohorten beeinflussen Latenzverteilung signifikant.
+
+**Implikationen für Experimente:**
+- Schedulingmuster sind aktive Einflussfaktoren auf Latenzstrukturen.
+- Startoffset-Jitter kann Resonanzeffekte abschwächen.
+- Timingänderungen sind messbare Systemdesignhebel.
+
+**Planungsziel:**
+- Ziel: Verifikation der Hypothese, dass Startkohortenstruktur Latenzresonanzen induziert.
+- Vorgehen:
+  - Runs mit variiertem Startverhalten aber identischem Inhalt vergleichen.
+  - Latenzstrukturen über Heatmaps und Cluster-Scores analysieren.
+
+## Limitationen & Fallstricke
+
+**Datenbezogene Limitationen:**
+- Kleinere Samples einzelner Worker können Clusterstatistik verzerren.
+- Eventuell ungleichmäßige Logtick-Dichte über Workergruppen.
+
+**Bootstrap-spezifische Limitationen:**
+- Resampling setzt unabhängige Workerannahme voraus.
+- Korrelationen zwischen Workerinstanzen können Unsicherheitsbandbreite unterschätzen.
+
+**Kausalität & Generalisierbarkeit:**
+- Korrelation zeigt Mechanik, aber keine vollständige Kausalitätsbeziehung.
+- Ergebnisse übertragbar nur auf ähnliche Schedulingregime.
+
+**Praktische Fallstricke:**
+- Unpräzise Startzeitstempel verfälschen Offsets.
+- Zu kleiner Jitterbereich kann Effekt unterschwellig halten.
+
+## Nächste Schritte & Erweiterungen
+
+**Geplante Experimente:**
+- Run #27 – Burst-Start mit zeitversetztem Burst-Fenster zur Testung synchroner Bandverschiebung.
+
+**Analyseziele:**
+- Überprüfung der relativen Verschiebung des Resonanzbands bei verlagertem Startfenster.
+- Erweiterung der Clusteranalyse um Kohortenlaufzeitvergleiche.
+
+**Regression & Modellierung:**
+- Modellierung der Bandposition als Funktion des Startoffset-Mittels pro Workergruppe.
+- Lineare Regression oder Mixed-Effect-Modell zur Schätzung des Jitter-Einflusses.
+
+**Community-Beiträge:**
+- Bereitstellung von Trace-Templates und Heatmap-Skripten für Nachanalyse durch andere Runs.
+- Austausch über Resonanzmuster im Donau2Space-Forum.