Safety before optimization: how we rank every control decision

Software that gets a decision wrong shows the wrong number. Software that controls a pump, a battery, or an irrigation valve moves water, current, and heat. That difference shapes how we design automation at Greecon: protection and stability always come before optimization.

Here is what that principle means in engineering terms.

Three tiers, always in the same order

Every automated action sits in one of three tiers. When goals conflict, the higher tier wins.

Protect. Keep people, equipment, and the environment safe. These are hard limits — a pump must not run dry, a pipe must not be over-pressurized, a battery must stay inside its safe operating window, a tank must not overflow. Nothing below this tier can override them, and neither can a remote user.
Stabilize. Keep the system inside its normal operating envelope: supply continues, levels stay within range, loads are served.
Optimize. Reduce cost, save water, raise yield, use more of the sun. Optimization is valuable, but it only acts when the two tiers above are satisfied.

A schedule that would save energy never runs a pump past its safe runtime. A forecast that predicts rain never leaves a tank empty. The ranking is boring on purpose — predictable systems are trustworthy systems.

Check the data before acting on it

A control decision is only as good as the measurement behind it. Before a reading is used, it should earn that trust:

Range: is the value physically possible for this sensor?
Rate of change: a soil-moisture reading cannot jump from 12% to 60% in a second.
Freshness: is the timestamp recent, or is this the last value before a cable failed?
Flatline: a sensor that reports exactly the same number for hours is usually stuck, not stable.
Cross-checks: does a second, independent signal agree? A rising tank level should match pump runtime and flow.

When quality drops, the right response is to say so plainly — sensor quality degraded — and fall back to a conservative behavior, not to guess.

Fail safe, not fail silent

For every asset we define a safe state in advance: pump off, valve closed, battery on standby, treated water diverted instead of released for reuse. If a signal is lost, a command expires, or a controller stops responding, the asset moves to that state. Watchdogs make sure a frozen controller does not freeze equipment in a dangerous position.

Equally important, the system tells people what it did and why. An action that is refused should read blocked by safety policy, with the reason visible — not a silent no-op that leaves an operator guessing.

Humans in the loop, with a paper trail

Operators know things a system does not: a technician is on the roof, a neighbor is irrigating from the same canal. So manual override has to exist. But it should be a deliberate, bounded action — who did it, why, and for how long — and it must be recorded.

An override changes who decides inside the limits. It does not remove the limits. Hard safety rules stay in force even when a person is in control.

Prove a rule before it acts

New control logic should earn its authority in stages:

Simulate against recorded and synthetic data.
Advise: run live alongside the system and show what it would do, without touching equipment.
Act on non-critical equipment with tight limits.
Act broadly, once the record shows it behaves.

Each stage leaves evidence, which matters to the engineers who sign off on a system and the auditors who review it later.

The result: systems that not only work — but can explain what they did.

This is the philosophy behind GAIA Tech, the intelligence layer inside the Greecon Platform: simple on the surface, disciplined underneath.