How idempotency prevents duplicate actions when market data is revised

Abstract

Market data can be observed more than once as upstream values are restated or a newer source revision becomes available. A household integration that treats every observation as a new command can therefore repeat charging, heating, notification, or schedule-publication actions. In the frozen evidence, the mean archived point revision rate was 18.772560105996472% across 1,804 revision-rate groups, with a day/row-block mean-bootstrap interval of [17.41734175954391%, 20.21151469441113%]. This is production-origin revision evidence, not a duplicate-device-action rate.

Idempotency separates the identity of data from the identity of physical intent. Each observation should be uniquely versioned by zone, delivery start, series/source, and revision. Each household action should have a stable logical key for the appliance and delivery objective. When a newer revision arrives, the controller updates the pending decision under explicit rules; it does not blindly append another physical command. If an action has already become irreversible, the revision is recorded and evaluated for a compensating decision rather than replaying the original one. A controller should reject missing, regressive, conflicting, or stale revision identities and must persist idempotency state before external side effects. The measured archive shows that revision handling is not merely theoretical. Deterministic retry and out-of-order-revision scenarios remain proposed fixtures, not repository tests claimed as having run.

Plain-language answer

Give every market observation a version, and give every intended household action a separate stable identity. If the same webhook or poll arrives twice, the second copy should find the existing observation and do nothing. If the source publishes a genuine revision, the controller should update the stored schedule proposal, compare it with the previous one, and decide whether a new command is necessary. It should not repeat the old command just because the data message is new.

The evidence found a mean revision rate of about 18.773% across 1,804 archived rate groups. That percentage does not mean 18.773% of household actions would otherwise be duplicated. It means revisions are common enough in the archived data to require an explicit state machine.

The safe sequence is: validate the revised payload, store it under a revision-aware observation key, lock the stable action intent, compare current state, and only then issue a changed command. If the database write or lock fails, stop before controlling the appliance. Exactly-once physical execution cannot be guaranteed by an HTTP idempotency header alone; durable local state and device acknowledgement are also needed.

Research question

The research question is how a home-energy controller can consume revised market data without converting repeated or amended observations into duplicate physical actions. The supporting empirical question is how prevalent point revisions are in the frozen append-only archive.

Three identities must be distinguished. The delivery identity says what interval and zone a value describes. The observation identity says which source series and revision produced that value. The action-intent identity says what the controller is trying to accomplish for a device, such as setting one charging plan for one target window. Conflating any pair creates risk. Ignoring the observation revision can hide changed inputs; putting every revision directly into the physical command identity can manufacture multiple actions.

The decision criterion is monotonic, fail-closed processing. A controller accepts only a valid next observation, records whether it changes the decision, and performs at most one side effect for each authorized transition. Missing or conflicting lineage blocks the transition. The paper does not measure a specific controller or device and does not claim a realized duplicate-prevention rate.

Data and provenance

The public evidence uses schema volt-home-paper-evidence-v1, identifies VOLT-HOME-WP-095, and records status measured. The publication cutoff is 2026-08-30T00:00:00Z. The primary input comes from the frozen revision summary derived from the append-only grid_revisions contract. The family contract also lists auction publications, ingestion runs, public API schemas, and repository integration fixtures.

The extraction grouped revision rows by zone, series, key, timestamp, and resolution, counting observed revisions and comparing first and latest values. The paper-level analysis calculated a revision percentage for each non-empty summary group and then averaged those percentages. The resulting sample has 1,804 group-level rates. This is not the same as pooling all points into one global revised-points ratio.

The snapshot was taken through a SELECT-only production transaction with a 180-second statement timeout. The evidence records snapshot SHA-256 f77e3ae328f93916e53b1bab7516e1d0ac740a0dbf424cd2b73c81fee2559318, analysis-code SHA-256 57c57de79cdab2b5b6d6c54c485cb5162598c5ba0b0bfe995da40d75e6c52ba9, protocol SHA-256 adb36bf6b447af9f96339249b8becaefc20422499cca1977242866347a97bd4b, paper-registry SHA-256 7bcb91d7476d0a69fe9fa75a5c7782f8117e0153f82f9112b7e1d307d3943717, and source-registry SHA-256 07949550ac443ff673fda5c0209b99f137544f3ffecf6775f109bb9d09663bd6. The evidence-manifest hashes are 4d02fbae164d93e199315fce6116b5ba2f3cb8b2f5027b635ecd20c6a38937d4 for the JSON and 2db488aa877ed96236a8fb7cdc87714f942ada3190833a22f6954a241f474ede for the WebP figure.

These revision summaries are production-origin observational evidence. No household command log was joined. Retry storms, stale messages, and out-of-order revisions discussed below are deterministic fault-injection designs for future conformance testing, not observed production failures or claimed repository-test passes.

Method

For each revision-summary row with a nonzero point count, the analysis calculated 100 × revised_points / points. It collected 1,804 rates and took their arithmetic mean. The deterministic bootstrap resampled the group rates, calculated 400 resampled means after the corpus’s bounded-sample procedure, and reported the 2.5th and 97.5th percentiles.

The primary value is therefore an unweighted mean across groups. A group with few points contributes the same weight as a group with many points. That choice describes the typical group-level revision rate under the frozen registry; it does not estimate the probability that an arbitrary raw point is revised. The metric label and limitation should be retained when citing it.

For controller design, use two coordinated records. The observation record key includes zone, series or source, delivery start, resolution, and revision; its content hash detects conflicts. The action record key includes device, objective, and target window and persists the last observation revision evaluated. A transaction or compare-and-set operation claims the next action transition before any external call. The device call then carries an idempotency token where supported, and its acknowledgement is stored.

