Industry Acronyms

Configuration Item

Q: How do you decide whether an assembly should be designated a configuration item?

CI selection is a deliberate engineering and program decision, not an automatic one. An item is typically designated a configuration item when it has critical or high-risk performance, is procured to a specification, has a distinct development or maintenance lifecycle, requires separate qualification or acceptance testing, is supplied by a different organization, or must be field-replaceable and tracked by serial number. In an RF subsystem, a 28 GHz block downconverter module, a phased-array tile, or a frequency-synthesizer board are commonly designated CIs, while passive standoffs, fasteners, and generic SMD passives are not. Over-designating CIs inflates documentation and change-board workload; under-designating loses traceability. EIA-649 guidance is to push CI status down only to the level where independent change control and accountability add real value.

Q: What is the difference between a configuration item and a part number?

A part number identifies a specific design and revision of a piece part or assembly so that two items with the same part number are interchangeable. A configuration item is a management designation: it declares that a particular product entity will be controlled as a unit, with its own approved baseline, change authority, status accounting records, and audits. A CI almost always carries a part number, but most part numbers are not CIs. The CI is the level at which a change board convenes and at which functional and physical configuration audits are conducted, whereas the part number is the identifier that the resulting baseline points to. For a CI you also track effectivity, serialized units, and the as-built versus as-designed configuration.

Q: What documents make up the baseline of a hardware configuration item?

A hardware CI baseline evolves through three formal stages. The functional baseline captures the system or CI performance requirements, typically in a system or item performance specification approved at the System Requirements Review. The allocated baseline adds the development specification that allocates and derives requirements down to the CI, approved at the Preliminary Design Review. The product baseline is the as-built definition: detailed drawings, the bill of materials, parts lists, interface control documents, acceptance test procedures, and the product specification, approved at the Critical Design Review and verified by a Physical Configuration Audit. Each baseline is frozen at its review, and after that point any change is processed as an engineering change request against the CI rather than an informal edit.

/kuhn-fig-yuh-RAY-shuhn EYE-tuhm/ (CI)

Designated in configuration management as the unit of formal control, a configuration item (CI) is any hardware assembly, software unit, or controlled document selected to be managed as a single entity with a unique identifier, an approved baseline, and a defined change-control authority. Once an item is declared a CI, its design definition is frozen at each program milestone and every subsequent change is processed through a change board rather than edited informally, which is what gives a program full traceability from requirements to the as-built units. In RF and microwave programs, CIs are usually picked at the line-replaceable module level, such as a downconverter, synthesizer board, or phased-array tile, where independent qualification, serialization, and accountability genuinely matter. The CI is the level at which functional and physical configuration audits are performed and against which the bill of materials and effectivity are tracked.

Category: Industry Acronyms

Governing standards: EIA-649, MIL-STD-973

Typical CI level: Line-replaceable module

Selecting and Controlling a Configuration Item

The configuration item is the cornerstone of any disciplined configuration management program because it answers the first practical question: what, exactly, are we going to control as a unit? Standards such as ANSI/EIA-649 and the older MIL-STD-973 do not hand out a fixed list; instead they treat CI selection as an engineering decision driven by risk, lifecycle independence, and accountability. An entity becomes a CI when it has critical performance, a distinct development or maintenance path, separate acceptance or qualification testing, a different supplier, or a need to be tracked and field-replaced by serial number. Choosing the right granularity is the real skill: designate too many CIs and the change board drowns in paperwork, designate too few and you lose the very traceability the program exists to provide.

For a millimeter-wave subsystem, the natural CIs are the line-replaceable modules. A 28 GHz block downconverter, a frequency synthesizer board, a power-conditioning module, and an antenna tile are each plausible hardware configuration items (HWCIs), while their firmware loads are computer software configuration items (CSCIs). Generic passives, fasteners, and brackets are controlled through the parent assembly's drawing and parts list rather than as standalone CIs. Each CI carries its own identifier and its own approved baseline, and that baseline is what a change request is written against.

