How Wattif delivers continuous control policies end to end

The scope and the runtime are separate objects.

The Intervention holds the scope and the M&V plan. The strategy is the runtime that delivers it. Keeping them apart lets a hardware retrofit verify under the same scope with no strategy at all, lets a partner algorithm replace a Wattif-written one without re-papering, and lets a strategy be paused or retuned without touching the verification record. One scope; zero, one, or many runtimes.

One control surface across three entity kinds.

A strategy binds to an asset (a fan-coil), a space (a refrigerated zone), or a process (a CIP step). We model these as three columns on the same row, with a CHECK constraint enforcing exactly one is set, instead of three parallel tables. The lifecycle, the audit trail, the authority ladder, and the executor pipeline all gain one implementation to maintain instead of three.

Authority belongs to the strategy, not the building.

A control loop's risk profile is local to the loop. The same site can run an FCU setback at Dispatch — fully autonomous — and a chiller-plant sequencer at Recommend, because the cost of a wrong move differs by orders of magnitude. The authority level lives on the strategy row and is the only thing standing between a Decision and equipment movement.

Replay precedes commissioning.

Before a strategy reaches Enabled, the operator sees the last thirty days of their telemetry re-played through it — every Decision it would have emitted, the energy delta against the baseline, the comfort excursions. The executor is a pure function with no side effects, so the replay uses the exact same code path as live operation. The preview is faithful, not approximate, and trust transfers against evidence the customer already owns.

The decision stream is the audit trail.

Every executor tick writes one row to control_strategy_decisions — including the ticks that decided to do nothing, so gaps in the stream mean cron incidents, not silent ambiguity. Each row carries the state it was evaluated against and forward links to the Case or control_command it produced. The table is append-only at the database level; corrections come from new rows, never from edits.

Approving the contract creates the strategy.

When the customer accepts an Intervention's scope, the state-machine transition fires a commissioning hook in the same call. The hook walks target_entities, looks up matching policies in the registry, and writes one disabled control_strategies row per eligible pair with default config and an intervention back-link. The operator never files paperwork to enable a strategy — they choose when to flip a row that's already pre-configured and waiting.

asset

A single piece of equipment — fan-coil unit, exhaust fan with VFD, single compressor, single refrigeration case. The most common binding. Used when the strategy's measurement boundary is one sub-circuit.

space

A zone, room, or floor — refrigerated warehouse rack, hotel guest room, retail trading floor. Used when a single sensor + actuator combination governs a multi-asset comfort or storage outcome.

process

A process_flows row — a clean-in-place loop, a batch step, a production line. Used in food processing and other industrial contexts where the relevant control point is a process, not an asset.

Scoped

A diagnosis writes an Intervention row with the category, the entities it would attach to, and a sized opportunity. The strategy doesn't exist yet — only the contract sketch does. Owner: diagnostic agent.

Approved

The customer accepts scope. The state-machine transition fires synchronously; the commissioning hook in the same call reads the registry, walks the target entities, and writes one disabled control_strategies row per eligible pair with default config and an intervention_id back-link. Owner: customer.

Commissioning (run-up)

Telemetry accumulates against the boundary meter while the strategy sits disabled. The baseline window is strategy-specific — fourteen days for an FCU loop, twenty-eight for whole-facility — and the Strategy tab refuses the disabled-to-enabled flip until that window is met and an mv_baselines row is built. The customer doesn't need to know this is happening; the platform tracks the gate. Owner: platform.

Replay review

The operator opens the Strategy tab. The executor is invoked in dry-mode over the last thirty days of state, producing a hypothetical decision stream and the energy delta against the baseline. Sliders for the config parameters re-run the replay under a second. Commissioning happens only when the operator's judgement and the replay agree. Owner: operator.

Enabled

The operator flips status to enabled and chooses an initial authority — Recommend by default. The platform stamps commissioned_at. From this timestamp forward the reporting period is running and every tick is part of the settlement record. Owner: operator.

