How precise and timely are negative-price alerts?

Abstract

Negative-price alerts are useful only when their underlying curve is complete, their classification is correct, and their notification arrives before a household decision. The frozen evidence measures one of those properties: server-side notification timeliness after complete-curve detection. Across 2,141 production-origin auction publication receipts, the 95th-percentile detection-to-notification latency was 1.0 second. The regenerated artifact reports no uncertainty interval for the 1.0-second tail statistic.

The evidence includes no negative-price truth table, false positives, false negatives, alert suppression, destination delivery, or household-device acknowledgement. It therefore does not measure “precision” in the classification sense and does not establish end-to-end alert latency. The measured result is narrower: successful infrastructure fan-out was usually rapid after the system identified a complete auction curve. A safe integration should separately validate curve completeness, target zone and date, native intervals, negative-price predicate, revision identity, and freshness before notifying or acting. It should fail closed on missing or inconsistent fields and deduplicate revisions. Production receipts ground the timing result; suggested corrupt-price and incomplete-curve scenarios are deterministic fault injections for a future alert test, not repository tests claimed here.

Plain-language answer

The measured part is timely: among 2,141 successful auction notification receipts, 95% had been sent within 1.0 second of complete-curve detection. That clock starts after Voltcast detected the completed curve. It does not start when an exchange closed its gate, and it does not stop when a phone, n8n workflow, Home Assistant instance, or device received or acted on the alert.

The paper cannot answer how precise the negative-price classification was. The public evidence contains no counts of correctly alerted negative intervals, false alerts, or missed negative intervals. A 1-second notification can still be wrong if it was generated from an incomplete day, the wrong zone, a stale revision, or an incorrect threshold.

Use the timing result as one component of a larger contract. Before an alert is eligible, prove that the target curve is complete and current. Then evaluate the declared predicate, such as whether any native interval price is below zero. If the data fail validation, send an “unavailable” status rather than a negative-price claim or device command.

Research question

The research question has two parts. First, how quickly does the notification rail fan out an alert after a complete day-ahead curve is detected? Second, how accurately does a negative-price alert correspond to the realized predicate in that validated curve?

Only the first part is observable in the frozen outcome. The primary metric is the 95th percentile of notified_at - detected_at across production auction publication receipts. It is a serving-infrastructure measure. The second part would require a linked classification ledger containing every eligible curve, its negative-price truth label, the alert decision, any suppression rule, and a stable revision identity.

The decision problem is not merely “is the latency low?” A robust household integration needs an eligibility gate. No alert should be emitted from a partial curve, a mismatched delivery date, an unsupported resolution, or a stale cached response. Precision and timeliness must be measured on the same decision identity, but this paper refuses to infer the absent precision half from the available timing half.

Data and provenance

The public JSON binds the paper to schema volt-home-paper-evidence-v1, status measured, and publication cutoff 2026-08-30T00:00:00Z. Its primary sample consists of 2,141 auction publication receipts from the frozen corpus. The extraction selected zone, delivery date, period count, detected_at, notified_at, and the elapsed notification seconds. The family contract also names grid revisions, ingestion runs, public API schemas, and repository integration fixtures.

The source snapshot was extracted from production with a SELECT-only, read-only transaction and a 180-second statement timeout. The snapshot SHA-256 is 7e97489fc8528c8cc8c38830e05b48d949ce1f67b98575dff26f5d7c321e4c67. The analysis-code SHA-256 is 57c57de79cdab2b5b6d6c54c485cb5162598c5ba0b0bfe995da40d75e6c52ba9; the protocol SHA-256 is adb36bf6b447af9f96339249b8becaefc20422499cca1977242866347a97bd4b; the paper-registry SHA-256 is 7bcb91d7476d0a69fe9fa75a5c7782f8117e0153f82f9112b7e1d307d3943717; and the source-registry SHA-256 is 07949550ac443ff673fda5c0209b99f137544f3ffecf6775f109bb9d09663bd6. The evidence-manifest hashes are 5ae0056d6c8e06c4cac841897925e753e7c0373ae7c2c2dc01d25b16e616915b for the JSON and 74841c05b4c69e244023f2acb820a0f67e0f418f60f07433a6dcc2a5caf2067e for the WebP figure. The common detailed data window runs from 2025-10-01 through 2026-08-29, while the publication receipt rail has its own actual coverage within the extracted data.

These rows are production receipts for infrastructure detection and notification timestamps. They are not raw upstream exchange records, destination acknowledgements, or customer-device traces. They also do not encode whether the completed curve contained a negative interval. Any example involving a corrupted price, omitted interval, or false alert is a proposed deterministic fixture, clearly separate from the production timing evidence.

Method

The analysis filtered finite notification-delay values and calculated the 95th percentile. That quantile is the primary result: 1.0 second across 2,141 receipts. The figure also presents the median, 90th, 95th, and 99th percentile positions from the same delay distribution, although only the primary value is enumerated in the public JSON.

The regenerated evidence records bootstrap_95_interval: null and interval_method: "not reported for this estimand". No interval is available for the P95 estimator, and the paper does not invent a quantile interval.

