One Asset, Four Identities

This article continues the data center scenario from The Cooling Alarm Is Only the Beginning. That example left us with a deceptively simple question: how do we know that the chassis reporting a thermal condition, the Kubernetes node running workloads and the asset referenced by the maintenance team are the same physical system?

A technician receives a work order to replace a failing power supply in a server identified as asset-4271. Before the chassis can be touched, the platform team needs to move its workloads. Kubernetes does not know asset-4271; it knows a node named worker-a17. Redfish reports the hardware condition under a ComputerSystem resource with its own UUID. The maintenance system refers to the same equipment as DC2-R07-U18.

In this simplified example, all four identifiers are supposed to lead us to the same physical server:

The decision sounds simple: drain the node before the technician starts. The dangerous part is hidden inside the phrase the node. Which Kubernetes object represents the chassis in the work order? Does the Redfish warning belong to that chassis or to another system managed by the same controller? Does the maintenance reference follow the physical server, the rack position or the function performed by the equipment?

Operators usually know how to answer these questions. The difficulty begins when we expect a query, workflow or agent to know as well.

Each identifier is valid inside its boundary

It is tempting to describe the four names as inconsistent data. That would miss why they exist.

Redfish models the system from the perspective of hardware management. Its ComputerSystem schema can expose a resource Id, UUID, SerialNumber and AssetTag, each with a different meaning. The Id is scoped to its resource collection, while the UUID and serial number can help correlate the system beyond that local API path.

Kubernetes has another responsibility. A Node is the compute resource on which the control plane places workloads. Its name identifies the Node object, and Kubernetes assumes that a resource recreated with the same name represents the same node. The project documentation explicitly warns that reusing the name for a changed physical host can produce inconsistencies. The Node API also carries values such as providerID, machineID and systemUUID, but their availability and lifecycle depend on the environment. That is useful correlation material, not a universal asset registry. The Kubernetes Node documentation explains this boundary in detail.

The asset and maintenance systems have equally legitimate views. One may track what the company owns; the other may track what technicians service at a location. Depending on local practice, replacing a motherboard, moving a chassis or reusing a rack position can preserve one identifier and invalidate another.

The names differ because the systems own different parts of the lifecycle. Forcing one identifier into every source would couple those lifecycles and make a local change somebody else's breaking change.

This problem has a name

I use operational identity fragmentation for the situation where several valid source identities describe the same operational subject, but the correspondence between them is implicit, incomplete or maintained by people.

The problem is not the number of identifiers. Four may be perfectly reasonable. The problem is that an action crosses their boundaries.

To prepare the maintenance safely, we need to move through a chain like this:

flowchart LR
  asset["Asset API<br/>asset-4271"] -->|refers to| server[Physical server]
  redfish["Redfish<br/>ComputerSystem UUID"] -->|describes| server
  kubernetes["Kubernetes<br/>worker-a17"] -->|runs on| server
  maintenance["Maintenance<br/>DC2-R07-U18"] -->|services| server

No source has to own the central object in exactly this form. It represents the relationship the operation needs. If that relationship lives only in a runbook or in the memory of the person on call, the organization still depends on it. It simply cannot query, validate or audit it reliably.

Uniqueness and sameness are different problems

This distinction matters in a federation.

A global primary key makes a row addressable without colliding with a row from another source. Kubling's calculated primary keys, described in Why Every Federated Row Needs a Unique Global Primary Key, can derive that identity from existing source fields without requiring the source to store a new value.

That solves uniqueness. It does not automatically prove that two independently unique rows refer to the same physical object.

asset-4271 and the Redfish ComputerSystem UUID can both be excellent identifiers while remaining unrelated until we declare how they correspond. The same applies to a Kubernetes Node. Matching the node name to a hostname may work in one environment and be dangerously optimistic in another. A join that happens to return a row is not yet an identity model.

For the relationship to be operationally useful, we need to know more than the values being compared:

• the scope in which each identifier is unique;
• which source is authoritative for each attribute;
• how the correspondence was established;
• whether it survives replacement, reprovisioning or relocation;
• what should happen when the identifiers conflict or disappear.

This is where modeling earns its place. The model does not make uncertain data certain. It makes the assumptions visible enough to test and govern.

Where should the correspondence live?

There is no universal answer.

If Redfish and Kubernetes expose a trustworthy common UUID, joining them directly may be sufficient. If an asset registry already governs the mapping, the federation should use it rather than invent another master. In other environments, a small mapping source maintained near the operation may be the most honest representation available.

The choice should follow the lifecycle of the relationship. A mapping managed by a platform team may be appropriate for cluster membership. A facilities or maintenance relationship may need to remain under site ownership. Centralizing every identity relationship would recreate the organizational dependency that federation was meant to avoid.

What I want from the federated model is not one corporate identifier imposed on every system. I want an explicit path between the identities, together with enough context to understand who owns it and when it is valid.

What Kubling changes today

Kubling can expose those autonomous source models in one query space and evaluate a query across them without first copying all of their data into a central store. Providers retain the source-specific contract. The engine handles federation, planning and execution. Calculated primary keys can make rows globally addressable even when a source does not provide a suitable key of its own.

Today, the correspondence can be expressed through modeled keys, source data and federated joins. That is already useful, but it leaves some of the relationship semantics inside schemas and queries.

We are working toward a lightweight ontology that makes identities and cross-source relationships more directly consumable. That work is not part of the public release yet. When it is, the goal will not be to generate a complete enterprise ontology. The useful scope is much smaller: expose the relationships required for a concrete operational decision and compose them as the federation grows.

That boundary matters. A central semantic project can become as large as a central data project. Kubling should let a team begin with the relationship needed to answer one question, while preserving the option to connect that model upward later.

The AI question comes after the identity question

An agent can be given four tools, one for each system in this example. Tool access does not tell it that asset-4271, the ComputerSystem UUID, worker-a17 and DC2-R07-U18 refer to the same server. It may discover the relationship from descriptions or matching fields, but then the operational identity depends on an inference made during that particular run.

Our hypothesis is that an explicit model reduces this reconstruction work and makes unsupported matches easier to detect. We have not run the comparison yet, and the Kubling artifacts needed to make it reproducible are still under construction.

When those artifacts are public, the experiment should be straightforward to inspect. We can build a fixed set of assets containing exact matches, stale mappings, missing identifiers and one deliberate conflict. Then we can ask the same operational questions under two conditions: separate source tools, and a bounded federated model. The useful observations will include correct matches, unsupported assumptions, refusal to act on incomplete context, source calls and consistency across repeated runs.

The point will not be to prove that an agent is generally smarter with Kubling. It will be to test whether making identity explicit changes its behavior in a specific operation.

Identity before automation

Back in the maintenance window, draining worker-a17 is only safe if we can justify why it is the node running on the chassis referenced by the work order. The operator should be able to inspect that path, see which source established each part and notice when the evidence is missing.

This is why data models return to the discussion when we move from dashboards to operational automation. Values tell us what each system observed. Identity tells us whether those observations belong to the same thing.

The four names are not the defect. The missing, invisible relationship between them is.

When an AI Agent Joins the Operation continues the series by asking what model, identity and authorization boundary an agent should receive before it reasons over this operation.