FAMILY_IOT_STORAGE_OPTIMIZATION - Experiment Log

Overview

Family ID: FAMILY_IOT_STORAGE_OPTIMIZATION
Status: Active
Created: 2025-08-19
Last Updated: 2025-08-19

Hypothesis Summary

IoT sensor networks in storage facilities enable optimal release timing through real-time decision modeling based on electricity costs (Eurostat NRG_PC_205), temperature control requirements (Open-Meteo API), and integrated facility management simulations. Expected 8-12% improvement based on storage optimization literature, building on FAMILY_STORAGE_ELECTRICITY_COSTS methodology.

Variants

Variant A: Electricity Cost Optimization Signals

• Focus: Simulate facility decisions based on Eurostat NRG_PC_205 industrial electricity prices
• Mechanism: IoT cost monitoring → optimal release timing when costs exceed €0.50/ton/day
• Expected: 8-12% improvement with 2-4 week transmission lags

Variant B: Temperature Control Decision Modeling

• Focus: Open-Meteo weather data + storage temperature requirements
• Mechanism: IoT temperature sensors → predictive release decisions when >8°C threshold
• Expected: Quality degradation acceleration creates predictable supply timing

Variant C: Integrated Facility Management Simulation

• Focus: Multi-objective optimization (electricity + temperature + quality)
• Mechanism: IoT systems balance all factors → sophisticated release timing strategies
• Expected: Outperform single-factor optimization through integrated decision-making

Data Sources (REAL DATA ONLY)

Primary Interfaces

• Eurostat NRG_PC_205: Industrial electricity prices (500-2000 MWh band)
• Open-Meteo API: Temperature, humidity, precipitation for storage control
• BoerderijApi: Dutch potato prices (NL.157.2086) + quality spreads

Storage Parameters

• Energy consumption: 85 kWh/ton/month (60 cooling + 20 ventilation + 5 humidity)
• Cost thresholds: €0.50/ton/day optimization trigger
• Temperature thresholds: 8°C storage optimum, 15°C sprouting risk

Evaluation Framework

Statistical Tests

• Primary: Diebold-Mariano test with Harvey-Leybourne-Newbold correction
• Baseline comparison: Against persistent baseline (MANDATORY)
• SESOI: 8% improvement threshold (conservative based on literature)
• FDR correction: Applied for multiple comparisons

Mandatory Standard Baselines

All experiments MUST include these 4 baselines using get_standard_baselines(): 1. persistent: Current value for next period (random walk) 2. seasonal_naive: Same period previous year (52-week lag) 3. ar2: Autoregressive order 2 with trend 4. **historical_mean: Average of all historical values (alias for persistent)

Cross-Validation

• Method: Rolling-origin CV
• Min training: 365 days
• Step size: 7 days (weekly evaluation)
• Test periods: Up to 60 days ahead

Decision Thresholds

• Directional accuracy: ≥60%
• Improvement over baseline: ≥8%
• Statistical significance: p ≤ 0.05

Experiment Results

No experiments completed yet. Results will be appended below using the standard verdict template.

Decision Log

Decision log entries will be added here after experiment completion to summarize outcomes and next actions.

Codex Validation — 2025-11-10

Files Reviewed

• run_experiment.py
• experiment.md
• hypothesis.yml

Findings

1. Synthetic fallbacks baked in. When Eurostat or Open-Meteo calls fail, the loader silently fabricates constant electricity prices and weather (run_experiment.py:92-142). That violates the “REAL DATA ONLY” policy even though the header claims otherwise.
2. No experiment executed. The experiment log states “No experiments completed yet,” and there are no MLflow runs or metrics showing a comparison against the standard baselines.
3. Price-only baseline superiority unproven. Although the script imports get_standard_baselines, the absence of recorded runs means the IoT signals have never been shown to beat a price-only model.

Verdict

NOT VALIDATED – The current implementation still relies on synthetic fallback data and has never been executed. Real Eurostat/Open-Meteo data must be ingested end-to-end, and statistically significant gains over the mandated baselines must be documented before this family can be treated as validated.