What Is a Configuration Item (CI)?

A configuration item (CI) is any hardware element, software component, document, or aggregation of elements that has been formally designated for configuration management. That designation means the item gets an identifier, its changes are controlled through a formal process, its status is recorded, and it can be audited against a known baseline.

The definition sounds simple. In practice, CI selection is one of the highest-leverage decisions in a program. Choose too few CIs and you lose traceability at exactly the points where failure modes tend to hide. Choose too many and the configuration management overhead becomes the job, crowding out the engineering work that actually produces a product.

This article covers what CIs are, how they are classified under defense and systems engineering standards, what baselines mean in this context, and how requirement sets fit into the CI model — including how modern tooling can manage them as first-class configuration artifacts rather than documents that happen to sit in a folder.

The Core Concept: Designation and Identity

Not every piece of hardware or every source file is a configuration item. A CI is created by a deliberate management decision, documented in the Configuration Management Plan (CMP), that says: this entity warrants independent identification, change control, and traceability.

That decision is driven by several factors:

  • Risk and criticality. Safety-critical subsystems, single-failure-point hardware, and software with safety implications are almost always CIs.
  • Interface responsibility. Anything at a system interface — between contractors, between hardware and software, between a deliverable and an external system — is a natural CI boundary.
  • Contractual deliverability. If a customer takes delivery of it, accepts it, or verifies it separately, it is a CI.
  • Independent replaceability. If you can upgrade, replace, or repair the item without changing everything around it, it warrants separate identity.

The CMP documents the rationale for CI selection, the naming and numbering scheme, the change control process, and the roles (Configuration Control Board, configuration manager, etc.) responsible for each CI class.

HWCI vs. CSCI: The Standards-Based Distinction

Under MIL-STD-499 and the associated configuration management standard MIL-HDBK-61, the CI taxonomy splits along a fundamental line:

Hardware Configuration Item (HWCI)

An HWCI is a configuration item that is implemented primarily in hardware — circuit cards, chassis, RF assemblies, mechanical structures, power supplies, sensors. The governing documentation chain for an HWCI runs from the System Requirements Specification (SyRS) through the Hardware Development Specification (Type B3) to the engineering drawings that define the item’s physical and functional characteristics.

Verification of an HWCI proceeds through a Functional Configuration Audit (FCA) and Physical Configuration Audit (PCA). The FCA confirms that the item performs all functions in its specification. The PCA confirms that the as-built configuration matches the documented drawings and parts lists.

Computer Software Configuration Item (CSCI)

A CSCI is a configuration item implemented in software. Under MIL-STD-499 and MIL-STD-498 (since superseded in commercial practice but still referenced on many defense programs), each CSCI has its own Software Requirements Specification (SRS), Software Design Document (SDD), and Software Version Description (SVD).

CSCIs are verified through a similar FCA/PCA sequence, but the PCA for software focuses on confirming that the compiled, linked executable corresponds to the exact source configuration under CM control — the same concept as hardware build-of-materials translated into software builds.

Why the Distinction Matters

HWCIs and CSCIs have different change cost structures. A hardware change after the product baseline is set typically requires engineering change proposals (ECPs), drawing updates, re-qualification testing, and often physical retrofit. A software change can be cheaper to implement but carries the same contractual weight on a baselined CSCI — it still requires an ECP, regression testing, and an updated SVD.

Teams that blur the HWCI/CSCI boundary — treating firmware, for example, as neither hardware nor software — tend to discover the problem at a configuration audit when no one can say with authority what version of what firmware is in what unit.

Firmware and embedded software deserve particular attention. Firmware burned into a programmable device (FPGA, microcontroller) is typically managed as a CSCI even when the device itself is part of an HWCI. The device is the hardware; the image on it is software. Both need CM identity.

Baselines: Locking CI Definitions at Milestones

A baseline is a formally reviewed and agreed-upon snapshot of a CI’s configuration at a specific program milestone. Three baselines appear in nearly every defense and complex commercial program:

Functional Baseline (FBL)

Established at System Requirements Review (SRR) or its equivalent. The FBL captures the system-level functional and performance requirements — what the system must do, under what conditions, verified by what methods. The FBL does not describe how the system will be built. It describes what it must accomplish.

All CIs at the system level are identified in the FBL, even if their internal configuration is not yet defined.

Allocated Baseline (ABL)

Established at Preliminary Design Review (PDR). The ABL allocates system-level requirements down to individual HWCIs and CSCIs. Each CI’s specification is released: this is what this particular box or this particular software module must do, within these interfaces, verified by these tests.

The ABL is the formal document set that a subcontractor or integrated product team works to. Changes to allocated requirements after ABL require formal change control.

Product Baseline (PBL)

