Experiment record

When appliance stop and cloud cost settlement are asynchronous: field validation on a Rinnai RDT-93

A field-validated reconciliation pattern for cloud-connected appliances whose physical stop event and utility-cost update occur asynchronously. Four post-fix delayed-cost cases were automatically finalized on the first attributable post-stop cost change.

Summary

A cloud-connected appliance can report “stopped” before its associated cost record is final.

AIEL-2026-0008 began after a Rinnai RDT-93 dryer operation had ended while its cloud utility-cost value was still unresolved. The first design problem was therefore not how to estimate the missing cost. It was how to preserve the operation until a later API value could be attributed safely.

The collector was redesigned around separate state transitions:

1. preserve the appliance stop event;
2. keep the operation unresolved while the cost remains unchanged;
3. finalize immediately on the first attributable post-stop cost change;
4. after two hours without a change, mark the operation as late but continue reconciliation for a bounded period;
5. never assign a later value speculatively when attribution is ambiguous.

The post-fix validation is now complete. Four independent operations entered the late-cost path after more than two hours without an attributable cost change. All four later finalized automatically on the first attributable change, with rounded stop-to-settlement delays between 159 and 540 minutes. No unresolved late-cost operation remained at the review snapshot.

This validates the ordinary delayed-settlement path in production. A separate branch that handles a cost change first appearing exactly when a new dryer run begins is implemented conservatively, but these four cases all settled before the next run began, so that boundary branch remains an explicit unexercised edge condition.

Background

Many telemetry systems implicitly treat physical completion and cloud accounting as one event. That assumption is unsafe when a vendor API updates different fields on different schedules.

In this case, the dryer state could transition to OFF while the utility-cost API still returned the same value observed during the active run. An earlier settlement design also required repeated stable samples after the first relevant cost change. That created unnecessary dependence on later polls: the collector could already have enough evidence to attribute the change, yet still wait for additional identical observations.

The reusable problem is broader than this dryer model:

How should a collector close an operation when the device state says the operation ended, but a cloud-derived accounting value becomes final later?

The safe answer requires an evidence-preserving pending state rather than either immediate finalization or speculative estimation.

Methods

The Experiment used retained private operation logs, diagnostic logs, and the current production collector source.

The current collector polls both appliance state and utility cost every minute. Unchanged diagnostic heartbeat rows are thinned to five-minute intervals, so a five-minute gap between heartbeat rows does not mean the APIs are polled only every five minutes.

For settlement, the collector stores the last complete utility-cost value observed while the operation is active. After OFF:

• an incomplete cost payload cannot finalize the run;
• the run remains open while the cost equals the active baseline;
• the first complete cost value that differs from that baseline is treated as the settlement trigger when attribution is unambiguous;
• after 120 minutes without such a change, the run enters a late-reconciliation state;
• late reconciliation remains bounded for a further 24 hours;
• if a new run begins while the old run is unresolved, the old run is finalized only under explicit attribution conditions; otherwise it is recorded as unconfirmed rather than assigned a guessed cost.

The post-fix field review then searched for real operations that entered the late path and checked whether they were automatically closed without manual repair.

Only sanitized aggregate validation results are public. Raw household operation times, costs, run identifiers, installation identifiers, and the production source remain private.

Experiment Log

Initial failure mode

At least one operation had already stopped while its utility cost remained unresolved. This established that dryer stop and cost finalization were separate observable events.

A safe repair rule was adopted: a later API value could be used only if it could be attributed to the unresolved operation from retained observations. The collector must not invent a cost or infer one merely because the operation had ended.

State-machine redesign

The earlier settlement process depended on additional repeated observations after the first relevant post-stop change. The revised design removed that unnecessary dependency.

The core transition became:

OFF + unchanged cost → unresolved

unresolved + first attributable changed cost → finalized

If no change appears for two hours:

unresolved → pending late reconciliation

and the collector continues bounded observation rather than discarding the run.

Post-fix field validation

After the redesign, four independent real operations entered the late path.

All four later executed the first-change settlement path automatically. Rounded stop-to-settlement delays were:

159, 273, 343, 540 minutes

No manual repair was required for those four cases, and no late operation remained unresolved at the review snapshot.

The key result is not that one particular delay duration is normal. With only four delayed cases, these timings are not a population estimate. The result is that the revised state machine encountered the failure mode it was designed for and recovered from it repeatedly in production.

Remaining boundary condition

All four delayed operations finalized before the next observed dryer run began.

The collector also contains a separate new-run-boundary rule. If an old run is already late and unchanged, and the first attributable cost change appears exactly as a new run begins, the code can assign that change to the old run only when explicit baseline and boundary conditions are satisfied. Otherwise the old run remains unconfirmed.

That branch is implemented and source-reviewed, but it was not exercised by these four post-fix field cases. This Experiment therefore does not describe it as field-validated.

Conclusion

For this collector, appliance stop and cloud utility-cost settlement must be modeled as separate events.

The validated pattern is:

• preserve the stopped operation;
• retain the active-run cost as the attribution baseline;
• do not finalize from incomplete or unchanged data;
• settle on the first attributable post-stop cost change;
• keep unresolved operations in a bounded late-reconciliation state;
• prefer an explicit unconfirmed result over speculative cross-run attribution.

The redesign was exercised by four independent delayed-cost operations in production, and all four were automatically finalized without manual repair. This completes the main Experiment objective.

The evidence does not establish that every delayed update has the same upstream cause, that 159–540 minutes is a general delay distribution, or that the separate competing-new-run boundary path has been field-validated.

Evidence summary

The Evidence States for the information obtained in this Experiment are as follows.

See Evidence State for the shared definitions.

Operational implications

The main reusable lesson is to represent physical completion and derived cloud settlement as separate events when they come from different API fields or backend processes.

A robust collector should keep the original operation identity alive until the delayed field is either safely attributed or explicitly declared unresolved. This is preferable to closing the run at OFF and later attaching whatever value appears next.

The same pattern can apply to other asynchronous systems: delayed energy costs, cloud-computed summaries, billing events, post-processing results, or any telemetry where the accounting record can lag the physical event.

The pattern is not “wait a fixed number of minutes and then trust the next value.” The essential requirement is attribution evidence.

A sanitized aggregate of the post-fix validation is available at post-fix-validation-summary.json.

Experiment data

The raw operation log, diagnostic log, and production source are retained privately for audit. The public record excludes household operation timestamps, individual costs, run identifiers, installation identifiers, and other nonessential private telemetry.

Gas volume derived from utility cost and configured tariff remains an estimate; it is not presented as a direct gas-meter measurement.

Machine-readable experiment record

A machine-readable canonical record of this Experiment is published as JSON.

AIEL-2026-0008 experiment.json

Related experiments

AIEL-2026-0005 uses the same Rinnai collection stack but addresses authentication failure. AIEL-2026-0008 addresses asynchronous post-stop cost settlement and reconciliation, so the two Experiments are related but have separate objectives.