Once selected, a CI moves through configuration identification, change control, status accounting, and audits. Identification assigns the numbering and marking; the baseline is approved and frozen at the relevant design review; subsequent changes flow through engineering change requests and the change board; status accounting records who changed what, when, and on which serialized units; and configuration audits confirm that the as-built hardware matches the as-designed product baseline before delivery.

Baselines and Effectivity

A CI does not have one baseline, it accumulates them. The functional baseline fixes the performance requirements, the allocated baseline derives requirements down to the CI, and the product baseline captures the complete as-built definition including drawings, parts lists, and acceptance procedures. Effectivity then records which serialized units a given revision applies to, so an in-service change to units 1 through 20 can coexist with a later revision on units 21 onward without ambiguity.

Configuration Identification Rules of Thumb

CI selection score (relative weighting):
S = w_r·Risk + w_l·Lifecycle + w_i·Interface + w_s·Supplier → designate CI when S ≥ threshold

Documentation effort scaling:
Effort ≈ N_CI × (D_baseline + R_change × f_change)

Identifier structure (typical):
CI-ID = CAGE + PartNumber + Revision + SerialNo (composed, not multiplied)

Where N_CI = number of configuration items, D_baseline = effort per baseline document set, R_change = effort per change action, f_change ≈ 2 to 6 changes per CI per year on an active RF development. Pushing CI level one tier deeper can multiply N_CI by 5× to 10×, so granularity is a deliberate cost trade.

Configuration Item vs. Adjacent Concepts

Concept	What it is	Granularity	Controlled by	Example (RF subsystem)
Configuration Item (CI)	Unit of formal CM control with its own baseline and change authority	Module / LRU level	Configuration control board	28 GHz downconverter module
Part Number	Identifier for an interchangeable design + revision	Any level	Drawing release process	PCB assembly P/N 41207-03
Baseline	Approved, frozen configuration at a milestone	Per CI	Design review approval	Product baseline at CDR
HWCI	Hardware configuration item	Assembly / module	CCB + physical audit	Synthesizer board
CSCI	Computer software configuration item	Software build	CCB + functional audit	DSP firmware load v2.4

Common Questions

Frequently Asked Questions

How do you decide whether an assembly should be designated a configuration item?

CI selection is a deliberate decision driven by risk, lifecycle independence, and accountability, not an automatic rule. Designate a CI when an item has critical performance, a distinct development or maintenance path, separate qualification or acceptance testing, a different supplier, or a need to be serialized and field-replaced. In an RF subsystem a downconverter, synthesizer board, or array tile are natural CIs, while fasteners and generic passives are not. EIA-649 guidance is to push CI status down only to where independent change control adds real value, since over-designating inflates change-board workload and under-designating loses traceability.

What is the difference between a configuration item and a part number?

A part number identifies a specific design and revision so that two items sharing it are interchangeable. A configuration item is a management designation declaring that an entity will be controlled as a unit, with its own baseline, change authority, status accounting, and audits. A CI almost always has a part number, but most part numbers are not CIs. The CI is the level at which a change board convenes and at which functional and physical configuration audits run, while the part number is the identifier the baseline points to. For a CI you also track effectivity, serialized units, and the as-built versus as-designed state.

What documents make up the baseline of a hardware configuration item?

A hardware CI baseline evolves in three stages. The functional baseline captures CI performance requirements in a performance specification, approved at the System Requirements Review. The allocated baseline adds the development specification that derives requirements down to the CI, approved at the Preliminary Design Review. The product baseline is the as-built definition: drawings, bill of materials, parts lists, interface control documents, acceptance test procedures, and the product specification, approved at the Critical Design Review and verified by a Physical Configuration Audit. After each review the baseline is frozen and any change is processed as an engineering change request.

Related Terms

← Confidence Value Configuration Management →