There is a tradeoff between revision sensitivity and operational stability. Replanning on every changed value is responsive but can churn a device. Ignoring revisions is stable but can act on superseded information. A guarded policy compares the old and new validated decisions, applies materiality and deadline rules declared in advance, and updates only when the transition is both meaningful and still safe.

Results

The mean archived point revision rate is 18.772560105996472% across 1,804 group-level rates. The day/row-block mean-bootstrap interval is [17.41734175954391%, 20.21151469441113%]. The figure values are exactly 0.0%, 0.05486418373569071%, and 79.47777170516068% at P10, median, and P90.

The predefined interpretation is: “Idempotency keys should bind zone, delivery start, and source revision so a restatement updates state without repeating an action.” A safe implementation makes that binding explicit in the observation identity while retaining a stable physical-intent identity. This layered model preserves the evidence’s revision lineage and prevents the revision number itself from authorizing an unconditional repeat.

The result establishes that changed archived observations occur at a material group-level rate in the frozen sample. It does not say which series drove the rate, how large the value changes were, whether changes altered a household schedule, or how often duplicates occurred. It supports revision-aware design, not a quantified savings or reliability claim.

Robustness and placebo checks

The bootstrap interval is aligned with the estimator because both use means of the group-level rates. A reproduction should nevertheless inspect weighting. A pooled point-level rate and an unweighted mean across groups answer different questions. Neither should be substituted silently for the registered metric.

Future deterministic checks should replay the identical observation twice, deliver a newer revision twice, deliver revisions out of order, reuse a revision number with conflicting content, crash after the idempotency record but before the device call, and crash after the call but before acknowledgement. These are proposed fixtures, not measured repository tests. The expected behavior should be specified for every crash boundary.

A strong placebo is a new receipt whose content hash and revision identity match the current observation. It must not create a new decision. Another placebo changes irrelevant metadata while leaving the canonical decision inputs unchanged; it should update provenance without controlling the appliance. A true changed revision can then verify the guarded re-evaluation path.

The family result is descriptive. If a future study compares multiple materiality thresholds or update policies, the preregistered family-wise correction should be applied. No such policy comparison is inferred from this evidence.

Limitations

The rate is averaged across 1,804 summary groups and is not a raw-point-weighted revision probability. Group composition is not exposed in the paper-level JSON. The analysis does not quantify change magnitude, timing, direction, or downstream decision impact.

Production archive records measure data behavior, not customer networks, firmware, device APIs, or duplicate commands. The family limitation explicitly warns that repository contract tests and production receipts do not measure those boundaries. This paper does not even claim a count of executed repository fixtures.

Exactly-once physical behavior is difficult when a device API lacks idempotency and acknowledgement. A controller can guarantee durable intent transitions locally, but a network failure after device acceptance can leave the caller uncertain. Device-specific reconciliation is required.

Finally, revision policies depend on appliance constraints. A revised charging plan may be safe to replace, while a heating or storage action already underway may need a different transition. This paper supplies identities and fail-closed principles, not a universal control policy. It makes no customer-savings or trading claim.

Practical implication

Persist an immutable observation ledger and a mutable-but-audited action state machine. The observation ledger accepts only recognized series, zones, intervals, units, resolutions, and monotonic revision identities. It stores the canonical payload hash. The action state machine records which observation produced the current plan, whether the command was armed, sent, acknowledged, replaced, or cancelled, and why.

Acquire the action transition before external side effects. If two workers race, only one should hold the transition token. If the same receipt is retried, return the stored outcome. When a genuine revision arrives, compare the newly computed plan with the active plan. A revision may update displayed state without changing the device; only an authorized state transition should trigger a new command.

Fail closed when revision lineage is absent, regresses, conflicts with a stored hash, targets an already elapsed interval, or arrives too late for a safe transition. Do not overwrite the prior observation. Preserve both versions and expose the blocked state. If the device acknowledgement is ambiguous, reconcile device state before retrying rather than assuming failure and repeating the call.

Reproducibility

Verify all five provenance hashes and both evidence-manifest artifact hashes. From the frozen revision summary, select rows with nonzero points, calculate each group’s revised-points percentage, confirm 1,804 rates, and calculate their mean as 18.772560105996472%. Run the deterministic day/row-block mean bootstrap using the paper-specific seed and confirm [17.41734175954391%, 20.21151469441113%].

A controller follow-up should publish separate production and fixture manifests. Production receipts would establish real duplicate, revision, action, and acknowledgement counts. Deterministic fixtures would establish expected behavior at each retry and crash boundary. Both should identify versions and hashes; neither should be described as the other.

A later data snapshot is a replication. It should retain this fixed evidence artifact and publish a new cutoff, source composition, estimator choice, and provenance rather than revising the historical percentage in place.

Disclosure

Analysis and drafting were model-assisted. This is a public working paper. It is not peer reviewed. Sources, assumptions, code, evidence hashes, and the estimator are disclosed. Voltcast maintains the internal architecture reference and produced the aggregate.

No customer command stream, device firmware, or repository-test run was measured. Volt has no live traders or live capital; C0R is the only paper strategy, and production weather forecasting is a non-trading service. This paper is not trading advice, an exactly-once guarantee, or a promise of household savings.

References

1. Google Search Central, Article structured data.
2. Google Search Central, Introduction to structured data markup in Google Search.
3. Google Search Central, Spam Policies for Google Web Search — Scaled content abuse.
4. ENTSO-E, Single Day-ahead Coupling (SDAC).
5. Voltcast, Voltcast Architecture.