Running

The executor cron evaluates the strategy every minute. Each tick reads state through the same fetcher the replay used, calls the pure decision function, routes the decision by authority, and appends a row to the stream. Per-strategy failures never block other policies; per-tick failures preserve the strategy's vacancy memory so the next tick recovers without manual intervention. Owner: strategy executor.

Verified (per cadence)

On the Intervention's M&V cadence, the verifier cron reconstructs the period: the boundary meter, the baseline model, the decision stream cross-referenced with telemetry to confirm the strategy caused what it claimed to cause. The result is an immutable intervention_verifications row, hash-chained, with a method-version stamp. Settlement reads from here. Owner: verifier (agent or human).

Archived

Operator-initiated retirement or Intervention end-of-life. decommissioned_at is stamped; the stream stays. Ticks stop, but every prior decision remains queryable for audit and for the next pass at the strategy if the customer comes back. Owner: operator.

observe

The executor runs, decisions are logged, nothing is surfaced and nothing is dispatched. Used during shadow commissioning when the operator wants telemetry-driven sanity-checking before the strategy becomes visible to anyone else.

inform

Decisions land in the operator's feed but never become Cases or commands. Useful when the operator wants a passive stream of what the strategy is thinking without a queue to triage.

report

Decisions roll up into daily or weekly reports rather than appearing interactively. Suitable for policies whose decisions are advisory by design — tariff-window strategy notes, monthly comfort-band reviews.

recommend

The default for every new strategy. Each non-trivial decision creates a Case for operator review; nothing reaches the equipment until the operator approves. Equivalent to a human technician proposing a change in person.

adjust

Decisions write control_commands within explicit guard-rails declared on the registry entry (setpoint may move at most 2.0 °C from base, fan_mode may not jump more than one step). The dispatch worker delivers commands to the bound device's transport — but the strategy can't escape its declared box.

dispatch

Decisions write control_commands without per-decision guard-rail clamping. The registry's hard limits still apply, but inside those limits the strategy is autonomous. Reached only after the operator has watched a few cycles match intent at the lower levels.

emergency

Reserved for safety- and grid-critical interventions — demand-response dispatch, equipment-protective shutdowns. Decisions execute immediately and notify the operator after. The registry restricts which strategy types can be promoted here; for most loops this level is not user-toggleable at all.

Purity is the precondition

The executor is a pure function: (state, config, now) → Decision. No I/O, no clocks except the one passed in, no hidden state. Purity is what lets the same code that decides live at 14:22 decide the same way again when replayed in dry-mode at midnight against the state of 14:22 — which is what makes replay a faithful preview rather than an approximation.

State as a time series, not a snapshot

The replay reconstructs the state the executor would have seen at each tick. For simulator-backed entities that's a read from simulator_devices.state at one-minute resolution. For real devices it's an interpolation across load_telemetry and context_telemetry. Either way, the executor sees the same shape of input it sees live, which is the only way to trust the output.

Output is the same shape the operator will live with

Replay emits a list of Decision objects identical in shape to control_strategy_decisions rows. The operator inspects the same data structure they will see in the Recent Decisions table once the strategy is enabled, including the action='none' ticks. There is no separate 'preview format' to learn.

Energy delta through the baseline model

Each replay decision is run through the same baseline model the live verifier uses, producing a per-tick kWh delta. The summed delta is the figure the operator approves against; the confidence band scales the baseline's residual error by tick count and is honest about how much of the headline number is signal versus noise.

Sub-second tuning

Configuration sliders re-run the replay under a second. The interaction is closer to scrubbing a clip than to filling a form: the operator drags vacancy_window from fifteen to ten minutes, the timeline redraws with more setback events, the savings tile updates, the comfort excursion count is still zero — keep, or revert. Convergence on a config that matches operator judgement takes minutes, not weeks.

Replay becomes the first verification's anchor

