Engineering configuration management is the discipline that lets a team answer a deceptively simple question at any important moment: exactly what system are we talking about? It preserves the identity, relationships and approved state of requirements, designs, hardware, software, interfaces, models, documents and operating configurations as the system changes across time.
In one line: configuration management keeps change from destroying the identity of the thing being engineered.
WINTOUR HOUSE V1 · eduKATE PUBLISHING · ENGINEERING SERIES
Reader Job, Owner and Publication Boundary
Reader job: understand how engineering preserves one trustworthy identity across changing requirements, drawings, models, hardware, software, tests and operational states.
This article owns the engineering configuration-management layer: configuration planning, identification, baselines, version identity, change control, status accounting, audits and the relationship between as-required, as-designed, as-built, as-tested and as-operated states. How Systems Engineering Works remains the whole-system coordination owner. How Engineering Reviews Work owns evidence-based technical gates. How Engineering Testing Works owns test design and execution. How Quality Works remains the wider quality-system owner.
The identity question
Which exact requirements, drawings, models, parts, software versions and settings define this system state?
The change question
What changes, who approves them, what else is affected and which evidence becomes stale?
The trust question
Can another engineer reconstruct what was built, tested, accepted, deployed and operated?
Quick Read: The Configuration Management Mechanism
PRODUCT SCOPE → CONFIGURATION ITEMS → IDENTIFIERS → BASELINES → APPROVED STATE → CHANGE REQUEST → IMPACT ANALYSIS → DECISION → IMPLEMENTATION → VERIFICATION → STATUS ACCOUNTING → AUDIT → RELEASE → AS-BUILT / AS-TESTED / AS-OPERATED RECORD → FUTURE CHANGE → WORLD RETURN.
NASA describes configuration management as a life-cycle management discipline that provides visibility into and control of changes to functional, performance and physical characteristics. INCOSE likewise treats configuration management as the means by which the evolving design remains coherent and verifiable across its life cycle. The practical result is simple: the team should always know what state it has, why that state exists and which evidence belongs to it.
1. Configuration Management Exists Because Engineering Changes
No serious engineered system remains frozen from first idea to retirement. Requirements change. Suppliers change. Software changes. Parts become obsolete. Tests reveal weaknesses. Operators discover better procedures.
Configuration management makes those changes controlled rather than invisible.
2. Change Without Identity Creates Confusion
If a drawing changes but the installed hardware does not, “the system” now has at least two possible meanings.
Configuration management separates the approved definition from the actual physical or digital state so the mismatch is visible.
3. Configuration Is More Than Version Numbers
A configuration includes the set of characteristics and items that define the product at a particular time: requirements, hardware, software, settings, interfaces, documents and sometimes operating data or procedures.
A version label helps identify a state, but the state must still be defined.
4. A Configuration Item Is Something Worth Controlling
Configuration items are selected elements whose identity and changes need explicit control because they affect system integrity, interfaces, evidence, safety, support or lifecycle decisions.
Not every screw or paragraph requires equal control; the level should match consequence.
5. Selecting Configuration Items Is an Architecture Decision
Subsystem boundaries, software services, interface documents and replaceable units often become natural configuration items.
The selection should support change localisation, traceability and system understanding rather than mirror the organisation chart blindly.
6. Configuration Planning Defines the Rules Before Change Arrives
A configuration-management plan establishes scope, roles, identifiers, baselines, change authority, status records, audits, tools and lifecycle retention.
NASA’s handbook provides a dedicated CM-plan outline because configuration discipline is easier to design before the first major change than after confusion begins.
7. Identification Is the First Configuration Function
Items need names, numbers, revisions, versions or other unique identifiers.
Identity should be unambiguous enough that two engineers can refer to the same item without relying on memory or location.
8. Human-Friendly Names and Machine-Friendly IDs Serve Different Jobs
People benefit from descriptive names; systems benefit from stable identifiers.
Good configuration systems often preserve both so a renamed object does not become a new object accidentally.
9. Revision and Version Need Defined Meanings
Some organisations use revision for released states and version for working states; others use different conventions.
The specific convention matters less than using it consistently and documenting what each identifier means.
10. A Baseline Is an Approved Reference State
A baseline creates a stable point from which change can be measured.
It does not mean the system can never change. It means changes after that point become deliberate, visible and authorised.
11. Requirements Baselines Stabilise the Problem Definition
Once requirements are sufficiently mature, a baseline lets design teams work against an agreed set while later changes remain traceable.
Without a requirements baseline, teams can unknowingly design against different problem definitions.
12. Architecture Baselines Stabilise Major Structure
System boundaries, major functions, allocations and interfaces may be baselined so detailed design proceeds from a controlled structural model.
Architecture can still evolve, but consequential changes must be impact-assessed.
13. Design Baselines Stabilise the Definition of What Will Be Built
Released drawings, models, bills of material, code and specifications collectively define a buildable design state.
The release boundary distinguishes exploratory work from an authorised product definition.
14. Product Baselines Stabilise the Realised Configuration
Once the product is built and accepted, its actual hardware, software and documentation can become a controlled reference for operation and maintenance.
This matters because the fielded system may differ from the original design through approved concessions or changes.
15. As-Required Is Not the Same as As-Designed
The requirement state describes what the system is obligated to achieve. The design state describes the chosen technical solution.
Traceability links them without pretending they are the same artefact.
16. As-Designed Is Not the Same as As-Built
Manufacturing substitutions, field adjustments, software patches and concessions can create differences between drawings and reality.
Strong configuration management records those differences rather than assuming the build matches the design automatically.
17. As-Built Is Not the Same as As-Tested
A system may be modified between build completion and formal testing.
The configuration used for evidence must therefore be recorded explicitly.
18. As-Tested Is Not the Same as As-Deployed
Software, settings, cables, calibration or hardware can change between the test facility and deployment.
Configuration control protects against deploying a state whose evidence belongs to something else.
19. As-Deployed Is Not the Same as As-Operated
Operators may alter settings, install approved updates, replace components or reconfigure modes over time.
Operational configuration management preserves which state is actually delivering service.
20. As-Operated Becomes the Starting Point for Maintenance
Maintenance needs to know the current installed state, not merely the original design.
Parts, procedures and software compatibility depend on the real configuration in service.
21. Change Control Begins With a Proposed Difference
A change request identifies what is proposed, why it is needed and which configuration items are affected.
The request creates a visible object that can be analysed before implementation.
22. Change Requests Need Reasons
Drivers may include failure, obsolescence, cost, supplier change, regulation, performance improvement, safety, manufacturability or user feedback.
Recording the reason lets future engineers judge whether the same condition still applies.
23. Impact Analysis Looks Beyond the Item Being Changed
A small component change can alter weight, thermal load, interfaces, software, spares, certification, maintenance and test evidence.
Configuration management forces the project to examine the dependency network before approval.
24. Requirements Impact Must Be Checked
A design change may improve one function while violating another requirement or changing the conditions under which the requirement was verified.
NASA’s requirements-management guidance explicitly links baseline changes to configuration-management impact assessment.
25. Interface Impact Must Be Checked
Dimensions, connectors, protocols, units, timing and responsibility can change at system boundaries.
Interface documents themselves are often configuration-controlled because late changes propagate widely.
26. Safety Impact Must Be Checked
A replacement component may have different failure modes, materials, thermal behaviour or protective characteristics.
Configuration decisions should not assume functional equivalence means safety equivalence.
27. Reliability Impact Must Be Checked
Changes can introduce new common-cause dependencies, wear mechanisms or software faults.
28. Verification Impact Must Be Checked
If a configuration change alters something relevant to previously collected evidence, that evidence may no longer apply.
The correct question is not merely “was this tested before?” but “was this configuration, or an adequately equivalent one, supported by the evidence?”
29. Validation Impact Must Be Checked
A technical change can alter user workflow, maintenance burden or operational fit even when all lower-level requirements remain satisfied.
Changes affecting receiver outcomes may require renewed validation.
30. Cost and Schedule Impact Are Part of the Decision
Configuration control is not only a technical veto system. Decision-makers need to understand implementation cost, schedule disruption and lifecycle consequence.
The goal is informed change, not frozen design.
31. Change Authority Should Match Consequence
Minor internal changes may be approved locally; system-wide or safety-significant changes may require a configuration control board or equivalent authority.
Governance should be proportionate rather than equally heavy for every edit.
32. A Configuration Control Board Is a Decision Forum
A CCB brings together people capable of judging technical, cost, schedule, safety, operational and support impacts.
Its purpose is not ceremony; it decides whether a proposed baseline change should be approved, rejected, deferred or modified.
33. Approval Must Precede Controlled Implementation
If implementation begins before impact analysis and approval, the decision becomes a retrospective attempt to legitimise an already changed system.
Emergency exceptions can exist, but they should have their own controlled path.
34. Emergency Change Still Needs Identity
Urgency may compress review time, but the changed item, reason, authority and resulting state still need to be recorded.
Otherwise the emergency leaves a hidden branch in the product’s history.
35. Temporary Change Must Be Marked Temporary
Temporary bypasses, patches, jumpers, workarounds or operating restrictions can become permanent through inertia.
A temporary configuration should have scope, expiry or review conditions and a path back to a controlled long-term state.
36. Deviations and Waivers Need Distinct Identity
Sometimes a product does not fully conform to the intended baseline but is accepted under controlled conditions.
The exact terminology varies by industry; the important principle is that accepted nonconformance should be explicit rather than hidden inside the as-built record.
37. Implementation Must Update Every Affected Artefact
An approved hardware change may require revised drawings, bill of materials, maintenance manual, test procedure, spare-parts list and training material.
A change is not complete when only the physical object changes.
38. Software Change Can Propagate Faster Than Hardware Change
A software build can be copied instantly to many systems, making version control and deployment records essential.
Speed of distribution increases the need for exact identity rather than reducing it.
39. Hardware and Software Must Be Paired Correctly
One software version may depend on a specific sensor, controller or interface revision.
Configuration management should preserve compatibility rules so technically valid items do not form an invalid combination.
40. Firmware Is Often the Hidden Configuration Layer
Embedded systems can appear physically identical while behaving differently because firmware differs.
Firmware versions should therefore be treated with the same seriousness as visible hardware where they affect function.
41. Settings Are Configuration Too
Limits, calibration constants, feature flags, control gains, database schemas and policy settings can alter system behaviour without changing code or hardware.
Important settings need controlled identity where the operational outcome depends on them.
42. Data Can Be Part of the Configuration
Maps, lookup tables, trained model parameters, rule sets and reference databases can affect behaviour materially.
If changing data changes system function, the relevant data state may need configuration control.
43. Models Can Be Configuration Items
System models, simulations, CAD assemblies and analytical models can define or justify the design.
If decisions depend on a model, its version, assumptions and linked data should be identifiable.
44. Digital Engineering Makes Configuration Relationships More Important
Modern engineering can connect requirements, models, code, product lifecycle data and test evidence across digital tools.
INCOSE’s current configuration-management work explicitly addresses model-centric and digital-engineering environments because configuration now includes connected information, not only documents.
45. A Digital Twin Without Configuration Identity Can Become a Digital Stranger
A digital representation is useful only if it corresponds to the real asset state sufficiently for its decision purpose.
Hardware replacements, software patches and calibration changes must return to the digital representation when they matter.
46. Supplier Configuration Must Connect to Integrator Configuration
A supplier may revise a component, firmware or manufacturing process while preserving the same commercial part family.
The integrator needs enough visibility to know whether the supplied state still matches the evidence and interfaces supporting system acceptance.
47. Commercial Off-the-Shelf Products Still Change
COTS items can receive silent component substitutions, software updates or discontinuations.
Buying rather than building does not remove configuration risk; it changes who controls the internal change.
48. Supplier Notifications Are Configuration Inputs
Product-change notices, end-of-life notices, process changes and revised datasheets can trigger impact analysis.
The supply chain therefore participates in the configuration-management system.
49. Obsolescence Is a Configuration Event
When a part disappears, replacement may affect interfaces, performance, software, reliability and evidence.
50. Serialisation Preserves Unit-Level Identity
Where individual units can differ through manufacturing, repair or modification, serial numbers allow records to attach to the correct physical item.
Unit identity becomes essential for recalls, maintenance and anomaly investigation.
51. Lot and Batch Identity Preserve Population History
Materials, electronics, chemicals and manufactured parts can vary by production lot.
Batch identity helps connect later failures to common manufacturing or supplier conditions.
52. Configuration Status Accounting Answers “What Is the State Now?”
Status accounting records the current and historical state of configuration items, baselines, changes, releases and implementation.
It converts configuration control from memory into inspectable information.
53. Status Accounting Should Show Approved but Not Yet Implemented Changes
A change can be approved while some units remain on the earlier configuration.
The status system should distinguish decision state from implementation state.
54. Fleet Configuration Can Be Heterogeneous
Not every aircraft, train, server, machine or building may receive an update simultaneously.
Operations and maintenance need to know which unit carries which approved configuration.
55. Compatibility Matrices Make Mixed Fleets Manageable
When several hardware and software versions coexist, a matrix can show valid and invalid combinations.
This protects against assembling individually approved items into an unapproved system state.
56. Release Management Is a Configuration Boundary
A release packages approved items into a defined state authorised for build, test, deployment or operation.
Release therefore converts engineering work into an executable configuration commitment.
57. Build Reproducibility Depends on Controlled Inputs
Software libraries, compiler versions, CAD files, bills of material, manufacturing instructions and tool settings can affect the result.
A reproducible build needs enough input identity to create the same intended state again.
58. “Latest” Is Not a Configuration Identifier
Folders named latest, final or final-final create ambiguity because the meaning changes over time.
Stable release identifiers let references remain valid after the next version appears.
59. Branching Allows Parallel Change
Software and complex products sometimes need parallel configurations: development, released, maintenance, customer variants or experimental branches.
Branching is useful only when the team can understand divergence and control later merging.
60. Merging Is an Integration Decision
Two valid change branches can conflict when combined.
The merged state needs its own integration and evidence because local correctness does not guarantee combined correctness.
61. Configuration Audits Ask Whether Records and Reality Agree
An audit compares the approved product definition, records and actual realised state.
The purpose is to detect drift before it undermines test evidence, maintenance or safety.
62. Functional Audits Examine Whether Required Characteristics Are Satisfied
Some configuration frameworks distinguish audits focused on functional and performance evidence from audits focused on physical product definition.
The names vary, but the broader idea is useful: integrity includes both what the product is and what it demonstrably does.
63. Physical Audits Examine Whether the Realised Product Matches Its Definition
Part numbers, drawings, labels, software loads and documentation can be checked against the approved configuration.
Physical identity is crucial before the product becomes the reference for future units or maintenance.
64. Audit Findings Are Configuration Evidence
A mismatch may reveal an undocumented change, stale drawing, incorrect installation or incomplete implementation.
The correction should restore agreement or deliberately establish a new approved state.
65. Test Evidence Needs Configuration Traceability
A test result should identify the article, software, settings, environment and relevant support equipment.
This connects configuration management directly to How Engineering Testing Works.
66. Evidence Can Expire Through Configuration Change
A previously valid test may become irrelevant after a change to the load path, algorithm, interface or material.
Configuration impact analysis determines which evidence remains valid and which must be repeated or supplemented.
67. Reverification Should Follow Affected Claims
Not every change requires repeating every test.
Traceability should identify the affected requirements and evidence so reverification is targeted but sufficient.
68. Regression Testing Is Configuration-Aware Evidence
Software regression tests check whether previously working behaviour survives changes.
The regression suite itself can also be configuration-controlled because it encodes the claims that must remain true.
69. Review Decisions Belong to a Configuration State
A design review approves or conditions a specific technical state.
Major later changes can invalidate the assumptions that supported that review decision. See How Engineering Reviews Work.
70. Acceptance Belongs to a Configuration State
A product accepted in one configuration is not automatically accepted after a material change.
Configuration control keeps acceptance evidence attached to the state that earned it.
71. Certification Belongs to a Defined Configuration
Regulated products often have approved configurations, approved change processes and limits on what can change without renewed assessment.
The applicable regulatory framework governs the exact obligations; configuration management provides the identity needed to comply with them.
72. Maintenance Must Restore a Known State
A repair can return the asset to the same approved configuration or deliberately move it to a newer approved configuration.
Unrecorded substitutions create maintenance-driven configuration drift.
73. Cannibalisation and Part Swaps Need Unit-Level Records
Moving components between assets can solve immediate availability problems while complicating history and reliability analysis.
Serialised records preserve where each controlled item is installed.
74. Calibration Changes Can Change Configuration
Some systems depend on calibration constants, alignment or tuning values that materially affect performance.
Where these values define behaviour, their controlled state matters alongside hardware and software.
75. Operational Restrictions Can Become Configuration Constraints
A system may remain serviceable only under temporary restrictions after a known issue.
The restriction, affected units and release condition need controlled visibility so operations do not unknowingly exceed the approved state.
76. Configuration Drift Is the Slow Loss of Identity
Small undocumented changes accumulate until records no longer describe the actual system reliably.
Drift turns later maintenance, failure investigation and evidence reuse into guesswork.
77. Configuration Debt Is Real
Teams can defer documentation and change closure to move faster temporarily.
The debt appears later as slow troubleshooting, duplicate testing, incompatible replacements and uncertain product identity.
78. Too Much Configuration Control Can Also Harm Engineering
If every experimental note requires formal board approval, teams become slow and learn less.
Configuration control should become stricter as artefacts become authoritative and consequences of uncontrolled change increase.
79. Working State and Released State Should Be Distinct
Engineers need freedom to explore drafts and branches while the organisation needs stable released references.
A strong system separates experimentation from authoritative product definition.
80. Tailoring Is Part of Good Configuration Management
A small classroom device, a railway signalling system and a spacecraft do not need identical bureaucracy.
The principles—identity, controlled change, status and auditability—can be scaled to consequence.
81. Worked Configuration: A Lift System
Controlled items may include controller hardware, safety logic, door software, drive firmware, interface drawings and emergency-mode settings.
A field software update should preserve which lifts received it, which tests support it and whether old hardware revisions remain compatible.
82. Worked Configuration: A Water Pumping Station
Pumps, drives, PLC software, set points, instrumentation, valve schedules, electrical drawings and telemetry interfaces can form one controlled configuration.
Replacing a pump with a nominally equivalent model can still affect starting current, flow control and maintenance spares.
83. Worked Configuration: A Software Booking Platform
Source code, dependencies, database schema, infrastructure configuration, secrets policy, feature flags and deployment artefacts define the operational state.
A rollback is possible only when the earlier compatible state is identifiable and recoverable.
84. Worked Configuration: A Battery-Powered Device
Cell supplier, protection circuit, charging firmware, enclosure, thermal interface and radio firmware may all interact.
A quiet supplier substitution can invalidate thermal or endurance evidence even when the commercial specification looks similar.
85. Worked Configuration: A Classroom Ventilation Upgrade
Fan type, filter grade, controller settings, sensor calibration, electrical installation and maintenance interval collectively determine performance.
If sites differ, each classroom or building may have an as-installed configuration that must remain traceable to design assumptions.
86. Worked Configuration: A Railway Passenger Information Service
Central software, station software, display firmware, message schemas, network interfaces and timetable-feed versions must remain compatible.
Configuration management prevents one station’s older software from silently interpreting a newer message differently.
87. Hostile Test: “We Have the Latest Drawing”
Is it the approved drawing? Does it match the installed unit? Which revision was used during test? Was the field modification incorporated?
Latest is not enough; correspondence matters.
88. Hostile Test: “The Part Number Is the Same”
Did the supplier change internals, firmware, process, material or manufacturing site?
Commercial identity does not always guarantee engineering equivalence.
89. Hostile Test: “The Software Passed Before”
Which build? Which dependencies? Which database schema? Which hardware? Which settings?
Evidence belongs to a configuration, not to a product name in the abstract.
90. Hostile Test: “It Was Only a Small Change”
Small in code lines, weight or cost does not mean small in system impact.
Interfaces and shared dependencies can amplify apparently local modifications.
91. Hard Distinctions
| Do not collapse | Why it matters |
|---|---|
| Configuration ≠ version label | The state includes relationships, settings and product characteristics, not merely a number. |
| Baseline ≠ frozen forever | A baseline creates controlled change, not permanent immobility. |
| As-designed ≠ as-built | Reality can differ through approved or unapproved implementation. |
| As-built ≠ as-tested | The article can change before evidence is collected. |
| Approved change ≠ implemented change | Decision state and field state must remain distinct. |
| Same part number ≠ proven equivalence | Supplier internals or process may change. |
| Document control ≠ full configuration management | CM also governs product identity, change, status and audits. |
| Change control ≠ configuration management | Change control is one function inside the broader identity system. |
| Test pass ≠ evidence for every future configuration | Material change can invalidate old evidence. |
| Latest ≠ authoritative | Authority depends on approved state and intended use. |
92. What Strong Engineering Configuration Management Looks Like
- Configuration items are selected deliberately.
- Identifiers are stable and unambiguous.
- Authoritative baselines are visible.
- Working and released states are distinct.
- Changes have reasons, impact analysis and approval authority.
- Implementation status is recorded separately from approval status.
- Hardware, software, settings and data compatibility are controlled where relevant.
- As-built, as-tested and as-operated states can be reconstructed.
- Supplier changes enter the configuration process.
- Evidence is traced to the configuration that earned it.
- Audits compare records with reality.
- Configuration history survives the people who created it.
93. What Weak Engineering Configuration Management Looks Like
- Files are named final, latest and final-final.
- Software versions are known but hardware pairings are not.
- Installed units differ from drawings without a controlled record.
- Changes are implemented before impact analysis.
- Temporary workarounds have no expiry.
- Supplier substitutions are accepted by part number alone.
- Test results do not identify configuration.
- Approved changes are assumed to be implemented everywhere.
- Operational settings change without traceability.
- Audits occur only after a serious discrepancy appears.
- The team cannot answer which exact state is in service.
94. A Practical Configuration Management Checklist
- What product or system is under configuration control?
- Which items are configuration items?
- How is each item uniquely identified?
- Which baselines exist?
- What is the current approved state?
- What is the actual built or deployed state?
- Which changes are proposed?
- What requirement impacts do they have?
- What interface impacts do they have?
- What safety, reliability and support impacts do they have?
- Which evidence may become stale?
- Who can approve the change?
- How is implementation tracked?
- Which documents and models must update?
- Which units or sites have received the change?
- Which hardware/software combinations are valid?
- Which temporary configurations exist?
- When was the last configuration audit?
- Can the as-tested state be reconstructed?
- Can the as-operated state be reconstructed today?
95. The Configuration Decision Record
A strong record preserves the item, baseline, proposed change, reason, impact analysis, affected requirements and interfaces, evidence consequences, approval authority, implementation plan, verification needs, release identity and closure state.
This gives future engineers the reasoning behind the change rather than only the resulting revision number.
96. Configuration Management Is Organisational Memory
Engineered systems often outlive their original teams. Years later, maintainers and investigators still need to know why an unusual part, setting or restriction exists.
Configuration history preserves the ancestry of the system.
97. Configuration Management Is Also a Model of Identity Through Time
The system changes continuously but remains recognisably the same engineered asset or product family.
Configuration management explains which changes preserve continuity, which create a new baseline and which create a new product identity altogether.
98. The Receiver Test
Configuration control ultimately serves the receiver by ensuring that the thing delivered, maintained and operated is the thing whose capability and evidence were promised.
A perfect database is useless if the fielded system no longer corresponds to it.
99. The World-Return Test
After operation, ask where mismatches repeatedly appear: wrong parts, stale manuals, incompatible software, missing change records, obsolete test evidence or unknown settings.
Those mismatches reveal where the configuration system itself needs redesign.
100. The Final Configuration Principle: Know What You Have Before You Claim What It Can Do
Engineering confidence depends on identity. Requirements describe one state, drawings another, software another, hardware another and tests another unless configuration management binds them together.
The discipline succeeds when a team can answer, without guesswork: what was required, what was designed, what was built, what was tested, what changed, what is operating now and which evidence still belongs to it.
Engineering Series Map
- What Is Engineering? — field definition and boundaries.
- How Engineering Works — canonical lifecycle.
- How Engineering Requirements Work — needs into obligations.
- How Engineering Architecture Works — functions, boundaries and structure.
- How Engineering Design Works — design search and trade-offs.
- How Engineering Prototypes Work — temporary realities for learning.
- How Engineering Testing Works — controlled experiments and evidence.
- How Engineering Integration Works — joining realised elements.
- How Engineering Validation Works — fitness for intended use.
- How Engineering Failure Works — breakdown, learning and redesign.
- How Systems Engineering Works — whole-system coherence.
- How Engineering Reviews Work — technical gate decisions.
- How Engineering Configuration Management Works — this article; preserving exact product identity through change.
eduKateSG Crosswalk
- How Quality Works — wider quality-system owner.
- How Verification Works — claim-to-evidence discipline.
- How Interfaces Work — controlled exchange across boundaries.
- How Maintenance Works — preserving capability through service life.
- How Obsolescence Works — technology leaving the supportable estate.
- How X Works Master Hub — wider mechanism estate.
Evidence and Further Reading
Source-return note: the external anchors below were checked against their current official publisher pages on 8 September 2026. ISO 10007:2017 remains the current published ISO guideline for configuration management and is under revision; the draft revision is not treated here as a published standard.
- NASA Systems Engineering Handbook — 6.5 Configuration Management — life-cycle CM, configuration identification, control, status accounting and audits.
- NASA Systems Engineering Handbook — Appendix M: CM Plan Outline — planning structure for a configuration-management programme.
- NASA Systems Engineering Handbook — Requirements Management — baseline changes, impact assessment and configuration-control-board logic.
- NASA Systems Engineering Handbook — Technical Data Management — the relationship between data management and formal configuration control.
- INCOSE Configuration Management Working Group — full-lifecycle CM practice, model-centric engineering and evolving configuration-management methods.
- INCOSE Systems Engineering Handbook — current Version 5 and ISO/IEC/IEEE 15288:2023 life-cycle process context.
- ISO 10007:2017 — Quality management: Guidelines for configuration management — current published ISO configuration-management guideline, confirmed in 2023 and under revision as of 2026.
- ISO/IEC/IEEE 15288:2023 — current systems life-cycle process framework.
What This Article Does Not Claim
- It does not claim every project needs the same level of configuration bureaucracy.
- It does not claim configuration management prevents all change; its purpose is controlled change.
- It does not make document control equivalent to full product configuration management.
- It does not claim the same part number always proves technical equivalence.
- It does not replace applicable regulatory, contractual or safety-specific configuration requirements.
- It does not expose proprietary eduKateAI routing, private Wintour diagnostics or internal editorial ledgers.
Observable Mastery Test
Choose one engineered system and reconstruct six states: as-required, as-designed, as-built, as-tested, as-deployed and as-operated. Identify ten configuration items, two baselines, three valid hardware/software combinations, one proposed change, its impact path, the evidence that would become stale, the authority needed to approve it, the records needed to implement it, and one audit that would prove the fielded state matches the records.
Final compression: engineering configuration management is the discipline of identity through change. It tells engineers exactly what the system is, which baseline governs it, what changed, who approved the change, which units received it, which evidence still applies and what state is operating now. Before engineering can claim what a system can do, it must know which system it is talking about.