1 Scope and relationship to BUS-1§

PROVISIONAL First version of this part. Every construct here is new and expected to be challenged by the first real historian export.

1.1 Purpose§

This document specifies how historical time series travel in an exchange package: a declaration entity, bus:Series, and a sample format, bus-csv-1. Its object is the same as BUS-1’s — continuity. A building accumulates years of what it did, and that record is the evidence behind every retro-commissioning study, every energy baseline, every fault investigation, and every dispute about whether the chiller was always this bad. Today it lives in the vendor’s historian and leaves with the vendor.

Both mature semantic models punt exactly here, and in the same direction. Project Haystack treats history as a capability of the point — the his marker — addressed by the point’s own identifier through a live hisRead operation against a running server. Brick’s ref:TimeseriesReference is an external database pointer: a timeseries identifier and the name of the store it lives in. Both answers assume the system of record is still running and still cooperative, which is precisely the dependency this standard exists to remove. Neither carries the data. This part carries the data.

1.2 Relationship to BUS-1§

BUS-2 is not free-standing. It uses BUS-1’s datatypes (BUS-1 7), identity rules (BUS-1 6), entity envelope (BUS-1 8.1), package container and integrity machinery (BUS-1 16), completeness declaration (BUS-1 16.6), and conformance targets and grading (BUS-1 2, Annex A). A conformance claim against this part is a claim about a BUS-1 package, and nothing here modifies a BUS-1 requirement.

The seam between the parts is BUS-1 8.8. A point declares that durable history exists and over what extent; this part specifies how the history itself travels. The two statements are made by the same exporter in the same package and are checked against each other (test TS-7).

1.3 The division of labor: why samples are not entities§

The single structural decision in this part is that bulk samples are NOT JSON entities. The declaration of a series is an entity; the samples are a file inside the package, digested in the manifest like every other document and resource (BUS-1 16.5).

The decision is measured, not aesthetic. At 344,285 entities, JSON Schema validation took roughly a hundred seconds of a hundred-and-two second reference-implementation import, while every other stage took seconds. A single trended point at a fifteen-minute interval produces about 35,000 rows a year; a modest building trending two thousand points for a decade holds several hundred million. History is orders of magnitude more rows than the model is entities, and a format that pushed those rows through the entity envelope, the schema validator, and the canonicalizer would make every package with real history unimportable in practice. The wire format would be correct and the standard would be ignored.

NOTE The same measurement is why the package inspector runs schema validation as a separate opt-in stage. This part applies the lesson at the format level rather than the tooling level, which is where it stops being advice and starts being load-bearing.

1.4 What is out of scope§

• Analytics and forecasting — a series is a record of what happened. What it implies belongs to whoever analyzes it, and the internal shape of an analytic result remains deferred (BUS-1 1.3).
• Live streaming and query — this is a package standard. Protocols for subscribing to, querying, or trickling telemetry exist and are not its business.
• Compression beyond the container — the ZIP container already offers DEFLATED (BUS-1 16.2), and repetitive timestamped text compresses well under it. A columnar or binary encoding is a MINOR-version question for a future format token, to be raised only with scale evidence in hand.