On commissioning, the chosen replay result is captured as the predicted savings the first live verification will be measured against. Predicted-versus-actual ratio is one of the cheapest sanity checks for an algorithm changing behaviour: if the first month diverges from replay by more than the model's residual band, something material changed and the verifier surfaces it before settlement.

entity_types

Which entity kinds the strategy may bind to. fcu_occupancy_optimizer accepts entity_type='asset' only; cip_schedule_optimizer accepts 'process' only; zone_setback accepts 'space'.

applies_to_*_types

Sub-filter by category. fcu_occupancy_optimizer.applies_to_asset_types = [fcu, vav, split_ac, minisplit, ahu]. The commissioning hook refuses to attach a strategy to an entity whose category is outside this list.

intervention_category_ids

Which intervention_categories.id values trigger this strategy on commissioning. fcu_occupancy_optimizer registers operational_optimization. A new strategy that delivers electrification adds 'electrification' here and the commissioning hook picks it up without further wiring.

telemetry_required

The columns the executor's state fetcher expects non-null. Used by the replay engine to refuse policies whose state cannot be reconstructed from history.

baseline_min_days

Minimum days of pre-commissioning telemetry needed for a defensible mv_baselines row. The Strategy tab will not allow the flip from Disabled to Enabled until this window is met.

default_config

Sensible starting parameters. Merged over by intervention-specific tuning at commissioning. Visible to the operator in the Strategy tab; editable before commissioning.

default_authority

The authority a new strategy commissions at. Every entry in the registry today defaults to 'recommend'. Promotion to Adjust or Dispatch is an explicit operator action recorded on the Decision Stream.

One tick, one row, no gaps

The executor writes to control_strategy_decisions every minute for every enabled strategy. The action='none' ticks are written too — that's deliberate, because the absence of a row means the cron didn't run, not that the strategy decided nothing. Gaps surface as cron incidents in monitoring, not as silent uncertainty in the audit trail.

Frozen state snapshot per row

Each row carries the state the executor evaluated against — temperature, setpoint, occupied, vacancy_since — copied into the row, not referenced. Re-running the executor against historical rows produces the same Decision the cron made; the audit doesn't depend on the original telemetry still being available at original resolution.

Bidirectional links to side effects

When a Decision routed to a Case, case_id on the decision row points to it. When it routed to a control_command, command_id points to that. The graph of (Decision → Case → operator action) and (Decision → control_command → device transport) is fully queryable in both directions — useful when an auditor asks how a specific equipment movement came about, and useful when a verifier asks which Decisions actually reached the equipment.

Append-only by RLS, not by convention

The table grants no UPDATE strategy to any role; service-role inserts only. Corrections are appends with supersedes metadata, never mutations. A row that lands in the stream is in the audit trail forever — the engineering equivalent of a financial journal's ink.

Attribution evidence for verification

The verifier cron reads the stream filtered by intervention_id and the verification window. The presence and count of action-bearing decisions inside the window is the primary evidence that the strategy did the work — distinguishing 'savings appeared and we ran' from 'savings appeared because we ran'. The two are not the same and a defensible settlement requires we tell them apart.

One verification engine, two delivery shapes

Hardware-retrofit Interventions and strategy-delivered Interventions settle through the same ledger writer, the same uncertainty calculation, the same baseline builder, and the same hourly verifier cron. There is no parallel pathway, no second M&V code path to maintain, and no second method version to keep aligned with the first. A reviewer who has accepted the Option B engine has accepted ours.

Decision stream becomes attribution evidence

Baselines tell you what should have happened. Boundary meters tell you what did happen. Neither tells you why — and 'why' is what attribution requires. The decision stream provides the contemporaneous record of the strategy's actions, so the verifier can prove the savings followed the strategy's behaviour rather than coinciding with it. For setpoint-class policies this is decisive: the setpoint trace itself is the action proof.

Boundary coherence

