Find the half hour that matters.

A week of building measurements becomes one inspectable energy event, with the original readings and the limits of the conclusion attached.

01 / Building energy / Public-data replay · Reific · 15 September 2026 · 2 min read

The question

Which three consecutive 10-minute readings have the highest total appliance energy in the first seven complete days, and what can we conclude?

Source observations · Wh / 10-minute reading

Overview is downsampled for display; every selected-event reading is retained. Calculations use all 1,008 source readings.

Start with a question the data can answer.

We took the first seven complete days from a published building-energy dataset: 1,008 measurements at ten-minute intervals. The question is deliberately narrow: find the three consecutive readings with the greatest combined appliance energy. This gives an agent a concrete event to inspect without asking it to perform arithmetic over every row.

The selected period and method are explicit. The replay enumerates all 1,006 candidate windows, ranks their sums, and preserves the source rows for the maximum. There is no language-model call, learned anomaly detector, or customer deployment behind this example.

The result: 2,390 Wh in three readings.

The largest sum is 560 + 1,080 + 750 = 2,390 Wh, at the source timestamps 16 January 2016, 18:40, 18:50, and 19:00. Those three ten-minute energy intervals correspond to an average power of 4,780 W. The original CSV lines are 732–734, with the header counted as line 1.

The timestamp labels span twenty minutes; the three energy measurements each describe a ten-minute interval. The source does not say whether a timestamp labels the start or end of that interval, so we preserve its labels rather than inventing an exact interval boundary or timezone.

A maximum is an observation. A fault needs more evidence.

This window is the maximum in this week. That alone does not make it abnormal, wasteful, or faulty. An aggregate meter cannot identify the appliance responsible. A credible next step is to inspect device meters, schedules, and intervention records before recommending action.

The evidence packet carries that limit alongside the readings. Its usefulness is the audit trail: question, coverage, method, values, source rows, and the information still needed for a stronger conclusion.

Compare against a sensible simple baseline.

The complete 29-field CSV slice contains 250,068 tokens. Merely selecting the timestamp and appliance-energy columns reduces that to 16,838. The complete evidence JSON contains 529 tokens: 16,309 fewer than the projection, a 96.9% reduction for this specific input payload.

A short SQL query or Python aggregation can compute this result too. This example demonstrates the evidence interface and its exact payload size. It does not establish an advantage over a tool-using agent, better task resolution, or lower total agent cost.

Token counts and source files

Counted UTF-8 payload	Tokens	Inspect
Full selected CSV · 29 fields	250,068	CSV
Simple projection · timestamp + target signal	16,838	CSV
Complete evidence packet · includes provenance + limits	529	JSON

(16,838 − 529) ÷ 16,838 × 100 = 96.8583% less input payload than the two-column projection.

tiktoken==0.11.0 · o200k_base · 1,008 readings. No model calls were made. This measures serialized text size; it does not measure total token burn, resolution, latency, or an advantage over equivalent SQL or Python tools.

Inspect the exact evidence packet

{
  "schema": "reific.reference-evidence.v1",
  "status": "deterministic_public_data_replay",
  "question": "Which three consecutive 10-minute readings have the highest total appliance energy in the first seven complete days, and what can we conclude?",
  "source": {
    "dataset": "UCI Appliances Energy Prediction",
    "doi": "10.24432/C5VC8G",
    "file": "energydata_complete.csv",
    "sha256": "2820bf712ad0275cb18b85a05250926100d8e65ebb9f4d2d016ca91ea152a25d",
    "row_numbering": "1-based physical CSV lines; header is line 1",
    "timezone": "not supplied; retain source-local timestamps"
  },
  "coverage": {
    "start": "2016-01-12 00:00:00",
    "end": "2016-01-18 23:50:00",
    "samples": 1008,
    "cadence_seconds": 600,
    "missing_appliance_values": 0,
    "candidate_windows": 1006
  },
  "finding": {
    "type": "maximum_rolling_three_reading_energy",
    "first_reading": "2016-01-16 18:40:00",
    "last_reading": "2016-01-16 19:00:00",
    "reading_count": 3,
    "covered_energy_intervals_minutes": 30,
    "total_energy_Wh": 2390,
    "equivalent_average_power_W": 4780,
    "source_rows": [
      732,
      733,
      734
    ],
    "observed_values_Wh": [
      560,
      1080,
      750
    ],
    "ties_at_maximum": 1,
    "tie_break": "earliest first-reading timestamp"
  },
  "limits": [
    "This identifies a maximum in the selected week, not an abnormal or faulty state.",
    "Aggregate appliance energy does not identify which device ran or establish a cause.",
    "Source timestamps do not specify whether each 10-minute interval begins or ends at its label.",
    "A script with the same aggregation can produce the same finding; no model advantage is measured."
  ],
  "next_evidence": "Device-level meters, schedules, and intervention records are required for a device or fault attribution."
}

Verified by the replay

Source bytes match recorded SHA-256
All 1,008 readings have an exact 10-minute cadence
All 1,006 candidate windows were compared
Recorded source rows reproduce the maximum sum

These checks verify the deterministic artifact. They are not task-resolution or model-accuracy scores.

Sources and attribution

The source data are attributed to their authors under CC BY 4.0. Reific selected, serialized, and analyzed the data for this reference replay. No affiliation or endorsement is implied.