diff --git a/artifact_3/README.md b/artifact_3/README.md
new file mode 100644
index 0000000..358826e
--- /dev/null
+++ b/artifact_3/README.md
@@ -0,0 +1,160 @@
+# Einfluss der Zeitumstellung auf Worker-Kapazität und Effizienz
+
+## Purpose
+
+Analyse der Stabilität und Performance von Systemen während einer Zeitumstellung, insbesondere mit Fokus auf Worker-Skalierung und Timing-Konsistenz.
+
+**Problemstellung:** Zeitumstellungen beeinflussen Zeitstempel und Messungen. Ziel ist, echten Performance-Einfluss von artefaktbedingten Verzerrungen zu trennen.
+
+**Ziele:**
+- Überprüfung der Systemreaktion auf Zeitsprünge (CET → CEST)
+- Validierung von Zeitmessungen bei Lauf #35 gegen mögliche Zeitumstellungsartefakte
+- Quantifizierung des Effekts eines zusätzlichen aux-workers auf Kapazität und Latenz
+
+## Kontext & Hintergrund
+
+Läufe mit aufgezeichneten Zeitreihen zu Performance und Timing-Metriken, inklusive Zeitzonen-Offsets.
+
+**Gruppierung:**
+- Run #34
+- Run #35
+
+**Trace-Metadaten / zusätzliche Tags:**
+- epoch_ms
+- monotonic_ns
+- tz_offset_minutes
+- run_id
+- step_id
+
+**Domänenkontext:**
+- Zeitsynchronisation in produktionsnahen Workload-Systemen
+- Bewertung von Skalierungseffekten auf Worker-Basis
+
+**Motivation:**
+- Korrekte Interpretation von Messdaten trotz Zeitsprung
+- Ermittlung des Skalierungseffekts von zusätzlichen aux-workern
+
+## Methode / Spezifikation
+
+**Übersicht:**
+- Einführung eines Timing-Sentinels zur Überwachung von Zeitkonsistenz während der DST-Umstellung
+- Durchführung eines Single-Parameter-Sweeps mit Variation der aux-worker-Anzahl von 1 auf 2
+
+**Algorithmen / Verfahren:**
+- Erfassen pro Sample: epoch_ms, monotonic_ns, tz_offset_minutes, run_id, step_id
+- Validierung: Differenzen aus monotonic_ns ≥ 0; tz_offset_minutes darf einmal springen
+- Analyse des Einflusses zusätzlicher aux-worker auf Hotspot- und Restlatenz (retry_tailp99)
+
+## Input / Output
+
+### Input-Anforderungen
+
+**Hardware:**
+- Multi-core Umgebung mit konfigurierbaren Worker-Slots
+
+**Software:**
+- Logger mit monotonic-time Unterstützung
+- Zeitzonen-aware Scheduler
+
+**Konfiguration:**
+- Zeitzone CET/CEST
+- aux-worker=1 oder 2
+
+### Erwartete Rohdaten
+
+**Felder pro Run:**
+- epoch_ms
+- monotonic_ns
+- tz_offset_minutes
+- run_id
+- step_id
+
+**Formatbeispiele:**
+- [1711850400000, 123456789000, 120, 35, 004]
+
+**Trace-Daten:**
+- Format: CSV oder JSON mit Zeitstempeln und Performance-Metriken
+- Hinweis: Zeitzonenwechsel muss als Sprung in tz_offset_minutes erkennbar sein
+
+### Analyse-Ausgaben
+
+**Pro Gruppe / pro Governor:**
+- retry_tailp99 Hotspot
+- retry_tailp99 Rest
+- band_width Δ
+- Kosten in Slots
+
+**Vergleichsausgaben:**
+- aux-worker=1 vs aux-worker=2
+  - Δ: −0,4 Prozentpunkte Hotspot Tail
+
+## Workflow / Nutzung
+
+**Analyse-Workflow:**
+- Prüfe DST-Konsistenz per Timing-Sentinel
+- Verifiziere monotonic_ns Differenzen ≥ 0
+- Führe Run unter identischen Parametern außer aux-worker aus
+- Berechne Differenzen für retry_tailp99 zwischen Stufen A und B
+- Interpretiere Messabweichungen unter Berücksichtigung von Kosten und band_width
+
+### Trace-Template-Anforderungen
+
+**Ziel:** Erkennung und Isolation von Zeitumstellungsartefakten
+
+**Erforderliche Tags & Metadaten:**
+- run_id
+- step_id
+- monotonic_ns
+- tz_offset_minutes
+
+**trace-cmd-Setup:**
+- Monotonic clock aktivieren
+- Zeitzonenwechsel simulieren oder protokollieren
+
+**Run-Design für Contributors:**
+- Vergleiche Worker 1 und Worker 2 unter konstantem Setup
+
+## Interpretation & erwartete Ergebnisse
+
+**Kernbefunde:**
+- Zeitumstellung beeinflusst Messwerte nicht, wenn monotonic clock konsequent genutzt wird.
+- Hotspot-Rückgang um ~0,4 Prozentpunkte bei zusätzlichem aux-worker.
+- Restlatenzen und band_width nahezu unverändert.
+
+**Implikationen für Experimente:**
+- Skalierung über zwei Worker hinaus liefert nur marginale Gewinne.
+- Zeitumstellung ist als bekannte, aber kontrollierbare Störquelle zu betrachten.
+
+**Planungsziel:**
+- Ziel: Definition eines stabilen Kapazitätspunkts trotz DST-Ereignis
+- Vorgehen:
+  - DST-Sentinel zur Anomalieerkennung nutzen
+  - Worker-Skalierung schrittweise validieren
+  - Kapazitätskurven mit Sättigungspunkt identifizieren
+
+## Limitationen & Fallstricke
+
+**Datenbezogene Limitationen:**
+- Fehlende Korrektur bei Loggern mit wall time kann negative Δt erzeugen.
+- Unvollständige Zeitzonen-Metadaten verfälschen Vergleichbarkeit.
+
+**Kausalität & Generalisierbarkeit:**
+- Ergebnisse gelten nur für diese Worker-Konfiguration.
+- Übertragbarkeit auf heterogene Workload-Muster unbestätigt.
+
+**Praktische Fallstricke:**
+- Fehlkonfigurierte Zeitzonen springen mehrfach pro Lauf.
+- Nebenläufige Scheduler-Ticks können pseudo-negative Δt maskieren.
+
+## Nächste Schritte & Erweiterungen
+
+**Geplante Experimente:**
+- Untersuchung eines dritten aux-workers zur Verifikation der Sättigung
+- Test komplexerer Mechanismen (Throttle, Segmente)
+
+**Analyseziele:**
+- Quantitative Modellierung der Worker-Sättigungskurve
+- Trennung von Laufzeit- und Energieeinflüssen
+
+**Community-Beiträge:**
+- Bereitstellung eines generischen DST-Sentinel-Skripts für Systemexperimente