The Planning Loop

At every solar milestone and band transition, Iris (our OpenClaw AI agent) runs as an OpenClaw agent over a structured greenhouse context window. Routine checks and smaller deviations route through Gemma 4 26B A4B (MoE), served locally under the gemma4-26b alias; larger milestone reviews and major deviations can route to a heavyweight cloud peer. Iris does not choose what the greenhouse should target. The crop target band handles that, computed from the diurnal profiles of the currently active control crops with smooth hour-by-hour interpolation. As of the May 8 launch check, Verdify has four active-control crop profiles; a fifth active DB crop record, the center-zone Vanda orchid, is treated as observed/reference while the center zone remains offline. The planner chooses how aggressively the controller should chase those targets given forecast, memory, equipment state, and known physical limits. When the plan lands, Slack Operations is the human-readable layer: plan ID, prior scorecard, forecast, tactical posture, experiment, and watch items.

Each plan is a hypothesis. The system measures what happened, scores the result, and extracts lessons when predictions diverge from reality.

Control split: crop profiles define target bands, Iris chooses bounded tactics, MCP and the dispatcher validate writes, and ESP32 firmware decides relay state every 5 seconds.

The Closed Loop

Step 0: Validate the Previous Plan

Before writing anything new, the planner reviews what happened since its last plan. It reads the plan_journal entry — hypothesis, experiment, expected outcome — then checks actual data: stress hours, zone temperatures, VPD compliance, equipment runtimes, water usage. It scores the plan 1–10. If something unexpected happened, the planner extracts a lesson. Lessons accumulate in the planner_lessons table with confidence that increases each time the pattern is re-confirmed. The claim is not that the AI rewrites itself; it is that future plans can read validated outcomes from earlier failures.

Step 1: Gather Context

The planner assembles structured context from the database:

The local-memory story matters. Iris is not reasoning from a blank prompt. The context bundle pulls current telemetry and prior outcomes, the static-context builder makes the website’s greenhouse documentation available to the agent, and the lessons table gives durable findings a structured place to live. OpenClaw now uses trigger-scoped planner sessions so the local gemma4-26b route gets bounded context while memory remains database-backed and auditable. Semantic similarity is already used for observation history where embeddings exist; plan history and scorecards are exposed today as structured memory so the planner can compare the next decision against what actually happened last time.

Step 1b: Route the Planner Instance

Not every planning event needs the same model. Verdify uses a dual-Iris policy:

Step 2: Reason Across All Systems

The planner doesn’t optimize one variable. It reasons across seven interconnected systems simultaneously:

• Temperature — The south zone runs 9°F hotter than east at peak. temp_high applies to the average, so south is already in COOL_S2 when the average hits threshold.
• VPD — On a 14% RH day, the system fights VPD stress for 8+ hours. Lowering vpd_high means misters engage earlier — more water, more humidity, less plant stress.
• Misting — 60-second pulses with 45-second gaps is the tuned sweet spot. Higher VPD weight concentrates water on the driest zone.
• Economiser — When outdoor enthalpy is lower than indoor, the vent opens for free cooling. The planner understands enthalpy dynamics when planning ventilation strategy.
• Grow lights — Two circuits (816W + 630W) supplement natural DLI. The planner adjusts the lux threshold based on the DLI forecast.
• Irrigation — Misting serves dual purpose: humidity control AND irrigation via foliar absorption.
• Cost — Electric heat costs 3.9× more per BTU than gas. Running fog during solar production can be cheap, but it still appears in the resource accounting.

Step 3: Write the Plan

The planner writes two categories of parameters: Target tightening (optional, clamped to crop band): The crop band sets the outer envelope (e.g., temp 72-78F at midday). The planner can tighten within the band on mild days. If it sets temp_high=75, the ESP32 targets 75 instead of 78. On extreme days, it leaves these alone and the band edges are used. Values are always clamped to the band. The planner cannot exceed crop science limits. Tactical parameters are the planner’s main output:

