One of the most persistent mistakes in enterprise infrastructure is treating changes as events rather than objects. An event happens and disappears. An object can be inspected, compared, rolled back, and learned from. Software engineering figured this out decades ago. Version control, pull requests, code review, automated testing, staged rollouts — all of these are mechanisms for making changes into objects that can be reasoned about. Infrastructure has been slower to adopt the same discipline, and that lag is costing us.
The surface area of infrastructure change is more complicated than application code. A meaningful change may touch cloud resources, network paths, DNS, certificates, IAM policies, runtime state, backups, monitoring configurations, and sometimes all of these at once. Each layer has its own state model, its own failure modes, and its own rollback complexity. That complexity is real. But it is not an argument against version discipline. It is an argument for a control plane that can hold all of those layers in a single structured object and make the whole thing inspectable at once.
When a change is an event, the only record of it is whatever the person who made it happened to write down. That record is incomplete by definition. It captures intent, not execution. It captures the expected outcome, not the actual one. When the same change needs to be repeated, reversed, or explained in a postmortem, you are working from a document rather than from the system itself. The gap between the document and reality is where incidents live.
When a change is an object, the system holds the full record. What was proposed. What was approved. What was executed, in what order, against what targets. What verification ran afterward. What the rollback procedure is and whether it was ever tested. That object can be diff'd against previous changes of the same type. It can be compared to what succeeded and what failed. It can surface patterns that no individual engineer would have noticed by reading tickets.
The goal is not to pretend infrastructure is simple code. The goal is to make infrastructure change as inspectable and as recoverable as code has become. That requires treating the change itself as a first-class artifact rather than a log entry. The teams that get there first will be the ones who can move fast without the constant fear that the thing they changed three months ago is now the thing that is quietly breaking something else.