Configuration management in aerospace is the discipline of planning, identifying, controlling changes to, accounting for, and verifying the configuration of a product across its lifecycle, built on the five functions defined in EIA-649C and reinforced by NASA's CM guidance. A program succeeds at CM when it can produce an auditable baseline on demand, trace every change request back to a requirement, and verify that what was built matches what was approved. QA-Report and similar inspection tools exist to make that last step faster.
TL;DR:
- Proper identification of configuration items should focus on controlling elements with external interfaces, safety implications, or high lifecycle costs.
- Change requests must include detailed justification and impact assessment, with classification rules for major and minor changes clearly documented.
- Configuration status accounting should enable instant retrieval of current configurations, change progress, and verification evidence, with high data integrity standards.
- Audits and inspection efforts should produce artifact packages such as FAI reports and traceable records, verified through scheduled internal reviews.
- Tooling must support rigorous version control, automated status updates from manufacturing data, and full lifecycle record preservation to ensure audit readiness.
Table of Contents
- The five core functions behind every aerospace CM program
- Setting baselines and identifying configuration items
- Managing engineering changes without losing control
- What configuration status accounting needs to track
- Verifying configuration through audits and inspection evidence
- Keeping model-based baselines under control
- What to require from CM and CSA tooling
- Building a configuration management plan you can actually use
- Where aerospace configuration management programs actually fail
- Turning inspection data into audit-ready CM evidence
- FAQ
- Sources
The five core functions behind every aerospace CM program
Every aerospace CM program rests on five functions, and skipping one weakens the rest. These functions, as defined in EIA-649C and echoed in NASA's own CM guidance, give engineering teams a common language for discussing control, regardless of program size.
Planning sets the rules before any hardware or model exists: who approves changes, what gets baselined, and on what schedule. Identification assigns unique, persistent identifiers to configuration items (CIs) so that every drawing, model element, and software build can be referenced without ambiguity. Change management governs how a proposed change moves from request to approved implementation. Configuration status accounting (CSA) keeps a living record of what is baselined, what has changed, and what remains open. Verification and audit confirms that the as-built or as-coded product matches its approved baseline.
Underlying these functions are a few recurring principles worth memorizing:
- Traceability must run unbroken from requirement to design to verification record.
- Every CI needs a unique identifier that never gets reused, even after retirement.
- CM applies across the full lifecycle, not just during design.
- Tailoring is expected: a cubesat program and a crewed vehicle program apply the same functions at different rigor.
Setting baselines and identifying configuration items
Choosing the right configuration items is a judgment call, not a checklist exercise. Select CIs at the level where independent control actually matters: a system, a subsystem, a major assembly, or a part with its own interface or qualification history. Favor CIs with external interfaces, safety implications, or high lifecycle cost over components that are purely internal to an assembly with no independent use.
A practical sequence for identification and baselining looks like this:
- Assign each CI a unique identifier tied to a part number or model element ID that will never be reused.
- Version documents and models with a scheme that separates draft, released, and superseded states clearly.
- Establish the functional baseline at the system requirements review, defining what the system must do.
- Establish the allocated baseline at the system design review, apportioning requirements to subsystems.
- Establish the product baseline at or after critical design review, capturing the as-designed configuration ready for production.
Each baseline becomes the reference point against which later changes are measured, which is why naming conventions and version discipline matter as much as the technical content itself. The internal guide on revision control in manufacturing walks through a practical baselining sequence for production environments.
Managing engineering changes without losing control
A change request (CR) should never move forward on a verbal agreement. Each CR needs a technical justification, an assessment of what it touches, and an explicit trace back to the requirement or defect that triggered it. From there, the request moves through classification, impact review, board decision, implementation, and closure, with status recorded at each step.
A configuration control board (CCB) typically includes engineering, quality, manufacturing, and program management representation, and its decision rules should be written down before the first contested change arrives. Classification matters: a major change affects form, fit, function, interchangeability, or safety and requires full CCB review; a minor change does neither and can often be approved at a lower level with a lighter record.
- Capture schedule and cost impact alongside the technical rationale in every CR.
- Flag any change touching safety analysis for a mandatory safety review before approval.
- Record retrofit decisions separately from forward-fit decisions, since they often carry different risk profiles.
- Close the loop by verifying implementation, not just approving the request.
Pro Tip: Route every CR through the same intake form regardless of size. Small changes that skip the form are the ones that erode traceability first.
What configuration status accounting needs to track
CSA is the function most often reduced to paperwork, but its real job is answering "what is the current approved configuration, and what is in work" instantly, without a meeting. NASA's Glenn Research Center work on the Power and Propulsion Element%20Final.pdf) found that CSA has to be designed for instant status queries on baselined items and CR progress, not just periodic reporting.
A workable CSA dataset includes key items such as the current CI list with baseline identifiers, change requests linked to the CIs they affect, implementation progress, attached evidence like drawings and test reports, and authorship and approval timestamps for records, without specifying exact numbers or percentages.
Reports to need often drive dashboard design. Program reviews want baseline-level summaries, while supply-chain partners usually need CI-level change status tied to the parts they build. Data integrity controls matter here as much as the fields themselves: timestamps, digital signatures, access logs, and defined retention periods keep the record defensible under audit. NASA's CM guidance ties CM outputs directly to program decision points, which only works if the underlying CSA data is current and trustworthy.
Verifying configuration through audits and inspection evidence
Configuration verification confirms that a product meets its baseline before it moves forward, and it happens through three related but distinct activities. Configuration verification (CV) checks design output against requirements during development. The functional configuration audit (FCA) confirms the product performs as the functional baseline specifies. The physical configuration audit (PCA) confirms the as-built product matches the product baseline documentation, down to the drawing.
First Article Inspection packages built to AS9102 are some of the strongest audit evidence a program can produce, because they tie measured dimensions directly to the drawing and the approved baseline. A well-run FAI process gives auditors exactly what an FCA or PCA needs to check.
- Keep inspection records, test reports, and FAI packages linked to the CI and baseline they support.
- Run internal audits on a fixed schedule rather than only in response to external pressure.
- Treat a delta FAI as mandatory evidence whenever a change affects a previously accepted characteristic.
- Retain records long enough to cover the full program lifecycle, including sustainment.
The detailed walkthrough of AS9102 Rev C requirements and the companion piece on delta FAI rules both go deeper into building audit-ready packages that satisfy these three verification types.
Keeping model-based baselines under control
Model-based systems engineering changes what gets baselined. Instead of a drawing package, the baseline is a set of model elements, and not every element deserves the same level of control. Decide early which attributes are baseline-controlled under CM and which remain data-managed, meaning they can change freely without triggering a formal CR.
A pattern drawn from NASA Glenn's work on the Power and Propulsion Element MBSE model offers a workable sequence:
- Issue a CR number before any model branch is created.
- Name the development branch after the CR number so its purpose is traceable at a glance.
- Log every branch in an MBSE baseline action log that records status from creation to merge.
- Enforce one open CR per branch to keep merges auditable.
- Run a post-merge audit before locking the updated baseline.
Pro Tip: Lock only the model attributes that certification evidence depends on. Over-locking a model slows engineers down without adding real traceability.
Traceability across requirements, model elements, verification records, and CSA entries should use consistent identifiers end to end, the same discipline EIA-649C demands of document-based baselines, just applied to model fields instead of drawing revisions.
What to require from CM and CSA tooling
Tooling choices either reinforce CM discipline or quietly undermine it. A few requirements separate systems that hold up under audit from ones that generate extra work.
- Baselining and version control that timestamps every change and prevents silent overwrites.
- CR tracking that links each request to affected CIs, requirements, and verification evidence.
- CSA automation that updates status from inspection and production data rather than manual entry.
- Role-based access control with a full audit log of who viewed or changed what.
- Integration hooks into MBSE, PLM, and ALM systems so CM data does not live in a separate silo.
- CMM import and automated drawing ballooning that produce AS9102-ready output directly from measurement data.
- Links into MES or ERP systems so production status feeds CSA without a manual handoff.
Offline access for shop-floor inspectors and long-term record preservation round out the list. A tool that cannot preserve records for the full program lifecycle, including sustainment decades later, is not a serious CM tool.
Building a configuration management plan you can actually use
A CM plan does not need to be long to be effective, but it needs every one of these sections, tailored to the program's phase.
- Scope and applicability, naming which products and phases the plan covers.
- CI list with selection rationale.
- Baseline definitions and the milestone each one ties to.
- CCB composition and decision authority.
- CR process with classification rules for major and minor changes.
- CSA dataset and reporting cadence.
- Verification and audit schedule, including FCA and PCA timing.
- Tailoring rules explaining what changes between phases.
Tailoring matters in practice. A prototype phase might skip formal CCB review for minor changes, while a production phase enforces it for every change touching a released drawing. A sustainment phase often adds stricter retrofit tracking because fleet-wide consistency becomes the priority.
| Metric | What it tracks | Healthy signal |
|---|---|---|
| CR cycle time | Days from CR submission to disposition | Trending downward |
| Baseline currency | Share of CIs with an approved, current baseline | Near complete coverage |
| Audit finding rate | Findings per FCA/PCA cycle | Trending downward |
| Open CR backlog | Count of unresolved change requests | Stable or shrinking |
Where aerospace configuration management programs actually fail
The most common failure is not too little control, it is control applied in the wrong place. Over-controlling every model attribute slows engineers down; under-identifying CIs leaves gaps auditors find immediately. Poor CSA hygiene, stale timestamps, missing authorship, unlinked evidence, quietly erodes trust in the whole system long before an audit exposes it.
Programs that avoid this treat automation as a CM control, not a convenience: feeding CSA from inspection and production data directly, limiting CCB review to changes that genuinely warrant it, and locking only the model fields that certification depends on. Lightweight, scheduled internal audits catch drift before a customer or regulator does.
— Michael Chen
Turning inspection data into audit-ready CM evidence
Most of the manual work in aerospace CM happens at the evidence layer: ballooning drawings by hand, transcribing CMM output, and assembling FAI packages under deadline pressure. The platform balloons drawings automatically, imports CMM data directly, flags out-of-tolerance results, and generates comprehensive FAI reports that satisfy industry quality and production standards without rebuilding the package from scratch each time.
An integrated MES layer tracks parts, batches, and operations through production, so the CSA record updates from real shop-floor activity instead of a spreadsheet someone forgot to update. For teams managing sensitive aerospace data, QA-Report offers both cloud and on-premise deployment. Explore the Free, Basic, PRO, and Enterprise plans and start a trial to see how automated ballooning and FAI reporting fit into your CM workflow.
FAQ
What is configuration management in aviation?
Configuration management in aviation is the set of processes that plan, identify, control changes to, account for, and verify the configuration of aircraft systems and components across their lifecycle. It follows the same five functions defined in EIA-649C and referenced in FAA guidance for the National Airspace System.
What are the 5 pillars of configuration management?
The five pillars, or functions, are planning, identification, change management, configuration status accounting, and verification and audit. These are codified in EIA-649C and form the structure of NASA's CM guidance as well.
What are the 5 stages of the configuration management process?
The process generally moves through planning, identification of configuration items and baselines, change control, status accounting, and verification or audit. Each stage feeds the next, so a gap in identification, for example, weakens every later stage's traceability.
What is the average salary for a Configuration Manager in the US?
Salary figures for configuration management roles vary widely by industry, seniority, and location, and no figure in the sources behind this article is specific enough to state reliably. A program's engineering or HR team, or a current industry salary survey, is a better source for that number than this guide.