Phase 3 specifies how independent hosts federate: a vendor cloud emitting data, a downstream aggregator subscribing to many vendor clouds, a regulator subscribing to a small number of clouds for compliance reasons. The handshake state machine, replay defence bounds, and audience controls make multi-host operation safe.
The handshake reuses the WIA-SOCIAL Phase 3 §5 receipt shape so vendor implementations can share their federation library across multiple WIA family standards. State machine: IDLE → PENDING (origin verifies signature) → ACCEPTED (origin issues receipt) → optional REVOKED.
Each signed envelope carries a 96-bit nonce and an RFC 3339 timestamp. Receivers MUST reject envelopes with skew > ±300 seconds, reject envelopes whose (signer, nonce) tuple has been seen within the last 600 seconds, and maintain the seen-nonce cache for at least 600 seconds. For high-volume time-series ingestion, the cache MAY be a Bloom filter; false positives MUST trigger a re-fetch via the standard\x27s pull endpoints rather than silent drops.
The same time series can carry very different sensitivity profiles depending on the deployment (an industrial vibration sensor is operationally sensitive but not personally identifying; a home thermostat reveals occupancy). The standard requires the host to declare the per-series sensitivity classification and the consumer to match the declared audience.
An operator transferring a series from one host to another (cloud migration, vendor change, on-prem to cloud) signs a series_move envelope. The new host fetches the series history from the prior host over a federated read; the old host returns 301 Moved Permanently for the series URL for at least 12 months.
Federation is what makes WIA-DATA-014 more than a vendor format — it is a wire format that survives organisational boundaries with auditable trust establishment between participants.
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.