Your dashboard is not lying. Your data model is leaving things out.

The belief that a dashboard is objective runs deep. It shows numbers, and numbers do not lie. But a dashboard does not show reality. It shows a projection of reality determined by the data model underneath it, the KPI definitions that someone once chose, the context that was or was not attached to the data, and the way downtime, scrap and throughput were defined. Two factories with identical performance and a different data model show two entirely different OEE numbers, and both dashboards are correct.

Downtime classification is the most telling example. A planned stop for changeover counts as an availability loss in some definitions; in others it is excluded because it is considered inherent to the production plan. A microstop of 45 seconds is automatically captured by a system working with state change detection; a system that uses polling at a two-minute interval does not register it at all. The OEE calculated by one system is structurally higher than that of the other, not because production is better, but because the measurement method is different.

Shift context adds a second dimension. A downtime event that begins at the end of shift A and ends at the start of shift B is, in a system without explicit shift boundaries, split across two periods in a way that obscures responsibility. Product context does the same: a line processing a product with an inherently lower cycle time will show a lower performance score than the same line on a different product, unless the target speed per product type is included in the data model as a reference.

A Unified Namespace does not solve this by building better charts, but by formalising the meaning of data before it reaches a dashboard. In a UNS, every measurement carries not only a value and a timestamp but also an asset position in the hierarchy, a production context, a definition of the parameter being measured and a relationship with the KPI calculation based on it. That makes it possible to compare downtime on line 3 with downtime on line 7 without anyone manually verifying whether both lines use the same definition.

The implication for IT is relevant: when Power BI or Grafana consumes data from a contextualised layer, the logic does not need to live inside the dashboard itself. The KPI definition, the segmentation logic and the product context are already present in the data layer, which makes dashboards simpler, less error-prone and easier to maintain when definitions change.

The operations manager comparing his line performance over a week is in reality comparing the output of his data model, not the production itself. If he wants to trust that comparison, he needs to know that the definitions are consistent across every line, every shift and every product. That is not an IT question. It is an organisational question with a technical answer.

For the IT architect managing the platform, the semantic layer is not an optional enrichment but the core of credible reporting. Without consistent KPI definitions, product context and downtime classification, every performance discussion shifts from reality to methodology. 

Capture treats the historian not as a passive archive, but as a contextual analytical layer. Time-series values are only useful when they remain connected to the production reality in which they were created: the asset, line, batch, product, shift, operator context, event state and timestamp logic. Capture brings those dimensions into the data layer itself, so context does not have to be reconstructed manually after the fact.

That changes the role of historical data. A temperature peak is no longer just a value at a certain time. It becomes a measurement during a specific production run, on a specific line, under known process conditions, with a clear relationship to quality, downtime or performance outcomes. For quality managers and process engineers, that means root-cause analysis no longer starts with searching through disconnected traces. It starts from a structured historical record that can be queried, compared and trusted. Capture turns the historian from a storage system into a foundation for operational learning.