Phase 4 specifies how WIA-DATA-014 integrates with existing time-series tooling: OpenMetrics / Prometheus exposition format, InfluxDB line protocol, OpenTelemetry metric SDK, Apache Kafka for event streaming, S3 / GCS / Azure Blob for cold archive.
OpenMetrics 1.0 is the industry standard for operational metrics exposition. The bridge translates each Prometheus metric exposition into a WIA-DATA-014 series envelope (one-time on first scrape) plus a stream of point envelopes. Counters become monotonic series; gauges become point-in-time series; histograms become composite series with per-bucket points.
InfluxDB line protocol is the de-facto IoT ingest format. The bridge accepts line-protocol payloads at /tsd/influx and translates each measurement to the WIA point envelope. The bridge preserves InfluxDB tags as WIA labels and InfluxDB fields as WIA point values; multi-field InfluxDB measurements become multiple WIA points sharing the same captured_at.
OpenTelemetry metrics are emitted as OTLP (gRPC or HTTP) by instrumented application code. The bridge subscribes to OTLP endpoints, translates each metric into the WIA envelope, and forwards. The bridge preserves the OpenTelemetry resource attributes as WIA labels with a otel. prefix.
For very high-volume ingest (millions of points per second), a Kafka bridge separates ingest from query: producers publish WIA envelopes to a Kafka topic, the WIA host consumes from the topic and writes to its time-series store. Kafka\x27s replay semantics let operators rewind on failure without contacting individual producers.
The cold archive bridge writes Parquet files to S3 / GCS / Azure Blob with deterministic per-day naming. The WIA host indexes the archive on demand: a query for old data triggers a list-and-fetch from cold storage rather than a query of the live store.
Phase 4 keeps WIA-DATA-014 from being yet another silo. The standard is positioned as a thin layer that bridges to the existing tooling rather than replacing it.
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.