A time-series data point in WIA-DATA-014 consists of a timestamp, a series identifier, a value, optional labels for filtering and grouping, and a signature.
Three principles guide schema design in WIA-DATA-014: (1) the series identifier should be stable and human-readable so that operators can grep their dashboards for it; (2) labels should be low-cardinality (under 1000 distinct values per label) to avoid blowing out the index of the underlying time-series database; (3) high-cardinality dimensions (per-request trace IDs, per-user identifiers) should be carried in a separate event store rather than as labels on a metric.
The standard does not distinguish "tags" from "fields" the way some vendor formats do (InfluxDB, for example, treats tags as indexed and fields as unindexed). WIA-DATA-014 has only labels (always indexed) and the point value itself; if you need an unindexed metadata payload you carry it as a separate annotation envelope keyed to the same series_id and timestamp.
Cardinality (the number of distinct (series_id, label set) combinations) is the dominant cost driver in any time-series system. The standard recommends a per-series cardinality budget published in the series envelope so that downstream consumers can plan their query optimisation around the budget. Hosts MAY refuse a write that would push a series past its declared budget, returning a problem document of type .../cardinality-exceeded.
Every series declares a retention policy in its envelope: how long to keep raw points (1 Hz cadence), what cadence to downsample to after a given age, and what cadence to archive at long-term. Typical industrial deployment: 90 days raw, 1 year at 60s rollup, 5 years at 1h rollup, then archive to cold storage. The standard requires the policy to be explicit so that capacity planning is not magic.
Mobile-device sensors and edge gateways frequently emit measurements with timestamps in the past (the device buffered the measurement during a network outage, then flushed when it reconnected). The standard requires hosts to accept late points up to a configurable bound (default 24 hours) and to trigger a re-rollup of the affected window. Late points beyond the bound MAY be rejected with a problem document of type .../point-too-late; the bound MUST be advertised in the discovery document.
Proper data modeling is crucial for efficient storage and querying. The WIA-DATA-014 schema design principles (stable series IDs, low-cardinality labels, explicit retention policies, late-point handling) make implementations predictable across vendors.
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.