The long-term moat for Nexplane is not the model. Any team can call the same APIs. The model is a capability that is available to everyone. What is not available to everyone is accumulated operational memory — the specific record of what kinds of changes, against what kinds of infrastructure, in what kinds of environments, succeeded or failed and why. That is the thing that takes time to build and cannot be replicated by switching models.

The change request is the right unit of observation for this. A change request captures intent, proposed plan, execution steps, verification signals, outcome, and — when things go wrong — rollback. If you observe enough of those over time, across enough organizations and environments, you start to accumulate something genuinely valuable: a structured understanding of which plans tend to succeed, which tend to fail, which kinds of changes carry hidden dependencies, which rollback approaches actually work under pressure. That is different from what a general-purpose language model can offer. A language model can reason about infrastructure in the abstract. Infrastructure change intelligence is specific.

Concretely, accumulated operational memory means things like: knowing that key rotation changes in environments with certain authentication architectures tend to surface a particular class of dependency problem that the original plan did not account for. Knowing that network segmentation changes of a certain scope almost always require a verification step that teams skip. Knowing that rollback of a certain type of change frequently fails in a particular way and that the plan should be structured differently to account for it. These are not things you learn from training data. These are things you learn from watching real changes execute against real systems.

This is why the structured change request matters from day one, not just as a workflow tool but as a data model. Every change that flows through the platform is a training example. Not in the model fine-tuning sense necessarily — but in the sense that the platform can observe patterns, surface them at planning time, and eventually use them to make better recommendations. The platform gets smarter as it sees more. That compounding effect is what creates durable value that competitors cannot simply copy by using the same underlying model.

I want to be clear about what this is and is not. This is not a pitch for surveillance or data harvesting. Organizations should own their own change data. The point is that the platform's ability to reason about risk, flag likely failure modes, and produce better plans should improve over time as it accumulates operational experience. The value is not just generation. The value is judgment earned through observation. A junior engineer can generate a script. A senior engineer who has watched dozens of similar changes execute knows where the script is likely to break. Infrastructure change intelligence is an attempt to make that experience systematic rather than personal.