What should a cloud simulation actually tell you before you make a change?
We just published a technical walkthrough of how Cloud World Model handles a simulation step.
The basic idea is simple:
Current state → Action → Simulated next state → Metrics → Recommendation
For example, if you stop a workload, the compute cost may disappear while databases, load balancers, storage, or networking resources keep running.
Instead of finding that out after changing production, Cloud World Model simulates the transition first and shows the resulting costs, utilization, latency, error rate, and resource state.
Under the hood, the simulation step currently runs through:
Rule engine → ML model → referee/blend → failure effects → autoscaling → final metrics
The part I’m most interested in getting feedback on from other builders is this:
What would you want a cloud simulation to tell you before you make a real infrastructure change?
Cost impact?
Failure risk?
Dependency impact?
Performance changes?
Something else?
Technical walkthrough:
https://www.cloudworldmodel.ai/blog/cloud-simulation-step-internals
Replies
None of the four, or rather all four are downstream of the one I actually want.
Before cost or risk or latency, I want to know what the simulation could not model. Your own example is the argument for it: stopping a workload leaves databases, load balancers and networking running. That is the case where the simulator was right. The dangerous case is the dependency it did not know existed, because then the output is a confident, tidy, wrong number and it is indistinguishable from a confident, tidy, right one.
So the first line of the report I would want is not "cost drops 40%". It is "here is what I simulated, here is what I could not see, and here is how much of your bill lives in that second bucket". A simulator that says nothing about its own coverage is asking to be trusted exactly where it is weakest.
Concretely, in your pipeline: the referee blends a rule engine with an ML model. When those two disagree sharply, does the disagreement reach the user, or does the blend quietly average it away? That is a confidence signal you already generate and probably discard.
Smaller second thing: put reversibility next to every recommendation. "Cost falls 40%, undoing this takes four minutes" is a completely different decision from the same saving where undoing it takes a day and a support ticket.
Cloud World Model
@rabnoor_s This is really good feedback. Especially the point about the simulator telling you what it couldn’t see before telling you what it thinks will happen.
We already capture some of the rule vs ML disagreement inside hybridDecision, but your point is making me think that shouldn’t just be an internal/debugging detail. The disagreement itself can be part of the confidence signal we expose to the user.
I also like the reversibility idea.
I’m going to take both of these back to the product: simulation coverage/unknowns + reversibility alongside recommendations.
Appreciate this. This is exactly the kind of feedback I was hoping to get from this thread.