System01
System or facility view
Close to the source
Connect providers to a bounded set of systems at a site or operational domain.
Data center operations
Make one operational decision across facilities and compute.
Cooling, power, server health, workload placement and maintenance rarely share a system. Kubling gives them a working model without first copying them into a central platform.
operational questionlive + modeled
Can we reduce load on rack 07 without breaking service redundancy?
useful answer
Find the workloads running on affected hardware, preserve shared power and cooling constraints, exclude destinations under maintenance, then send changes only to the systems that own them.
live state
relationships
valid action
The systems involved
The decision crosses boundaries. Ownership does not have to.
Each source keeps its connection details and native behavior. Kubling gives the engine a model it can plan across.
Facility systems
Cooling zones, alarms and available capacity
BMS API or source-specific provider
Redfish / BMC
Server inventory, sensors and hardware health
API integration or custom provider
Kubernetes
Current workload placement and supported mutations
Official external provider
CMDB and maintenance
Ownership, dependencies and active work windows
OpenAPI provider or database source
The operational model
Give raw state enough structure to support a decision.
The model names the entities and relationships that matter in this domain. Agents and applications can use that context without inventing it again for every request.
workloadruns_onnode
nodeinstalled_inrack
rackcooled_bycooling_loop
rackpowered_bypower_domain
assetaffected_bymaintenance_window
reasoning boundarymodel + live state
01
Locate the impact
Resolve the live warning to racks, nodes, workloads and service dependencies.
02
Test the alternatives
Remove targets that are full, under maintenance or share the same failure domain.
03
Act through the owner
Keep the facility system, Kubernetes and each API authoritative for its own changes.
Deployment topology
Start at the operational boundary. Connect upward only when it helps.
Domain02
Data center view
Aggregate local instances
Join facilities, compute, networks and maintenance without replacing their local models.
Cross-domain03
Fleet view, when needed
Connect sites selectively
Add a wider operational view only for decisions that truly cross data centers.
System, domain and cross-domain describe roles in a topology, not products you must deploy as a fixed stack. A Kubling instance can use local providers, federate other Kubling instances, or do both.
Available now
Build from current capabilities.
Kubling does not ship a universal data-center model. The value is that your asset relationships and operating rules sit above live, source-owned state.
Kubernetes provider
Discovers one cluster per provider instance and supports the mutations exposed by each resource.
OpenAPI provider
Turns API operations into relational entities. Write mappings remain explicit and auditable.
Instance federation
A Kubling instance can be a source for another one, so a site can stay autonomous and still join a larger topology.
Start with proof
Prove it with one source. Grow without changing the execution model.
Query and mutate through a local provider, then replace the source when you are ready. The engine still plans against the same schema and capability contract.