The Cooling Alarm Is Only the Beginning

Imagine a fairly ordinary alert at 02:17: the building management system reports high inlet temperature at rack 07.

The alert may be perfectly valid. It has a timestamp, a location and a measured value. It probably reached the correct team. Still, there is not enough information to decide what to do.

Can we move some of the workloads out of that rack? Which servers are involved? Are those workloads replicated somewhere else? Do the available destinations share the same cooling or power domain? Is one of them already under maintenance? If we reduce capacity, which service or customer will notice first?

I chose a cooling alarm for this example because it sits directly on the boundary between IT and OT. The physical condition appears in one system, while most of its consequences are represented in several others. This is exactly the kind of boundary where operational automation becomes difficult.

One alarm, several valid models

Each system involved understands its own domain reasonably well.

The BMS knows about cooling zones, sensors and equipment state. A management controller can expose chassis health, fans and thermal readings. Redfish, for example, defines metrics for intake, ambient, internal and exhaust temperature. Kubernetes knows which workloads run on a node and what constraints were declared for them. An asset or service API knows who owns the application, how critical it is and perhaps which customer agreement applies.

None of these models is wrong. They were simply created for different purposes.

This is an important distinction. The problem is not that we forgot to install a monitoring product. In most cases, the organization already has the facts. What it does not have is a usable path through them.

The work between detection and decision

In practice, people provide that path.

Facilities identifies the rack and asks infrastructure for the servers installed there. Infrastructure maps them to operating systems or cluster nodes. A platform engineer checks which workloads are running. The application team reviews redundancy and service impact. Somebody also needs to verify planned changes and excluded destinations.

This process can work well because experienced operators carry a large part of the operational model in their heads. They know that a server name in Redfish corresponds to a Kubernetes node with another identifier, or that two apparently independent racks share the same cooling loop.

It is also difficult to automate for the same reason. The relationships are real, but they are implicit.

I use cross-system decision latency for the time spent gathering and validating this information, and operational context gap for the missing relationships between the source models. These are working names, not an attempt to invent a new technology category. They make visible a problem that otherwise tends to disappear inside phrases such as “manual investigation” or “integration work.”

Giving the problem a name helps us ask a better question: how much of the response time is caused by the incident itself, and how much is caused by reconstructing the operation before we can respond?

Why I would not begin by copying everything

The conventional answer is to move the data into a central platform and build the required views there. Sometimes that is the correct answer. Historical analysis, capacity planning, reporting and model training are all good reasons to maintain copies of operational data.

I am less convinced when the first objective is to make a live operational decision.

Once a copy becomes part of that path, we also need to establish its freshness, transformation rules and authority. A new source field needs to reach the central model. A source action still needs to be mapped back to the original API or protocol. Over time, the organization owns another operational system whose job is to imitate the systems that already exist.

It is possible to engineer around every one of these issues. The question is whether we should make that investment a prerequisite for answering the first cross-system query.

For this kind of decision, I prefer to begin closer to the sources. Let each system remain authoritative for its domain, expose a usable model over it and federate only the relationships that the operation needs. A data lake or historical pipeline can continue to exist beside that model. The two serve different purposes.

A model small enough to operate

We do not need to model the entire company before handling the cooling scenario. A useful first model could be expressed as a short chain:

flowchart TB
  subgraph facilities[Facilities]
    direction LR
    event[Cooling event] -->|affects| rack[Rack]
  end

  subgraph infrastructure[Infrastructure]
    direction LR
    chassis[Chassis] -->|hosts| node[Kubernetes node]
    node -->|runs| workload[Workload]
  end

  subgraph business[Business context]
    direction LR
    service[Service] -->|belongs to| customer[Customer / SLA]
  end

  rack -->|contains| chassis
  workload -->|supports| service

The syntax is not the point. What matters is that identity and relationships are made explicit. No source needs to own the complete chain, but an operator should be able to navigate it when a decision crosses those boundaries.

This is also where the discussion about agents becomes interesting. We can connect an agent to the BMS, Redfish, Kubernetes and the asset API through separate tools or MCP servers. The agent may be able to retrieve every individual fact. It still has to determine which identifiers refer to the same object, which relationships are relevant and which constraints must be checked before proposing an action.

I do not think an agent should have to rediscover that structure from scratch for every prompt. A bounded operational model gives it a more reasonable universe to work with. It can still reason, but it reasons over identities and relationships that the organization has made explicit.

The role of Kubling

Kubling should not replace the BMS, the server controller, Kubernetes or the asset system. Those systems know their domains better and should remain authoritative.

Kubling sits between their models. Providers expose source capabilities through a consistent contract, and the engine makes the resulting data queryable together. The query reaches the source directly, so a central copy is not required. Kubling instances can also be composed: a local instance can remain close to a site or group of sources, while another instance federates the views required across facilities or regions.

For the cooling example, a useful response could look like this:

Rack 07 has a sustained inlet temperature warning. Three active chassis are installed there and four Kubernetes nodes are running on them. Two customer-facing workloads are involved. One can be redistributed within its availability policy. The other has no valid destination outside the affected cooling domain, and the nearest alternative rack is under planned maintenance.

This is not a value that any single source can return. It is the result of traversing a model that preserves the authority of those sources.

Kubling providers may also expose mutations supported by the source. That makes actions technically possible, but it does not make them operationally safe by itself. Draining a Kubernetes node, changing a cooling setpoint or dispatching maintenance involves policy, validation and responsibility. Kubernetes provides a controlled drain procedure, but the command cannot decide whether the destination is acceptable for this particular operation.

For now, I am deliberately stopping at the decision boundary. Before automating the change, we need a reliable way to explain what is affected, which options are valid and why.

Before building the complete example

The complete implementation will connect this model to Redfish, Kubernetes and an asset API in Kubling. Its objective will be concrete: start with a rack under a thermal condition and return the affected nodes, workloads and services with one federated query.

Before building it, the next article follows the most immediate problem exposed by the diagram: how the same physical asset acquires different identities across Redfish, Kubernetes, asset and maintenance systems. That relationship has to be understood before it can become a trustworthy join.

The implementation will then force us to answer the less attractive questions, which are usually the useful ones: where those relationships are defined, what happens when an identifier is missing and which parts of the example can be reproduced with the providers available today.