Established at Critical Design Review (CDR) or after first article acceptance. The PBL captures the detailed design — drawings, schematics, code at the build level, interface control documents — sufficient to reproduce the item. This is the baseline that manufacturing and sustainment work from.

Post-PBL changes are the most expensive category of program change. The product baseline is what gets maintained throughout the operational life of the system.

Requirement Sets as Configuration Items

Here is where many programs create latent risk without realizing it: they manage hardware drawings under rigorous CM and treat requirement documents as living files in a shared folder.

Requirement sets are CIs. The allocated specification for a CSCI — the SRS — is a baselined document. The system-level requirements that flow into the FBL are a baselined document. If you cannot answer “what version of this requirement existed at the time this design decision was made,” you cannot conduct a valid FCA, and you cannot reconstruct the engineering rationale for the design.

In practice, requirements documents under traditional tooling (Word, Excel, PDF) are often version-controlled only in name. The file has a revision letter, but the internal change history is inconsistent, the linkage to downstream design artifacts is informal, and the re-baseline process at each milestone is a manual snapshot exercise.

The consequence appears during audits and during investigations after failures. “What requirement authorized this design choice?” becomes difficult to answer when the requirement document has been revised seven times since CDR with no formal change log and no downstream impact analysis.

How Modern Tools Implement Requirements as Configuration Artifacts

The practical question is not whether requirement sets should be treated as CIs — they should, and the standards say so. The question is what tooling actually makes this tractable.

Traditional requirements management tools — IBM DOORS, DOORS Next, Jama Connect, Polarion — provide versioning and baselining capabilities. DOORS, in particular, has deep baselining mechanics that many defense programs rely on. Jama Connect handles baseline snapshots with reasonable audit trails. These are real capabilities that real programs depend on.

The limitation of document-centric tools is structural: a baseline is a snapshot of a document, not a snapshot of a connected model. When you baseline a DOORS module, you capture the text of requirements at a point in time. What you do not automatically capture is the live state of the traceability graph — which requirements are linked to which design elements, which tests, which HWCIs and CSCIs. Reconstructing that graph after the fact is manual work.

Flow Engineering approaches this differently by treating the requirement set not as a document but as a graph of connected nodes — requirements, verification methods, design elements, interfaces — where the connections are part of the artifact being baselined. When a baseline is locked, it captures not just requirement text but the full relational context: what this requirement traces to, what it derives from, what verification evidence is associated with it.

For programs operating under formal CM discipline, this means that a baseline at PDR is a navigable model of the allocated requirements and their relationships, not a PDF that captures text at a point in time. Changes after that baseline are not just tracked as text diffs; they are tracked as changes in the graph — a new trace link, a broken allocation, an added child requirement — each of which can trigger the appropriate change control workflow.

Flow Engineering is explicitly focused on hardware and systems engineering teams rather than being a general-purpose ALM tool that happens to include requirements management. That focus shows in how it handles HWCI/CSCI decomposition, system-level allocations, and the formal baseline workflow at program milestones. Teams running large multi-domain programs that also need integrated software lifecycle management alongside requirements will want to evaluate whether Flow Engineering’s scope matches their full workflow, or whether it needs to connect into a broader toolchain.

Practical Starting Points

If you are setting up CI discipline on a new program, or cleaning up an existing program with inconsistent CM practices, three steps reduce risk quickly:

1. Document CI selection rationale in the CMP before CDR. The question “is this a CI?” needs an answer with recorded justification, not a judgment made at audit time. The CMP should list every CI by name, type (HWCI or CSCI), the responsible party, and the rationale for separate identification.

2. Treat every baselined specification as a configuration artifact, not a document. This means version numbers, change logs, formal change authorization before post-baseline revision, and traceability from requirements to the design decisions they drove. If your tooling cannot enforce this automatically, establish a manual process with enforced gate reviews.

3. Lock the requirement baseline before you lock the design baseline. The FBL and ABL exist because requirement changes after design is mature are expensive. If your requirement set is still in flux at CDR, you do not have a product baseline — you have a design that is ahead of its authorization. This is where most configuration audit findings originate.

Summary

A configuration item is any entity formally designated for identification, change control, status accounting, and audit. HWCIs and CSCIs carry different documentation chains and different audit requirements under MIL-STD-499 and related standards, but both exist within the same baseline discipline. Functional, allocated, and product baselines lock CI definitions at program milestones and establish the change-control boundaries that govern everything after.

Requirement sets are CIs. Treating them as managed documents rather than configuration artifacts is a common gap — one that shows up at audits and failure investigations at the worst possible time. Tools that manage requirements as connected graph models, where the baseline captures both content and relationships, give programs a materially better foundation for the traceability and auditability that complex hardware and software programs require.