# 12B Separating Configuration from Runtime State

Configuration describes how a system is intended to behave, while runtime state describes what it is actually doing at a particular moment.
A file may say that a service should start automatically, but the current process can still be stopped because an earlier attempt failed.
Likewise, changing a configuration file does not always update a running process immediately; some applications need a reload or a restart.
I therefore ask which settings were changed, when they were applied, and what evidence shows that the service is using them now.
This distinction is especially useful when a project has separate local, testing, and production environments that share similar names.
A successful change on my laptop does not prove that the same configuration is active on the server used by other people.
I also distinguish unavailable from stopped, because a service can be running but unreachable from a particular client or network.
An explanation should name the environment and the observed state, rather than simply say that everything is online or offline.
When the settings and state are documented separately, it becomes easier to repeat a setup and understand why two machines behave differently.
The result is a more reliable conversation about what needs to change, what is already correct, and what still requires direct observation.