The Slack brief is not a separate source of truth. It is the readable operator version of the same plan_journal and setpoint_plan records: plan ID, hypothesis, forecast context, expected risks, and watch items. See Slack Operations for screenshots of a successful SUNRISE plan, daily operator tasks, and a forecast-deviation adjustment.

AI-Writable Tunables

Iris can write only registry-approved tunables. set_plan is stricter than set_tunable: routine sunrise/sunset plans must include the 24 tactical parameters below at each waypoint and may not include crop-band parameters. set_tunable can make a one-shot adjustment to any planner-pushable registry entry; band-owned values are still clamped or overwritten by the band dispatcher.

Write path: Iris calls MCP set_plan or set_tunable; MCP validates names and registry bounds, stamps trigger audit data, and writes setpoint_plan. v_active_plan resolves the active value per parameter. The dispatcher pushes changed values to ESPHome number/switch entities and logs actual ESP32 reports in setpoint_changes; /setpoints is the 5-minute HTTP fallback. setpoint_snapshot stores cfg_* readbacks from firmware so pushed intent can be checked against actual configured state.

Routine Plan Contract

These 24 parameters are required in every multi-waypoint plan. Bounds are registry and firmware clamps.

Other Tier-1 One-Shot Knobs

These are planner-pushable through set_tunable, but are not required in every routine plan.

Band-Owned Values

These are visible to Iris and technically planner-pushable as one-shot overrides, but routine plans do not own them. /setpoints recomputes temp_low, temp_high, vpd_low, and vpd_high from crop profiles and clamps any one-shot value inside the active crop band. Per-zone VPD targets are also dispatcher-owned from crop data.

Tier-2 Escape Hatch

Iris can set these through set_tunable, but normal planning rarely should. They are mostly operator posture, irrigation, lighting, diagnostic, or older duty-cycle controls.

Not AI-Writable

Safety rails and site constants are registry entries but MCP rejects planner writes to them: safety_min, safety_max, safety_vpd_min, safety_vpd_max, and site_pressure_hpa. Firmware still consumes the safety rails directly: safety_min forces SAFETY_HEAT, safety_max forces SAFETY_COOL, and the VPD rails trigger dry/humid safety rescue paths.

Step 4: Journal the Hypothesis

Every plan writes a structured journal entry: what the world looks like, what the planner thinks will happen, one specific experiment being tested, and a measurable expected outcome. The next cycle validates the hypothesis and scores the result. This isn’t logging for debugging. It’s the experimental protocol that turns each cycle into a learning opportunity.

Step 5: Dispatch to the ESP32

The dispatcher runs every 5 minutes inside the ingestor service. It reads the active plan, compares each value to what the ESP32 currently reports, and pushes only changed values via aioesphomeapi (encrypted, immediate). The ESP32 also pulls /setpoints via HTTP every 5 minutes as a fallback. Between dispatches, the ESP32 runs completely autonomously. If the AI layer goes offline, the controller keeps the last valid setpoints and hard safety rails.

The Learning System

• Low: First observation. Might be coincidence.
• Medium: Confirmed 2+ times under similar conditions.
• High: Validated 5+ times. Mandatory unless conditions clearly differ. The planner must check every active lesson before finalizing a plan. See Lessons Learned for the full list.

Planning Goals (Priority Order)

1. Minimize VPD stress hours — plant transpiration balance
2. Minimize heat stress hours — physics-limited by cooling capacity
3. Maximize DLI — daily light integral for growth
4. Minimize water usage — misting water isn’t free
5. Minimize energy cost — USD 0.111/kWh, USD 0.83/therm, USD 0.00484/gal
6. Maintain positive DIF — 8–15°F day warmer than night
7. Maximize compliance % — time within setpoint bands These are ordered. The planner will spend water and energy to reduce VPD stress. It won’t sacrifice plant health for a lower utility bill.

Control Loop Performance

Full dashboards: Controller ↗ · Planning ↗