A complete alert-verification method would join each publication identity to its full ordered curve, validate expected interval coverage, calculate the negative predicate, and compare it with an alert ledger. Precision would be true negative-price alerts divided by all emitted negative-price alerts; recall would require all truly eligible curves as the denominator. End-to-end latency would use destination acknowledgement, not server notification time. Those metrics are specified here as future requirements and are not claimed as measured.

An architectural tradeoff follows. Alerting immediately on the first negative value minimizes delay but risks acting before the curve is complete. Waiting for complete-curve validation adds a gate but preserves correctness. The current timing metric starts after that gate, making it suitable for evaluating fan-out without pretending to measure upstream readiness.

Results

The primary result is a 1.0-second P95 auction notification latency, with 2,141 production-origin receipts. The evidence’s interpretation is explicit: timeliness is measured from complete-curve detection to notification, not from exchange gate closure.

The figure values are exactly 0.0, 1.0, 1.0, and 1.0 seconds for P50, P90, P95, and P99. The evidence reports no interval for P95, so the result is not accompanied by an uncertainty bracket.

No classification-precision result is available. There is no evidence-grounded percentage for correctly identified negative-price alerts, missed events, or false alerts. The answer is therefore asymmetric: notification timeliness after detection is measured; negative-price precision and destination timeliness are not.

Robustness and placebo checks

For the timing metric, a reproduction should verify monotonic clocks, non-negative elapsed times, finite values, and receipt uniqueness. It should examine whether repeated deliveries or retries create multiple rows for the same publication identity. The public aggregate does not expose those stratifications, so no robustness result is asserted beyond deterministic reproduction of the frozen calculation.

For classification, a future test should include deterministic curves with no negative intervals, one negative interval, multiple negative intervals, a zero-price boundary, a missing interval, duplicate timestamps, and a revision that changes the predicate. These are recommended fixtures, not measured repository checks. The no-negative curve is the essential placebo: it must never produce a negative-price alert. An incomplete curve should produce an unavailable state, not be counted as either positive or negative.

Production validation should compare alerts to a revision-aware truth ledger. It should report classification precision and recall separately from notification latency, and server fan-out separately from destination acknowledgement. Family-wide Holm control applies if multiple inferential alert comparisons are made. This paper remains descriptive and makes no significance claim.

Limitations

Receipt-based timing includes successful recorded notifications and may not represent failed attempts. Without the denominator of all eligible publications, it cannot estimate delivery availability. The timestamps end at the notification boundary and exclude queueing or processing inside n8n, Home Assistant, email, push services, or devices.

The metric is for auction notifications generally, while the title concerns negative-price alerts. The evidence does not prove that each timed receipt corresponded to a negative-price event. It measures infrastructure that can carry such alerts, not the semantic classifier itself.

No P95 interval is available, and none is fabricated. The analysis also does not stratify by zone, day, destination, or load.

Finally, repository fixtures are listed in the family contract, but this paper does not expose a run count or pass result for an alert suite. No customer network or firmware is measured. The result is not an alert-service guarantee.

Practical implication

Create an alert only after a strict eligibility function passes. Require a known zone, exact target delivery date, complete native interval coverage, valid prices and units, a recognized publication/revision identity, and a freshness threshold tied to the decision window. Evaluate the negative-price predicate on that immutable curve. Store the predicate, curve hash, rule version, and alert identity together.

Use an idempotency key that distinguishes the event identity from the transport attempt. A retry may resend the same alert notification without creating another household action. If a revision changes the negative-price set, apply a documented update or cancellation rule; do not execute both the old and new schedule blindly.

If validation fails, do not infer “no negative prices.” Return “unknown” or “unavailable,” preserve the last validated state for display, and follow an appliance-safe fallback. Alert consumers should distinguish informational notifications from control authorization. A fast message is not permission to act unless its evidence identity is valid and current.

Reproducibility

Verify all five provenance hashes and both evidence-manifest artifact hashes. From the frozen auction publication rows, calculate notified_at - detected_at in seconds for finite values, confirm 2,141 observations, compute the 95th percentile as 1.0 second, and confirm that the evidence reports no interval for this estimand.

A new precision study should preregister curve eligibility, truth construction, threshold semantics, revision handling, duplicate handling, precision, recall, destination latency, and failure denominators. It should keep production receipts separate from deterministic fault-injection fixtures and identify every adapter or workflow version under test.

A later snapshot is a replication and should carry a new cutoff and hashes. The existing evidence must remain immutable so public claims can be audited against the exact calculation described here.

Disclosure

Analysis and drafting were model-assisted. This is a public working paper. It is not peer reviewed. Evidence provenance, assumptions, hashes, and limitations are disclosed. Voltcast produced the analyzed aggregate and publishes the cited internal architecture.

No customer device, n8n destination, or Home Assistant instance was measured. No repository test pass is claimed. Volt has no live traders or live capital; C0R is its only paper strategy, and production weather forecasting is non-trading. This paper is not trading advice, an alert guarantee, or a recommendation to control safety-critical equipment without device-specific safeguards.

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.