The Historian Pattern
Industrial historians have existed for decades - storing time-series data from PLCs, SCADA systems, and sensors. Modern time-series databases like InfluxDB and TimescaleDB are the natural successors: purpose-built for high-frequency, append-heavy workloads with time-based queries.
But the historian is only as useful as the data it receives. And in most industrial architectures, that data arrives raw - unstructured, uncontextualized, and inconsistent.
What Structure Means for Time-Series
A raw Modbus register value landing in a time-series database is a number with a timestamp. It has no inherent meaning. The interpretation - what asset, what measurement, what unit, what quality - lives in a separate configuration system or in an engineer's memory.
Structured time-series data carries:
- Measurement identity derived from the ISA-95 namespace, not device-specific addressing
- Tag metadata including asset, area, line, and cell context
- Quality indicators from the source protocol - not inferred after the fact
- Consistent timestamps acquired at the source with known precision
When data is structured before it reaches the historian, every query returns meaningful results without post-hoc joins or interpretation logic.
UNS to Measurement Mapping
KŌJŌ Stack maps the Unified Namespace hierarchy directly to time-series database concepts:
- Namespace path → measurement name (InfluxDB) or hypertable (TimescaleDB)
- Asset context → tag keys that enable filtering by site, area, line, or cell
- Tag identity → field keys with consistent naming across all sources
- Quality and provenance → additional tag keys for filtering and alerting
This mapping is deterministic - the same namespace path always produces the same measurement structure. Adding a new source or site follows the existing pattern without schema migration.
Buffered Delivery
Industrial environments have unreliable networks. A historian destination that assumes continuous connectivity will lose data silently. The data plane must buffer locally and replay on reconnection - preserving original timestamps and ordering.
This is not optional for operational historians. A gap in the time-series record is not just missing data - it is missing operational context that may be needed for compliance, root cause analysis, or regulatory reporting.
Two Tiers: Edge and Enterprise
Not every historian question is answered in the same place. Line engineers need recent history at the panel; the enterprise needs one long-term record across every site. KŌJŌ Stack serves both tiers from the same platform.
At the edge, a KŌJŌ runtime acquires data natively, structures it, and writes to a local historian workload sized for bounded, recent-window storage. SCADA screens and line engineers query that history on-site, with no round trip to the enterprise. The same runtime also publishes the structured, reduced stream to an edge MQTT or Kafka broker.
OT devices are not allowed to reach past the plant's DMZ, so that second KŌJŌ runtime lives in the DMZ: it subscribes to the edge broker and forwards to a central historian - on-premises or in the cloud - consolidating many sites into one record. If the historian itself sits in the DMZ, the edge egress writes to it directly and no forwarder is needed. Either way, because the same platform governs both tiers, structure, quality, and timestamps are identical whether you read from the panel or from the enterprise historian.
Store Less, Trust More
Structure makes history meaningful. Two more properties make it affordable and dependable.
- Report-by-exception captures every meaningful state change and drops the noise at the source, so constrained links and edge storage carry signal rather than raw volume.
- Trend compression stores far less while preserving the shape of each trend within a bounded, configurable accuracy envelope - long retention on modest edge storage without discarding the signal.
- Trustworthy trends keep averages and statistics accurate even when tags report irregularly or only on change, so roll-ups and analytics reflect what actually happened instead of skewing toward whichever samples happened to arrive.
- Flexible retrieval returns each tag the way a consumer needs it - interpolated, stepped, or cyclic - so dashboards, reports, and models each read the right sample shape from the same stored history.
The result is a historian that holds more history for less, and answers questions consistently no matter who is asking.
What Changes
When the data plane structures and buffers data before it reaches the historian:
- Historians receive queryable, contextualized time-series data from the first write
- Schema consistency is guaranteed across all sources, sites, and protocols
- Network interruptions do not create gaps - buffered data replays in order
- Adding new historians or analytics destinations is a routing decision, not a data engineering project
The historian stores what the data plane delivers. If the data plane delivers structured, contextualized, reliable data - the historian is immediately useful. If it delivers raw telemetry - the historian is just another place where unstructured data accumulates.