Phase 1 specifies the JSON envelopes for time-series data: series definitions, individual points, query envelopes, and rollup requests. Every envelope is signed with Ed25519 (IETF RFC 8032) so that signed payloads survive intermediate processing.
The series envelope is the registration record. It declares the series name, unit (UCUM code), label set, retention policy, and downsampling rules. Hosts use the envelope to provision storage with the right retention bounds before any points arrive.
{
"wia_time_series_data_version": "1.0.0",
"type": "series",
"series_id": "ts_temperature_kitchen_sensor_A",
"unit": "Cel",
"labels": { "env": "production", "region": "us-east-1" },
"retention_seconds": 2592000,
"downsampling_policy": [
{ "from_resolution_seconds": 1, "after_seconds": 3600,
"to_resolution_seconds": 60 },
{ "from_resolution_seconds": 60, "after_seconds": 604800,
"to_resolution_seconds": 3600 }
],
"signature": { "alg": "Ed25519", "value": "..." }
}One observation. Required fields: series_id, captured_at, value, value_type. The captured_at timestamp is RFC 3339 UTC with millisecond precision (sub-second precision required for streams at ≥ 1 Hz).
A query envelope expresses a structured request: which series, which time window, which aggregation, which resolution. Hosts execute the query against their internal index; the response is a stream of points or a single aggregate value depending on the requested resolution.
Operators trigger explicit rollups via the rollup request envelope. The host computes the rollup over the requested time window and stores the result at the target resolution. Rollups are idempotent at the host level — re-running the same rollup yields the same result, allowing operators to safely retry.
Phase 1 envelopes are the source of truth for the wire format. JSON Schema 2020-12 documents at /spec/schemas/ are the authoritative validation reference.
This chapter participates in the WIA-DATA-014 8-chapter survey. Each chapter is intended to be readable standalone, but together they map the full surface of the standard. Chapter 1 sets context, Chapters 2-3 cover modeling and storage trade-offs, Chapters 4-7 walk the four-Phase specification, and Chapter 8 closes with conformance and roadmap.
https://github.com/WIA-Official/wia-time-series-data-conformance is the single source of truth for what your implementation needs to pass.wia/time-series-data-host:1.0.0 implements every Phase 2 endpoint with mock data; integrators exercise their bridge against it before going to production.cli/time-series-data.sh ships sample envelope generators (validate, series, point, query, rollup, info subcommands) so an implementer can produce conformant payloads without hand-rolling JSON.Three operational concerns recur across time-series implementations and are baked into the standard. First, cardinality management: every label dimension multiplies the number of distinct series the host must index, and beyond a few million distinct combinations index lookup latency degrades sharply. The standard recommends declaring per-series cardinality budgets and refusing writes that would push past them. Second, late-arriving points: mobile and edge sensors frequently emit measurements with timestamps in the past after a network outage; the standard requires hosts to accept late points up to a configurable bound (default 24 hours) and trigger a re-rollup. Third, retention policy: every series declares explicit retention bounds and downsampling rules, so capacity planning is not magic and operators can reason about long-term storage cost from the moment they create a series.
https://openmetrics.io/ — covers the operational metrics exposition format that Phase 4 §7.2 bridges from.