A black-box conformance test suite is published at https://github.com/WIA-Official/wia-time-series-data-conformance and walks through discovery document round-trip, write with idempotency-key collision, query with all aggregation types, stream subscribe / reconnect with Last-Event-Id, rollup request, federation handshake against a mock peer, replay-defence bounds, audience-control enforcement, late-arriving points re-rollup, rate-limit headers and exhaustion behaviour. Hosts publishing bridge_profile=Full SHOULD additionally pass the suite\x27s extension tests for at least one supported third-party time-series database.
The wia/time-series-data-host:1.0.0 container image implements every Phase 2 endpoint with mock data; integrators exercise their bridge against it before going to production. The container ships with a SQLite-backed store suitable for small-to-medium scale (up to 10 million points per series); production deployments typically swap in a purpose-built time-series database (InfluxDB, TimescaleDB, VictoriaMetrics, Apache IoTDB) via the WIA-supplied schema.
| Version | Focus |
|---|---|
| 1.0.0 | Initial publication: Phases 1–4 stable, conformance suite v1, reference container |
| 1.1.x | Additive: more bridges (TimescaleDB native, ClickHouse, QuestDB), additional aggregations (percentiles, histograms), optional WIA-AIR-SHIELD scoring |
| 1.2.x | Additive: federated query (a query against multiple hosts that returns a unified result) |
| 2.0.0 (no earlier than 2028) | Possible breaking change: post-quantum signature suite migration following the parent WIA family roadmap |
Within the 1.x line every Phase 2 endpoint MUST remain reachable and MUST continue to honour the documented status codes and content shapes. Hosts MAY add optional query parameters, response fields, new endpoints, or media types. Hosts MUST NOT remove or repurpose existing ones. Breaking changes ride a major version bump and MUST be preceded by a 12-month deprecation window per IETF RFC 8594 and RFC 9745.
The standard is maintained by the WIA Standards Committee. Change proposals follow the WIA RFC process: anyone may submit a proposal; the Committee reviews quarterly; accepted proposals enter an open comment period before being merged into a minor-version release. Breaking changes require a two-thirds Committee vote.
Time-series data is the connective tissue of operations: every modern infrastructure system, IoT deployment, financial market platform, and scientific instrument generates time-series data. The dominant pattern today is per-vendor silos that prevent a unified operational view. WIA-DATA-014 exists to close that gap with an open, federation-aware, audit-logged standard that lets operators and consumers share data on terms each can verify.
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.