Billy Green
Master Control

BGMC did not begin as a blank software concept. The cultivation workflow existed first. Billy had already spent years deciding what to measure, what to watch, what mattered at each stage, how to compare cultivars, how to diagnose a room and how to carry lessons forward. What did not exist was a practical platform capable of holding all of those relationships together.

That limitation became impossible to ignore when an irrigation controller began dictating what Billy could do instead of following the irrigation strategy he wanted to execute. Opening the irrigation architecture solved the immediate problem, but revealed the larger one: if irrigation could be rebuilt around the grower, why should everything else remain disconnected?

Billy has always put his own money behind his cultivation decisions. His facilities, equipment and crops were his responsibility. BGMC is therefore being questioned against real cultivation: missed irrigation, uneven rooms, sensor failures, mixed cultivars, changing plant counts, equipment limitations and the need to know exactly what happened after the crop is finished.

Lighting can work toward the approved PPFD target. CO₂ can follow stage and light intensity. HVAC, humidification and dehumidification can work toward temperature, RH and VPD. Irrigation can follow the active steering program. Root-zone sensors can verify how the substrate and crop respond. BGMC can compare intended strategy with measured reality.

BGMC Official Control Programs can be immutable and versioned. Facility/User Control Programs can be named, edited and versioned by the facility. Once a version has been used in production, its historical record remains intact so future edits do not rewrite the past.

When final dry weight is known, BGMC can surface the highest-performing historical Control Program within the proper comparison context as a prominent option for a future run. The grower can also select another previous run, an official program, create a new one or intentionally use no assigned Control Program.

Environmental Areas can represent meaningful spatial boundaries such as front, middle, back, left, right, upper or lower. The Area is the identity; the sensor serial number is metadata. Sensors can be replaced without destroying the historical meaning of the Area.

When Tables are assigned to an Area, environmental sensors representing that Area become the primary environmental context for those plants and cultivars. Additional sensors can provide secondary context. If a new Area is added mid-run, historical data remains preserved according to what was true at the time.

Repeated underperformance in one spatial Area across multiple cultivars or runs can point toward a facility problem rather than a genetic problem. BGMC can preserve the evidence required to investigate airflow, temperature, RH, VPD, PPFD, irrigation distribution or other location-specific differences.

The same model can expose differences in cultivation strategy. If one Control Program repeatedly performs better with a cultivar, BGMC preserves the conditions and results required to study that pattern. It does not need to pretend correlation proves cause; it needs to preserve enough context for better decisions.

Why name Tables? Because plant counts, cultivar identity, root-zone data, PPFD and historical performance need a stable physical location. Why define Areas? Because environmental readings need to represent the plants they actually surround. Why map Solenoids and Irrigation Zones? Because command history and irrigation history must describe physical truth.

The objective is to avoid the enterprise-software problem where a powerful platform requires a university course before a grower can use it.

The facility model is designed to grow naturally. New Rooms, Areas, Zones, Solenoids, Tables or sensors can be created from the workflows where they are needed. Sensor replacements and moves preserve historical assignments rather than erasing them.