Ask any program manager whether the program is under configuration control and the answer is always yes. Ask what was in the requirements baseline at the moment the Critical Design Review was held, which version of which documents, with which approved changes incorporated and which still pending, and the answer is far less confident. That gap is the whole subject of configuration management, and it is one of the least glamorous and most consequential disciplines in systems engineering. Configuration management is not filing. It is the discipline that lets a program state, with authority and at any moment, exactly what the system is supposed to be, how that definition came to be what it is, and what has changed since the last time everyone agreed on it. Without it, a program is a crowd of people building slightly different systems from slightly different assumptions, discovering the divergence only at integration, where it is most expensive to reconcile. The discipline is often mistaken for a records-keeping chore that adds friction, but its actual purpose is the opposite: it is what lets a large program move quickly without shaking itself apart, because everyone can rely on a shared, stable definition instead of stopping to confirm what the others believe the system is.
The discipline is usually described as four connected activities, and understanding them as a set rather than a checklist is what makes the difference. Configuration identification establishes what is under control, the configuration items, and gives each a unique, versioned identity so that a reference to a requirement or a drawing or an interface names a specific thing rather than a general one. Configuration control governs how those items change, through a defined process in which proposed changes are evaluated, dispositioned, and either approved or rejected by an authority with the standing to decide. Configuration status accounting records the state of every item and every change at every point in time, so the program can answer what the configuration was, not just what it is. And configuration audits verify that the system as built and as documented actually matches the configuration the program believes it approved. Drop any one of the four and the other three lose most of their value.
A baseline is the central concept, and the common misreading of it is what causes most of the trouble. A baseline is not a backup or a snapshot taken for safekeeping; it is a formally agreed, formally controlled definition of the system at a specific point in its life, a reference that everyone downstream is entitled to rely on and that no one is permitted to change unilaterally. Programs typically establish a functional baseline at the system requirements level, an allocated baseline as requirements are decomposed and allocated to the architecture, and a product baseline as the detailed design is completed. Each baseline is a promise: it says that this definition is stable, that work may proceed against it with confidence, and that if it must change, the change will come through a controlled process that notifies everyone the change affects. A baseline that anyone can quietly edit is not a baseline at all, it is just the current state wearing a more official-sounding name.
The promise is what makes change control the beating heart of configuration management rather than a bureaucratic tax on it. The reason a change to a baselined item has to go through a change board is not that programs enjoy meetings; it is that a baseline is something other people are relying on, and changing it without their knowledge breaks the reliance that made the baseline worth establishing. When a requirement in an approved baseline is proposed for change, the questions the process forces, what other requirements does this affect, what design work has already proceeded against the current version, what verification activities were planned around it, what will it cost in schedule and rework, are exactly the questions that separate a controlled program from one that discovers the consequences of a casual change three months later. Change control is the mechanism that keeps a baseline a promise instead of a suggestion.
The hard part of change control, and the part that determines whether it protects the program or merely slows it down, is impact assessment, and impact assessment is a traceability problem wearing a governance costume. To disposition a proposed change responsibly, the change board has to know what depends on the item being changed: which downstream requirements derive from it, which design elements implement it, which interfaces reference it, which verification activities were built to prove it, which trade studies assumed it. A change board that cannot see those dependencies is not assessing impact, it is guessing at it, and it will approve changes whose real cost surfaces only when the unmentioned dependency breaks. This is why configuration management and requirements traceability are not two separate disciplines that happen to coexist; they are two views of the same connected structure, and a program that maintains traceability but not configuration control, or the reverse, has built half a bridge.
Status accounting is the activity that programs most consistently underestimate, and its absence is felt most acutely at exactly the wrong moment, during an audit or an investigation. Status accounting is the ability to answer historical questions: what was the baseline when this decision was made, which changes had been approved but not yet incorporated at that date, what is the current disposition of change request forty-seven, when did this requirement acquire its current wording and who approved it. When a certification authority or a customer or an accident investigation asks what the configuration was at a particular moment, a program with real status accounting produces the answer as a record, and a program without it produces an archaeology project, reconstructing a past state from email threads and the memory of people who may no longer be on the program. The value of status accounting is invisible right up until the moment it is the only thing that matters.
None of the four activities works without a plan behind it, and the configuration management plan is the artifact that programs treat as a formality and later wish they had taken seriously. The plan is where the program decides, before the pressure is on, which items will be placed under control and at what point in their maturity, who sits on the change board and what authority they hold, how baselines are established and released, and what the naming and versioning conventions are so that identity means the same thing to everyone. A program without an agreed plan does not skip these decisions; it makes them ad hoc, differently, on each subsystem, and the inconsistency surfaces at integration when one team version-controls at the document level and another at the requirement level and neither can cleanly reconcile with the third. The plan is also where the program sets the granularity of control, and that choice has real consequences: control at too coarse a grain and a trivial change forces a whole document through the change board; too fine a grain and the process drowns in ceremony. Getting the plan right is unglamorous and pays off silently for the life of the program.
Configuration audits close the loop, and they exist because documentation and reality drift apart even in well-run programs, quietly and continuously. A functional configuration audit checks that the item actually meets the requirements its documentation claims it meets; a physical configuration audit checks that the item as built matches the item as documented, that the as-built configuration and the as-designed configuration are genuinely the same thing. These audits routinely surface the small, undocumented deviations that accumulate whenever people solve problems on the floor faster than the paperwork can follow, and each such deviation is a place where the program believes it has one system and actually has another. Catching that divergence before it reaches the field, or before it invalidates a verification result, is the entire reason the audits exist, and it is why configuration management cannot be purely a records discipline; at some point someone has to confirm that the records still describe the world.
Every one of these activities is easier to describe than to sustain, and the reason is that they all depend on the same thing: a definition of the system held as connected, versioned, controlled data rather than as a pile of documents whose relationships live only in people memory. This is the layer methodology-native tooling is built to hold. Hitt Hosting SE treats requirements, design elements, interfaces, and verification activities as first-class configuration items with real identity and history, so a baseline is a controlled state of the connected model rather than a folder copied to a dated directory. Because the dependencies between items are live relationships, a proposed change surfaces everything it affects for genuine impact assessment instead of a guess, status accounting is a query against recorded history rather than a reconstruction, and the drift that configuration audits exist to catch is flagged as it happens rather than discovered after the fact. The baseline goes back to being what it was always supposed to be, a promise the whole program can rely on, kept current by the tool instead of by heroic manual bookkeeping.