The mv_baselines row for a strategy-delivered Intervention is built against the same meter that defines the strategy's measurement boundary. This sounds obvious; it's a frequent source of error in less disciplined M&V systems where the baseline is built from one signal and the verification reads another. The platform enforces the equality at the schema level so the mismatch can't happen.

Tick count is not the point

What the customer is shown is intervention_verifications.verified_savings_amount on the ledger. Not how many ticks a strategy emitted, not how many control_commands it wrote, not any platform usage metric. Wattif charges a fixed fee for the work and takes no percentage of the saving, so the whole of it belongs to the customer and the ledger exists to prove the number rather than to bill against it.

Diagnostic agent (Wattif AI)

Identifies opportunities, scopes Interventions, populates target_entities, writes the Brief or Report.

Customer (operator)

Approves Intervention scope. Opens the Strategy tab. Reviews replay. Tunes configuration. Sets initial authority. Promotes, pauses, or archives policies as the relationship matures.

Strategy executor (Wattif platform)

Runs every minute. Emits Decisions. Routes per authority. Never exceeds authority. Writes the Decision Stream.

Dispatch worker (Wattif platform)

Delivers commands from policies at Adjust+ authority to the bound device's transport (LoRaWAN, MQTT, Modbus, BACnet). Until Phase 4 lands, the simulator stands in for this layer for development.

Verification cron (Wattif platform)

Settles on the Intervention's cadence by reading the Decision Stream and the boundary meter through the engine documented in /overview/mv-option-b-method.

Ecosystem partner

Ships an algorithm — model weights, an inference container, a runtime contract — into Wattif's infrastructure and registers it as a strategy_type. Does not receive customer telemetry; reads through Wattif's fetcher inside our perimeter. Wattif retains the M&V boundary, the boundary meter, and the customer relationship.

strategy-executor

Every minute. Walks every control_strategies WHERE status='enabled', fetches state, calls the executor, routes the decision per authority, writes the decision stream row. Per-strategy failures never block other policies.

normalize (simulator hook)

Every minute. Ticks any active simulator_devices before its channel loop. Until Phase 4 of the build sequence lands, the simulator drains pending control_commands inline and applies downlinks; that integration retires when the dispatch worker is generalised.

mv-baseline-builder

Nightly at 02:30 SGT. Builds the pre-commissioning baseline for any Intervention in Deploying or Live without an mv_baseline_id. Documented in /overview/mv-option-b-method.

mv-verifier

Hourly. Settles the Intervention's verification cadence by reading the Decision Stream and the boundary meter. Documented in /overview/mv-option-b-method.

missing_target_entities

Intervention approved with empty target_entities. Commissioning records the failure on its result; the Intervention stays Approved without any strategy rows. Operator action: add entities and re-fire the commissioning hook, or manually create the strategy from the Strategy tab.

no_platform_strategy_for_category

Intervention's category_id has no entry in any StrategyMetadata.intervention_category_ids. This is not a bug — it is the case for delivery_mode='external' categories. Commissioning is a clean no-op.

strategy_not_applicable_to_entity_category

Target entity's category is outside the strategy's applies_to_* list (e.g. a 'chiller' entity targeted by fcu_occupancy_optimizer). The pair is skipped with a recorded reason; other eligible pairs in the same intervention still commission.

baseline_min_days_unmet

Operator attempts to flip status from Disabled to Enabled before baseline_min_days of pre-commissioning telemetry has accumulated. The Strategy tab refuses the transition; commissioned_at remains unstamped.

executor_crash

Per-strategy failure during a tick. The cron continues to the next strategy; the failed strategy's tick is recorded as routed_to='skipped' with the error string. The vacancy_since memory is preserved so the next tick recovers.

authority_exceeded_attempt

Operator attempts to promote authority past the registry's hard ceiling for that strategy type (e.g. promoting an HACCP-class strategy to Dispatch). The Strategy tab refuses; the attempt is recorded as a Case for audit.